Instead of understanding all of this, and when it does or does not apply, it's probably better to disclose vulnerabilities anonymously over Tor.
It's not worth the hassle of being forced to hire a lawyer, just to be a white hat.
Part of the motivation of reporting is clout and reputation. That sounds harsh or critical but for some folks their reputation directly impacts their livelihood. Sure the data controller doesn't care, but if you want to get hired or invited to conferences then the clout matters.
People already pay for journalism through substack. It's not micropayments, it's a commitment to the ongoing consumption of a high quality creator's work.
I can't think of a single news outlet that isn't obviously propaganda or virtue porn. People who want that can have it, but the internet has has made the business models common knowledge, and now most people would be embarrassed to consume these outlets.
All of that was true before prediction markets, now if a fact is important enough, it has a market, and if I need to know the best take on that fact, I will look at the market.
There's an undertone of self-soothing "AI will leverage me, not replace me", which I don't agree with especially in the long run, at least in software.
In the end it will be the users sculpting formal systems like playdoh.
In the medium run, "AI is not a co-worker" is exactly right.
The idea of a co-worker will go away.
Human collaboration on software is fundamentally inefficient.
We pay huge communication/synchronization costs to eek out mild speed ups on projects by adding teams of people.
Software is going to become an individual sport, not a team sport, quickly.
The benefits we get from checking in with other humans, like error correction, and delegation can all be done better by AI.
I would rather a single human (for now) architect with good taste and an army of agents than a team of humans.
> In the end it will be the users sculpting formal systems like playdoh.
And unless the user is a competent programmer, at least in spirit, it will look like the creation of the 3-year-old next door, not like Wallace and Gromit.
It may be fine, but the difference is that one is only loved by their parents, the other gets millions of people to go to the theater.
Play-Doh gave the power of sculpting to everyone, including small children, but if you don't want to make an ugly mess, you have to be a competent sculptor to begin with, and it involves some fundamentals that does not depend on the material. There is a reason why clay animators are skilled professionals.
The quality of vibe coded software is generally proportional to the programming skills of the vibe coder as well as the effort put into it, like with all software.
It really depends what kind of time frame we're talking about.
As far as today's models, these are best understood as tools to be used as humans. They're only replacements for humans insofar as individual developers can accomplish more with the help of an AI than they could alone, so a smaller team can accomplish what used to require a bigger team. Due to Jevon's paradox this is probably a good thing for developer salaries: their skills are now that much more in demand.
But you have to consider the trajectory we're on. GPT went from an interesting curiosity to absolutely groundbreaking in less than five years. What will the next five years bring? Do you expect development to speed up, slow down, stay the course, or go off in an entirely different direction?
Obviously, the correct answer to that question is "Nobody knows for sure." We could be approaching the top of a sigmoid type curve where progress slows down after all the easy parts are worked out. Or maybe we're just approaching the base of the real inflection point where all white collar work can be accomplished better and more cheaply by a pile of GPUs.
Since the future is uncertain, a reasonable course of action is probably to keep your own coding skills up to date, but also get comfortable leveraging AI and learning its (current) strengths and weaknesses.
I don't expect exponential growth to continue indefinitely... I don't think the current line of LLM based tech will lead to AGI, but that it might inspire what does.
That doesn't mean it isn't and won't continue to be disruptive. Looking at generated film clips, it's beyond impressive... and despite limitations, it's going to lead to a lot of creativity, that doesn't mean someone making something longer won't have to work that much harder to get something consistent... I've enjoyed a lot of the StarWars fan films that have been made, but there's a lot of improvements needed in terms of the voice acting, sets, characters, etc that arre needed for something I'd pay to rent or see in a thaater.
Ironically, the push towards modern progressivism and division from Hollywood has largely been a shortfall... If they really wanted to make money, they'd lean into pop-culture fun and rah rah 'Merica, imo. Even with the new He-Man movie, the biggest critique is they bothered to try to integrate real world Earth as a grounding point. Let it be fantasy. For that matter, extend the delay from theater to PPV even. "Only in theaters for 2026" might actually be just enough push to get butts in seats.
I used to go to the movies a few times a month, now it's been at least a year since I've thought of going. I actually might for He-Man or the Spider-Man movies... Mixed on Mandalorean.
For AI and coding... I've started using it more the past couple months... I can't imagine being a less experienced dev with it. I predict, catch and handle so many issues in terms of how I've used it even. The thought of vibe-coded apps in the wild is shocking to terrifying and I wouldn't wany my money anywhere near them. It takes a lot of iteration, curation an baby-sitting after creating a good level of pre-documentation/specifications to follow. That said, I'd say I'm at least 5x more productive with it.
> In the end it will be the users sculpting formal systems like playdoh.
I’m very skeptical of this unless the AI can manage to read and predict emotion and intent based off vague natural language. Otherwise you get the classic software problem of “What the user asked for directly isn’t actually what they want/need.”
You will still need at least some experience with developing software to actually get anything useful. The average “user” isn’t going to have much success for large projects or translating business logic into software use cases.
Unfortunately, I believe the following will happen:
By positioning themselves close to law makers, the AI companies will in the near future declare ownership of all software code developed using their software.
They will slowly erode their terms of service, as happens to most internet software, step by step, until they claim total ownership.
> AI companies will in the near future declare ownership of all software code developed using their software.
(X) Doubt
Copyright law is WEEEEEEIRRRDD and our in-house lawyer is very much into that, personally and professionally. An example they gave us during a presentation:
IIRC the latest resolution is "it's not the monkey", but nobody has ruled the photographer has copyright either. =)
Copyright law has this thing called "human authorship" that's required to apply copyright to a work. Animals and machines can't have a copyright to anything.
A comic generated with Midjourney had its copyright revoked when it was discovered all of the art was done with Generative AI.
AI companies have absolutely mindboggling amounts of money, but removing the human authorship requirement from copyright is beyond even them in my non-lawyer opinion. It would bring the whole system crashing down and not in a fun way for anyone.
AFAIK you can't copyright AI generated content. I don't know where that gets blurry when it's mixed in with your own content (ie, how much do you need to modify it to own it), but I think that by that definition these companies couldn't claim your code at all. Also, with the lawsuit that happened to Anthropic where they had to pay billions for ingesting copyrighted content, it might actually end up working the other way around.
> the AI companies will in the near future declare ownership of all software code developed using their software.
Pretty sure this isn’t going to happen. AI is driving the cost of software to zero; it’s not worth licensing something that’s a commodity.
It’s similar to 3D printing companies. They don’t have IP claims on the items created with their printers.
The AI companies currently don’t have IP claims on what their agents create.
Uncle Joe won’t need to pay OpenAI for the solitaire game their AI made for him.
The open source models are quite capable; in the near future there won’t be a meaningful difference for the average person between a frontier model and an open source one for most uses including creating software.
> The benefits we get from checking in with other humans, like error correction, and delegation can all be done better by AI.
Not this generation of AI though. It's a text predictor, not a logic engine - it can't find actual flaws in your code, it's just really good at saying things which sound plausible.
> I can tell from this statement that you don't have experience with claude-code.
I happen to use it on a daily basis. 4.6-opus-high to be specific.
The other day it surmised from (I assume) the contents of my clipboard that I want to do A, while I really wanted to B, it's just that A was a more typical use case. Or actually: hardly anyone ever does B, as it's a weird thing to do, but I needed to do it anyway.
> but it is indistinguishable from actual reasoning
I can distinguish it pretty well when it makes mistakes someone who actually read the code and understood it wouldn't make.
Mind you: it's great at presenting someone else's knowledge and it was trained on a vast library of it, but it clearly doesn't think itself.
Oh, please. There’s always a way to blame the user, it’s a catch-22. The fact is that coding agents aren’t perfect and it’s quite common for them to fail. Refer to the recent C-compiler nonsense Anthropic tried to pull for proof.
It fails far less often than I do at the cookie cutter parts of my job, and it’s much faster and cheaper than I am.
Being honest; I probably have to write some properly clever code or do some actual design as a dev lead like… 2% of my time? At most? The rest of the code related work I do, it’s outperforming me.
Now, maybe you’re somehow different to me, but I find it hard to believe that the majority of devs out there are balancing binary trees and coming up with shithot unique algorithms all day rather than mangling some formatting and dealing with improving db performance, picking the right pattern for some backend and so on style tasks day to day.
What you're describing is not finding flaws in code. It's summarizing, which current models are known to be relatively good at.
It is true that models can happen to produce a sound reasoning process. This is probabilistic however (moreso than humans, anyway).
There is no known sampling method that can guarantee a deterministic result without significantly quashing the output space (excluding most correct solutions).
I believe we'll see a different landscape of benefits and drawbacks as diffusion language models begin to emerge, and as even more architectures are invented and practiced.
I have a tentative belief that diffusion language models may be easier to make deterministic without quashing nearly as much expressivity.
This all sounds like the stochastic parrot fallacy. Total determinism is not the goal, and it not a prerequisite for general intelligence. As you allude to above, humans are also not fully deterministic. I don't see what hard theoretical barriers you've presented toward AGI or future ASI.
Did you just invent a nonsense fallacy to use as a bludgeon here? “Stochastic parrot fallacy” does not exist, and there actually quite a bit of evidence supporting the stochastic parrot hypothesis.
I haven't heard the stochastic parrot fallacy (though I have heard the phrase before). I also don't believe there are hard theoretical barriers. All I believe is that what we have right now is not enough yet. (I also believe autoregressive models may not be capable of AGI.)
Much of the space of artificial intelligence is based on a goal of a general reasoning machine comparable to the reasoning of a human. There are many subfields that are less concerned with this, but in practice, artificial intelligence is perceived to have that goal.
I am sure the output of current frontier models is convincing enough to outperform the appearance of humans to some. There is still an ongoing outcry from when GPT-4o was discontinued from users who had built a romantic relationship with their access to it. However I am not convinced that language models have actually reached the reliability of human reasoning.
Even a dumb person can be consistent in their beliefs, and apply them consistently. Language models strictly cannot. You can prompt them to maintain consistency according to some instructions, but you never quite have any guarantee. You have far less of a guarantee than you could have instead with a human with those beliefs, or even a human with those instructions.
I don't have citations for the objective reliability of human reasoning. There are statistics about unreliability of human reasoning, and also statistics about unreliability of language models that far exceed them. But those are both subjective in many cases, and success or failure rates are actually no indication of reliability whatsoever anyway.
On top of that, every human is different, so it's difficult to make general statements. I only know from my work circles and friend circles that most of the people I keep around outperform language models in consistency and reliability. Of course that doesn't mean every human or even most humans meet that bar, but it does mean human-level reasoning includes them, which raises the bar that models would have to meet. (I can't quantify this, though.)
There is a saying about fully autonomous self driving vehicles that goes a little something like: they don't just have to outperform the worst drivers; they have to outperform the best drivers, for it to be worth it. Many fully autonomous crashes are because the autonomous system screwed up in a way that a human would not. An autonomous system typically lacks the creativity and ingenuity of a human driver.
Though they can already be more reliable in some situations, we're still far from a world where autonomous driving can take liability for collisions, and that's because they're not nearly as reliable or intelligent enough to entirely displace the need for human attention and intervention. I believe Waymo is the closest we've gotten and even they have remote safety operators.
It's not enough for them to be "better" than a human. When they fail they also have to fail in a way that is legible to a human. I've seen ML systems fail in scenarios that are obvious to a human and succeed in scenarios where a human would have found it impossible. The opposite needs to be the case for them to be generally accepted as equivalent, and especially the failure modes need to be confined to cases where a human would have also failed. In the situations I've seen, customers have been upset about the performance of the ML model because the solution to the problem was patently obvious to them. They've been probably more upset about that than about situations where the ML model fails and the end customer also fails.
It's roughly why I think this way, along with a statement that I don't have objective citations. So sure, it's not a citation. I even said as much, right in the middle there.
Nothing you've said about reasoning here is exclusive to LLMs. Human reasoning is also never guaranteed to be deterministic, excluding most correct solutions. As OP says, they may not be reasoning under the hood but if the effect is the same as a tool, does it matter?
I'm not sure if I'm up to date on the latest diffusion work, but I'm genuinely curious how you see them potentially making LLMs more deterministic? These models usually work by sampling too, and it seems like the transformer architecture is better suited to longer context problems than diffusion
The way I imagine greedy sampling for autoregressive language models is guaranteeing a deterministic result at each position individually. The way I'd imagine it for diffusion language models is guaranteeing a deterministic result for the entire response as a whole. I see diffusion models potentially being more promising because the unit of determinism would be larger, preserving expressivity within that unit. Additionally, diffusion language models iterate multiple times over their full response, whereas autoregressive language models get one shot at each token, and before there's even any picture of the full response. We'll have to see what impact this has in practice; I'm only cautiously optimistic.
I guess it depends on the definition of deterministic, but I think you're right and there's strong reason to expect this will happen as they develop. I think the next 5 - 10 years will be interesting!
And not this or any existing generation of people. We're bad a determining want vs need, being specific, genericizing our goals into a conceptual framework of existing patterns and documenting & explaining things in a way that gets to a solid goal.
The idea that the entire top down processes of a business can be typed into an AI model and out comes a result is again, a specific type of tech person ideology that sees the idea of humanity as an unfortunate annoyance in the process of delivering a business. The rest of the world see's it the other way round.
Absolutely nuts, I feel like I'm living in a parallel universe. I could list several anecdotes here where Claude has solved issues for me in an autonomous way that (for someone with 17 years of software development, from embedded devices to enterprise software) would have taken me hours if not days.
To the nay sayers... good luck. No group of people's opinions matter at all. The market will decide.
I think it’s just fear, I sure know that after 25 years as a developer with a great salary and throughout all that time never even considering the chance of ever being unemployable I’m feeling it too.
I think some of us come to terms with it in different ways.
I wonder if the parent comments remark is a communication failure or pedantry gone wrong, because like you, claude-code is out there solving real problems and finding and fixing defects.
A large quantity of bugs as raised are now fixed by claude automatically from just the reports as written. Everything is human reviewed and sometimes it fixes it in ways I don't approve, and it can be guided.
It has an astonishing capability to find and fix defects. So when I read "It can't find flaws", it just doesn't fit my experience.
I have to wonder if the disconnect is simply in the definition of what it means to find a flaw.
But I don't like to argue over semantics. I don't actually care if it is finding flaws by the sheer weight of language probability rather than logical reasoning, it's still finding flaws and fixing them better than anything I've seen before.
I can't control random internet people, but within my personal and professional life, I see the effective pattern of comparing prompts/contexts/harnesses to figure out why some are more effective than others (in fact tooling is being developed in the AI industry as a whole to do so, claude even added the "insights" command).
I feel that many people that don't find AI useful are doing things like, "Are there any bugs in this software?" rather than developing the appropriate harness to enable the AI to function effectively.
It's also literally factually incorrect. Pretty much the entire field of mechanistic interpretability would obviously point out that models have an internal definition of what a bug is.
> Thus, we concluded that 1M/1013764 represents a broad variety of errors in code.
(Also the section after "We find three different safety-relevant code features: an unsafe code feature 1M/570621 which activates on security vulnerabilities, a code error feature 1M/1013764 which activates on bugs and exceptions")
This feature fires on actual bugs; it's not just a model pattern matching saying "what a bug hunter may say next".
(Not GP) There was a well recognized reproducibility problem in the ML field before LLM-mania, and that's considering published papers with proper peer-reviews. The current state of afairs in some ways is even less rigourous than that, and then some people in the field feel free to overextend their conclusions into other fields like neurosciences.
Current LLMs do not think. Just because all models anthropomorphize the repetitive actions a model is looping through does not mean they are truly thinking or reasoning.
On the flip side the idea of this being true has been a very successful indirect marketing campaign.
While I agree, if you think that AI is just a text predictor, you are missing an important point.
Intelligence, can be borne of simple targets, like next token predictor. Predicting the next token with the accuracy it takes to answer some of the questions these models can answer, requires complex "mental" models.
Dismissing it just because its algorithm is next token prediction instead of "strengthen whatever circuit lights up", is missing the forest for the trees.
I think it all depends on the use case and a luck factor.
Sometimes I instruct copilot/claude to do a development (stretching it's capabilities), and it does amazingly well. Mind you that this is front-end development, so probably one of the more ideal use-cases. Bugfixing also goes well a lot of times.
But other times, it really struggles, and in the end I have to write it by hand. This is for more complex or less popular things (In my case React-Three-Fiber with skeleton animations).
So I think experiences can vastly differ, and in my environment very dependent on the case.
One thing is clear: This AI revolution (deep learning) won't replace developers any time soon. And when the next revolution will take place, is anyones guess. I learned neural networks at university around 2000, and it was old technology then.
I view LLM's as "applied information", but not real reasoning.
Ok, I'll bite. Let's assume a modern cutting edge model but even with fairly standard GQA attention, and something obviously bigger than just monosemantic features per neuron.
Based on any reasonable mechanistic interpretability understanding of this model, what's preventing a circuit/feature with polysemanticity from representing a specific error in your code?
---
Do you actually understand ML? Or are you just parroting things you don't quite understand?
Polysemantic features in modern transformer architectures (e.g., with grouped-query attention) are not discretely addressable, semantically stable units but superposed, context-dependent activation patterns distributed across layers and attention heads, so there is no principled mechanism by which a single circuit or feature can reliably and specifically encode “a particular code error” in a way that is isolable, causally attributable, and consistently retrievable across inputs.
---
Way to go in showing you want a discussion, good job.
Hint: the first paper is titled "Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet" and you can ctrl-f for "We find three different safety-relevant code features: an unsafe code feature 1M/570621 which activates on security vulnerabilities, a code error feature 1M/1013764 which activates on bugs and exceptions"
Who said I want a discussion? I want ignorant people to STOP talking, instead of talking as if they knew everything.
Your entire argument is derived from a pseudoscientific field without any peer-reviewed research. Mechanistic interpretability is a joke invented by AI firms to sell chatbots.
Ok, let's chew on that. "reasonable mechanistic interpretability understanding" and "semantic" are carrying a lot of weight. I think nobody understands what's happening in these models -irrespective of narrative building from the pieces. On the macro level, everyone can see simple logical flaws.
> On the macro level, everyone can see simple logical flaws.
Your argument applies to humans as well. Or are you saying humans can't possibly understand bugs in code because they make simple logical flaws as well? Does that mean the existence of the Monty Hall Problem shows that humans cannot actually do math or logical reasoning?
> do you know what "Mechanistic Interpretability Researcher" means? Because that would be a fairly bold statement if you were aware of that.
The mere existence of a research field is not proof of anything except "some people are interested in this". Its certainly doesn't imply that anyone truly understands how LLMs process information, "think", or "reason".
As with all research, people have questions, ideas, theories and some of them will be right but most of them are bound to be wrong.
You’re committing the classic fallacy of confusing mechanics with capabilities. Brains are just electrons and chemicals moving through neural circuits. You can’t infer constraints on high-level abilities from that.
This goes both ways. You can't assume capabilities based on impressions. Especially with LLMs, which are purpose built to give an impression of producing language.
Also, designers of these systems appear to agree: when it was shown that LLMs can't actually do calculations, tool calls were introduced.
It's true that they only give plausible sounding answers. But let's say we ask a simple question like "What's the sum of two and two?" The only plausible sounding answer to that will be "four." It doesn't need to have any fancy internal understanding or anything else beyond prediction to give what really is the same answer.
The same goes for a lot of bugs in code. The best prediction is often the correct answer, being the highlighting of the error. Whether it can "actually find" the bugs—whatever that means—isn't really so important as whether or not it's correct.
It becomes important the moment your particular bug is on one hand typical, but has a non-typical reason. In such cases you'll get nonsense which you need to ignore.
Again - they're very useful, as they give great answers based on someone else's knowledge and vague questions on part of the user, but one has to remain vigilant and keep in mind this is just text presented to you to look as believable as possible. There's no real promise of correctness or, more importantly, critical thinking.
That is not exactly true. The brain does a lot of things that are not "pattern recognition".
Simpler, more mundane (not exactly, still incredibly complicated) stuff like homeostasis or motor control, for example.
Additionally, our ability to plan ahead and simulate future scenarios often relies on mechanisms such as memory consolidation, which are not part of the whole pattern recognition thing.
The brain is a complex, layered, multi-purpose structure that does a lot of things.
This assumes every individual is capable of succinctly communicating to the AI what they want. And the AI is capable of maintaining it as underlying platforms and libraries shift.
And that there is little value in reusing software initiated by others.
> This assumes every individual is capable of succinctly communicating to the AI what they want. And the AI is capable of maintaining it as underlying platforms and libraries shift.
I think there are people who want to use software to accomplish a goal, and there are people who are forced to use software. The people who only use software because the world around them has forced it on them, either through work or friends, are probably cognitively excluded from building software.
The people who seek out software to solve a problem (I think this is most people) and compare alternatives to see which one matches their mental model will be able to skip all that and just build the software they have in mind using AI.
> And that there is little value in reusing software initiated by others.
I think engineers greatly over-estimate the value of code reuse. Trying to fit a round peg in a square hole produces more problems than it solves.
A sign of an elite engineer is knowing when to just copy something and change it as needed rather than call into it.
Or to re-implement something because the library that does it is a bad fit.
The only time reuse really matters is in network protocols. Communication requires that both sides have a shared understanding.
>The only time reuse really matters is in network protocols. Communication requires that both sides have a shared understanding.
A lot of things are like network protocols. Most things require communication. External APIs, existing data, familiar user interfaces, contracts, laws, etc.
Language itself (both formal and natural) depends on a shared understanding of terms, at least to some degree.
AI doesn't magically make the coordination and synchronisation overhead go away.
Also, reusing well debugged and battle tested code will always be far more reliable than recreating everything every time anything gets changed.
Even within a single computer or program, there is need for communication protocols and shared understanding - such as types, data schema, function signatures. It's the interface between functions, programs, languages, machines.
It could also be argued that "reuse" doesn't necessarily mean reusing the actual code as material, but reusing the concepts and algorithms. In that sense, most code is reuse of some previous code, written differently every time but expressing the same ideas, building on prior art and history.
That might support GP's comment that "code reuse" is overemphasized, since the code itself is not what's valuable, what the user wants is the computation it represents. If you can speak to a computer and get the same result, then no code is even necessary as a medium. (But internally, code is being generated on the fly.)
I think we shouldn't get too hung up on specific artifacts.
The point is that specifying and verifying requirements is a lot of work. It takes time and resources. This work has to be reused somehow.
We haven't found a way to precisely specify and verify requirements using only natural language. It requires formal language. Formal language that can be used by machines is called code.
So this is what leads me to the conclusion that we need some form of code reuse. But if we do have formal specifications, implementations can change and do not necessarily have to be reused. The question is why not.
This reframes the whole conversation. If implementations are cheap to regenerate, specifications become the durable artifact.
Something like TLA+ model checking lets you verify that a protocol maintains safety invariants across all reachable states, regardless of who wrote the implementation. The hard part was always deciding what "correct" means in your specific domain.
Most teams skip formal specs because "we don't have time." If agents make implementations nearly free, that excuse disappears. The bottleneck shifts from writing code to defining correctness.
> I think there are people who want to use software to accomplish a goal, and there are people who are forced to use software.
Typically people feel they're "forced" to use software for entirely valid reasons, such as said software being absolutely terrible to use. I'm sure that most people like using software that they feel like actually helps rather than hinders them.
> I think engineers greatly over-estimate the value of code reuse[...]The only time reuse really matters is in network protocols.
The whole idea of an OS is code reuse (and resources management). No need to setup the hardware to run your application. Then we have a lot of foundational subsystems like graphics, sound, input,... Crafting such subsystems and the associated libraries are hard and requires a lot of design thinking.
no but if the old '10x developer' is really 1 in 10 or 1 in 100, they might just do fine while the rest of us, average PHP enjoyers, may go to the wayside
>This assumes every individual is capable of succinctly communicating to the AI what they want. And the AI is capable of maintaining it as underlying platforms and libraries shift.
It's true that at first not everyone is just as efficient, but I'd be lying if I were to claim that someone needs a 4-year degree to communicate with LLM's.
Communication overhead between humans is real, but it's not just inefficiency, it's also where a lot of the problem-finding happens. Many of the biggest failures I've seen weren't because nobody could type the code fast enough, but because nobody realized early enough that the thing being built was wrong, brittle or solving the wrong problem
> Many of the biggest failures I've seen weren't because nobody could type the code fast enough, but because nobody realized early enough that the thing being built was wrong, brittle or solving the wrong problem
Around 99% of biggest failures come from absent, shitty management prioritizing next quarter over long strategy. YMMV.
> We pay huge communication/synchronization costs to eek out mild speed ups on projects by adding teams of people.
Something Brooks wrote about 50 years ago, and the industry has never fully acknowledged. Throw more bodies at it, be they human bodies or bot agent bodies.
The point of the mythical man month is not that more people are necessarily worse for a project, it's just that adding them at the last minute doesn't work, because they take a while to get up to speed and existing project members are distracted while trying to help them.
It's true that a larger team, formed well in advance, is also less efficient per person, but they still can achieve more overall than small teams (sometimes).
Interesting point. And from the agents point of view, it’s always joining at the last minute, and doesn’t stick around longer than its context window. There’s a lesson in there maybe…
The context window is the onboarding period. Every invocation is a new hire reading the codebase for the first time.
This is why architecture legibility keeps getting more important. Clean interfaces, small modules, good naming. Not because the human needs it (they already know the codebase) but because the agent has to reconstruct understanding from scratch every single time.
Brooks was right that the conceptual structure is the hard part. We just never had to make it this explicit before.
But there is a level of magnitude difference between coordinating AI agents and humans - the AIs are so much faster and more consistent than humans, that you can (as Steve Yegge [0] and Nicholas Carlini [1] showed) have them build a massive project from scratch in a matter of hours and days rather than months and years. The coordination cost is so much lower that it's just a different ball game.
I think we are. There's definitely been an uptick in "show HN" type posts with quite impressively complex apps that one person developed in a few weeks.
From my own experience, the problem is that AI slows down a lot as the scale grows. It's very quick to add extra views to a frontend, but struggles a lot more in making wide reaching refactors. So it's very easy to start a project, but after a while your progress slows significantly.
But given I've developed 2 pretty functional full stack applications in the last 3 months, which I definitely wouldn't have done without AI assistance, I think it's a fair assumption that lots of other people are doing the same. So there is almost certainly a lot more software being produced than there was before.
I think the proportion of new software that is novel has absolutely plummeted after the advent of AI. In my experience, generative AI will easily reproduce code for which there are a multitude of examples on GitHub, like TODO CRUD React Apps. And many business problems can be solved with TODO CRUD React Apps (just look at Excel’s success), but not every business problem can be solved by TODO CRUD React Apps.
As an analogy: imagine if someone was bragging about using Gen AI to pump out romantasy smut novels that were spicy enough to get off to. Would you think they’re capable of producing the next Grapes of Wrath?
It’s been a minute and a half and I don’t see the evidence you can task an agent swarm to produce useful software without your input or review. I’ve seen a few experiments that failed, and I’ve seen manic garbage, but not yet anything useful outside of the agent operators imagination.
Agent swarms are what, a couple of months old? What are you even talking about. Yes, people/humans still drive this stuff, but if you think there isn't useful software out there that can be handily implemented with current gen agents that need very little or no review, then I don't know what to tell you, apart from "you're mistaken". And I say that as someone who uses three tools heavily but has otherwise no stake in them. The copium in this space is real. Everyone is special and irreplaceable, until another step change pushes them out.
The next thing after agent swarms will be swarm colonies and people will go "it's been a month since agentic swarm colonies, give it a month or two". People have been moving the goal posts like that for a couple years now, it's starting to grow stale. This is like self driving cars which were going to be workingin 2016 and replace 80% of drivers by 2017, all over again. People falling for hype instead of admitting that while it appears somewhat useful, nobody has any clue if it's 97% useful or just 3% useful but so far it's looking like the later.
I work for one of those enterprises with lots of people trying out AI (thankfully leadership is actually sane, no mandates that you have to use it, just giving devs access to experiment with the tools and see what happens). Lots of people trying it out in earnest, lots of newsletters about new techniques and all that kinda stuff. Lots of people too, so there's all sorts of opinions from very excited to completely indifferent.
Precisely 0 projects are making it out any faster or (IMO more importantly) better. We have a PR review bot clogging up our PRs with fucking useless comments, rewriting the PR descriptions in obnoxious ways, that basically everyone hates and is getting shut off soon. From an actual productivity POV, people are just using it for a quick demo or proof of concept here and there before actually building the proper thing manually as before. And we have all the latest and greatest techniques, all the AGENTS.mds and tool calling and MCP integrations and unlimited access to every model we care to have access to and all the other bullshit that OpenAI et al are trying to shove on people.
It's not for a lack of trying, plenty of people are trying to make any part of it work, even if it's just to handle the truly small stuff that would take 5 minutes of work but is just tedious and small enough to be annoying to pick up. It's just not happening, even with extremely simple tasks (that IMO would be better off with a dedicated, small deterministic script) we still need human overview because it often shits the bed regardless, so the effort required to review things is equal or often greater than just doing the damn ticket yourself.
My personal favorite failure is when the transcript bots just... Don't transcript random chunks of the conversation, which can often lead to more confusion than if we just didn't have anything transcribed. We've turned off the transcript and summarization bots, because we've found 9/10 times they're actively detrimental to our planning and lead us down bad paths.
I build a code reviewer based on the claude code sdk that integrates with gitlab, pretty straightforward. The hard work is in the integration, not the review itself. That is taken care of with SDK.
Devs, even conservative ones, like it. I’ve built a lot of tooling in my life, but i never had the experience that devs reach out to me that fast because it is ‘broken’. (Expired token or a bug for huge MRs)
I have barely downloaded any apps in the last 5-10 years except some necessary ones like bank apps etc. Who even needs that garbage? Steam also has tons of games but 80% make like no money at all and no one cares. Just piles of garbage. We already have limited hours per day and those are not really increasing so I wonder where are the users.
> One of the tips, especially when using Claude Code, is explictly ask to create a "tasks", and also use subagents. For example I want to validate and re-structure all my documentation - I would ask it to create a task to research state of my docs, then after create a task per specific detail, then create a task to re-validate quality after it has finished task.
Which sounds pretty much the same as how work is broken down and handed out to humans.
Yes, but you can do this at the top level, and then have AI agents do this themselves for all the low level tasks, which is then orders of magnitude faster than with human coordination.
Far from everyone are cut out to be programmers, the technical barrier was a feature if anything.
There's a kind of mental discipline and ability to think long thoughts, to deal with uncertainty; that's just not for everyone.
What I see is mostly everyone and their gramps drooling at the idea of faking their way to fame and fortune. Which is never going to work, because everyone is regurgitating the same mindless crap.
Remember when Visual Basic was making everyone a programmer too?
(btw, warm fuzzies for VB since that's what I learned on! But ultimately, those VB tools business people were making were:
1) Useful, actually!
2) Didn't replace professional software. Usually it'd hit a point where if it needed to evolve past its initial functionality it probably required an actual software developer. (IE, not using Access as a database and all the other eccentricities of VB apps at that time)
This looks like the same problem as when the first page layout software came out.
It looked to everyone like a huge leap into a new world word processing applications could basically move around blocks of text to be output later, maybe with a few font tags, then this software came out that wow actually showed the different fonts, sizes, and colors on the screen as you worked! With apps like "Pagemaker" everyone would become their own page designers!
It turned out that everyone just turned out floods of massively ugly documents and marketing pieces that looked like ransom notes pasted together from bits of magazines. Years of awfulness.
The same is happening now as we are doomed to endure years AI slop in everything from writing to apps to products to vending machines an entire companies — everyone and their cousin is trying to fully automate it.
Ultimately it does create an advance and allows more and better work to be done, but only for people who have a clue about what they are doing, and eventually things settle at a higher level where the experts in each field take the lead.
I think I know what you mean, and I do recall once seeing "this experience will leverage me" as indicating that something will be good for a person, but my first thought when seeing "x will leverage y" is that x will step on top of y to get to their goal, which does seem apt here.
>In the end it will be the users sculpting formal systems like playdoh.
Yet another person who thinks that there is a silver bullet for complexity. The mythical intelligent machines that from poorly described natural language can erect flawless complex system is like the philosopher's stone of our time.
I'm rounding the corner on a ground's up reimplementation of `nix` in what is now about 34 hours of wall clock time, I have almost all of it on `wf-record`, I'll post a stream, but you can see the commit logs here: https://github.com/straylight-software/nix/tree/b7r6/correct...
Everyone has the same ability to use OpenRouter, I have a new event loop based on `io_uring` with deterministic playbook modeled on the Trinity engine, a new WASM compiler, AVX-512 implementations of all the cryptography primitives that approach theoretical maximums, a new store that will hit theoretical maximums, the first formal specification of the `nix` daemon protocol outside of an APT, and I'm upgrading those specifications to `lean4` proof-bearing codegen: https://github.com/straylight-software/cornell.
34 hours.
Why can I do this and no one else can get `ca-derivations` to work with `ssh-ng`?
Here's another colleague with a Git forge that will always work and handle 100x what GitHub does per infrastructure dollar while including stacked diffs and Jujitsu support as native in about 4 days: https://github.com/straylight-software/strayforge
Here's another colleague and a replacement for Terraform that is well-typed in all cases and will never partially apply an infrastructure change in about 4 days: https://github.com/straylight-software/converge
/tangent i've always like the word "straylight", I use to run a fansite for a local band and the site was called straylight6. This was maybe 20 years ago.
It has average taste based on the code it was trained on. For example, every time I attempted to polish the UX it wanted to add a toast system, I abhor toasts as a UX pattern. But it also provided elegant backend designs I hadn't even considered.
> especially in the long run, at least in software
"at least in software".
Before that happens, the world as we know it will already have changed so much.
Programmers have already automated many things, way before AI, and now they've got a new tool to automate even more thing. Sure in the end AI may automate programmers themselves: but not before oh-so-many people are out of a job.
A friend of mine is a translator: translates tolerates approximation. Translation tolerates some level of bullshittery. She gets maybe 1/10th the job she used to get and she's now in trouble. My wife now does all he r SMEs' websites all by herself, with the help of AI tools.
A friend of my wife she's a junior lawyer (another domain where bullshitting flies high) and the reason for why she was kicked out of her company: "we've replaced you with LLMs". LLMs are the ultimate bullshit producers: so it's no surprise junior lawyers are now having a hard time.
In programming a single character is the difference between a security hole or no security hole. There's a big difference between something that kinda works but is not performant and insecure and, say, Linux or Git or K8s (which AI models do run on and which AI didn't create).
The day programmers are replaced shall only come after AI shall have disrupted so many other jobs that it should be the least of our concerns.
Translators, artists (another domain where lots of approximative full-on bullshit is produced), lawyers (juniors at least) even, are having more and more problems due to half-arsed AI outputs coming after their jobs.
It's all the bullshitty jobs where bullshit that tolerates approximation is the output that are going to be replaced first. And the world is full of bullshit.
But you don't fly a 767 and you don't conceive a machine that treats brain tumors with approximations. This is not bullshit.
There shall be non-programmers with pitchforks burning datacenters or ubiquitous UBI way before AI shall have replaced programmers.
That it's an exoskeleton for people who know what they're doing rings very true: it's yet another superpower for devs.
> We pay huge communication/synchronization costs to eek out mild speed ups on projects by adding teams of people.
I am surprised at how little this is discussed and how little urgency there is in fixing this if you still want teams to be as useful in the future.
Your standard agile ceremonies were always kind of silly, but it can now take more time to groom work than to do it. I can plausibly spend more time scoring and scoping work (especially trivial work) than doing the work.
It's always been like that. Waterfall development was worse and that's why the Agilists invented Agile.
YOLOing code into a huge pile at top speed is always faster than any other workflow at first.
The thing is, a gigantic YOLO'd code pile (fake it till you make it mode) used to be an asset as well as a liability. These days, the code pile is essentially free - anyone with some AI tools can shit out MSLoCs of code now. So it's only barely an asset, but the complexity of longer term maintenance is superlinear in code volume so the liability is larger.
> I wonder whether the vaccine content matters at all in current vaccines.
The target does matter, that is the basis for the whole technology, and the thing most predictive of efficacy.
That's why the flu shots often don't work and the shots for smallpox and measles do, the flu is a more rapidly mutating target.
Going crazy with the adjuvants was popular during the pandemic when it became clear that the virus had mutated (the target protein), but no one wanted to do R&D for a new target.
Counting white blood cells became a proxy for efficacy, and you can manipulate that stat with adjuvants.
Yeah this is more likely than cancer, and is a potential side effect of anything that stimulates the immune system, including real antigen-carrying vaccines.
I'm less certain, many if not most lung cancers seems to follow chronic inflammation in the lungs.
The classic example is asbestos related mesothelioma. "Frustrated phagocytosis" is the name for the way macrophages become locked in a never ending spiral of eat, die poison loops around the asbestos.
Do we really want macrophages to go into high gear? Will we make sure no one who has it has been exposed every to any asbestos?
What about other triggers of frustrated phagocytosis? People who commute by subway (tiny metal particles).
The point isn't to say that this is a bad idea necessarily but that I'm not sure this sounds so much safer than regular vaccination.
What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++.
Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory.
Unless you have a system that says "no" a lot, and occasionally removes features, programming languages decay, and the game has been (historically, before LLMs) to pick a language that would be in the sweet spot for the time that you need to use it, while keeping your eye out for something else to switch to once it becomes sufficiently unusable.
> What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory.
Dear lord that is not the case. The C++ standardization process is extremely different from Rust's specification process, and the resulting pathologies are extremely dissimilar. Hell, C is fairly close to C++ in terms of process, and yet it still has its own set of pathologies.
The C++ committee is dominated not by experts on compiler implementation, but by people looking to get their own proposals incorporated into the standard, and is structurally organized in such a way that it can be difficult for any group to feel empowered to actually reject a feature. It should be noted that in the most recent batch of C++ papers, there was effectively an implementers' revolt: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39....
The Rust proposal process is much more ponderous, and when you take into account the lag between an accepted RFC and implementation and stabilization (and the fact that some accepted RFCs turn out to be unworkable and effectively get backed out without ever being stabilized), it's pretty clear that the actual development process is night-and-day different. For example, the Try trait in Rust still has yet to be stabilized, despite the RFC proposing it being introduced over nine years ago and a v2 RFC being accepted five years ago.
This kind of "but for us it's different" thinking is a little amusing.
I don't care about the implementation process or the RFCs or what-have-you.
If there is a democratic committee of humans that decides what goes in, and there is no bias for minimalism (e.g. 1/3 could strike down a proposal instead of 1/2) then the process will tend towards bloat.
The Rust RFC process requires essentially unanimous consent: there's no formal voting procedure, but the various teams can block any feature from going in.
But sure, keep on saying they're basically the same thing.
Rust intentionally keeps its std library small and makes no promises about ABI; it seems to have resisted a lot of pressure to do the opposite from C++ fanatics. I don't agree that the C++ path is inevitable.
Even Go is encountering the same fate, albeit slower. It’s nearly impossible to remove a feature once it has seen adoption, especially without an alternative; whereas there are always patterns that are greatly simplified by some new feature, and when a language becomes large, these patterns become common enough that the absence of said feature becomes annoying.
Suspiciously, after Rob Pike retired from the project, the amount of language and standard library changes skyrocketed.
Many people now trying to get their thing into the language so they can add it to their list of accomplishments.
Clear evidence that you need someone saying "no" often.
Is there ever a successful programming language that occasionally removes features? Like, not just a big, one-time backward-incompatible upgrade, but occasional feature removal?
Python removes features all the time in 3.x releases. For example, I was not a fan of the distutils removal in 3.12 which broke many legacy but otherwise functional packages. Deprecated functions and classes are also removed from packages regularly.
Java, since Java 9 deprecated for removal really means it.
.NET, the whole .NET Framework to modern (core) .NET migration, left several parts behind, the foor loop semantics change on C#, introduction of field keyword, and with.
Can someone, who knows computer graphics, explain why the old library had so many issues with flickering and black triangles or rectangles flashing on the app, and why the new library is expected to not have those same problems?
Product management might be the worst meme in the industry.
Hire people who have never used the product and don't think like or accurately represent our users, then let them allocate engineering resources and gate what ships. What could go wrong?
It should be a fad gone by at this point, but people never learn.
Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month.
Just saved you thousands or millions in salaries, and you have a better chance of making things that your users actually want.
Good PM's are extremely good at understanding users, and use soft-skills to make the rest of the org focus on users more. I've worked with a couple, and they've added an enormous amount of value, sometimes steering teams of dozens of engineers in a more productive direction.
The problem is, it's hard to measure how good a PM is, even harder than for engineers. The instinct is to use product KPI's to do so, but especially at BigTech company, distribution advantages and traction of previous products will be the dominant factor here, and the best way of raising many product KPI's are actually user-hostile. Someone who has been a successful FAANG engineer who goes to a startup might lean towards over-engineering, but at least they should be sharp on the fundamentals. Someone who has been a successful FAANG PM might actually have no idea how to get PMF.
> Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month
This is actually a great idea, but what will happen is this socially competent engineer will soon have a new full-time job gathering those insights, coalescing them into actionable product changes, persuading the rest of the org to adopt those changes, and making sure the original user insights make it into the product. Voila: you've re-invented product management.
But I actually think it's good to source PM's from people who've been engineers for a few years. PM's used to come from a technical background; Google famously gave entry-level coding tests to PM's well into the '10s. I dunno when it became more fashionable to hire MBA's and consultants into this role, but it may have been a mistake.
This is a names vs. structure thing. For a moment, taboo the term product manager.
What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want.
If they aren't great at it, they can go back to engineering.
We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
The conventional wisdom (bad meme) is going to the labor market with a search term for people who claim to know what the users want, any user, any problem, doesn't matter. These people are usually incompetent and have never written software. Then hiring 1 and potentially more of the people that respond to the shibboleth.
If you want the first case, then you can't say "product manager" because people will automatically do the second case.
> What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
It doesn't have to be the most socially competent engineer to gather feedback. Having the engineering team sit with the target users gives so much insight into how the product is being used.
I once worked on an administrative tool at a financial institution. There were lots of pain points, as it started as a dev tool that turned into a monstrosity for the support staff. We asked to have a meeting with some reps who were literally 2 floors below us. Having the reps talk as they worked with the tool in real time over 1 hour was worth more than a year's worth of feedback that trickled in. It's one thing to solicit feedback. It's another to see how idiosyncrasies shape how products get used.
Putting on a PM hat is something I've been doing regularly in my engineering career over the last quarter century. Even as a junior (still in college!) at my first job I was thinking about product, in no small part because there were no PMs in sight. As I grew through multiple startups and eventually bigger brand name tech companies, I realized that understanding how the details work combined with some sense of what users actually want and how they behave is a super power. With AI this skillset has never been more relevant.
I agree your assessment about the value of good PMs. The issue, in my experience, is that only about 20% (at most) are actually good. 60% are fine and can be successful with the right Design and Engingeering partners. And 20% should just be replaced by AI now so we can put the proper guardrails around their opinions and not be misled by their charisma or whatever other human traits enabled them to get hired into a job they are utterly unqualified for.
I have worked with some really really good product managers.
But not lately. Lately it’s been people who have very little relevant domain expertise, zero interest in putting in the time to develop said expertise beyond just cataloguing and regurgitating feedback from the customers they like most on a personal level, and seem to mostly have only been selected for the position because they are really good at office politics.
But I think it’s not entirely their fault. What I’ve also noticed is that, when I was on teams with really elective product managers, we also had a full time project manager. That possibly freed up a lot of the product manager’s time. One person to be good at the tactical so the other can be good at the strategic.
Since project managers have become passé, though, I think the product managers are just stretched too thin. Which sets up bad incentive structures: it’s impossible to actually do the job well anymore, so of course the only ones who survive are the office politicians who are really good at gladhanding the right people and shifting blame when things don’t go well.
There are individuals who have good taste for products in certain domains.
Their own preferences are an accurate approximation for those of the users.
Those people might add value when they are given control of the product.
That good taste doesn't translate between domains very often.
Good taste for developer tools doesn't mean good taste for a video game inventory screen.
And that's the crux of the problem.
There is a segment of the labor market calling themselves "product manager" who act like good taste is domain independent, and spread lies about their importance to the success of every business.
What's worse is that otherwise smart people (founders, executives) fall for it because they think hiring them is what they are supposed to do.
Over time, as more and more people realized that PM is a side door into big companies with lots of money, "Product Manager" became an imposter role like "Scrum Master".
Now product orgs are pretty much synonymous with incompetence.
Taste is pretty transferable, I think what you're talking about is intuition. The foundations of intuition are deeply understanding problems and the ability to navigate towards solutions related to those problems. Both of these are relatively domain-dependent. People can have intuition for how to do things but lack the taste to make those solutions feel right.
Taste on the other hand is about creating an overall feeling from a product. It's holistic and about coherence, where intuition is more bottom-up problem solving. Tasteful decisions are those that use restraint, that strike a particular tone, that say 'no' when others might say 'yes'. It's a lot more magical, and a lot rarer.
Both taste and intuition are ultimately about judgment, which is why they're often confused for one another. The difference is they approach problems from the opposite side; taste from above, intuition from below.
I agree with your assessment otherwise, PM can be a real smoke screen especially across domain and company stage.
The proportion of "really good" PMs on product engineering teams has to be less than 0.1%.
The counter to that is "the proportion of 'really good engineers' to product engineering teams has got to be in the single digits," and I would agree with that, as well.
The problem is what is incentivized to be built - most teams are working on "number go up?" revenue or engagement as a proxy to revenue "problems." Not "is this a good product that people actively enjoy using?" problems.
> Hire people who have never used the product and don't think like or accurately represent our users
In most of my engineering jobs, the Product Managers were much closer to our users than the engineers.
Good product managers are very valuable. There are a lot of bad ones carrying the product manager title because it was viewed as the easy way to get a job in tech without having to know how to program, but smart companies are getting better at filtering them out.
> Find your most socially competent engineer, and have them talk to users a couple times a month
Every single time I've seen this tried, it turns into a situation where one or two highly vocal customers capture the engineering team's direction and steer the product toward their personal needs. It's the same thing that happens when the sales people start feeding requests from their customers into the roadmap.
I've worked with some really good product managers, as well as some total duds. They all talked to customers on a regular basis. There is so much more to the job than that. Every time I think I understand a product manager's job completely, I see one fail in a way I hadn't thought about.
For example, I had one product manager who made themselves irrelevant because they wouldn't work with sales. The company needed to sell the product to pay us, and sales talked with potential buyers about what might swing their purchase decision and what they would pay extra for. Since the PM only talked to users and ignored sales when doing product design and product roadmaps, the way sales input got integrated into product development is that we frequently got top-down directives from management to prioritize one-off requests from sales over the roadmap. Needless to say, this didn't lead to a cohesive and easy-to-understand product.
Before I saw that PM failing, I hadn't thought about the relationship between product and sales.
This sentiment is going exactly against the trend right now. AI coding is making technically minded product manager's MORE powerful not less. When/if coding just because your ability to accurately describe what you want to build, the people yielding this skill are the ones who understand customer requirements, not the opposite.
> Find your most socially competent engineer,
These usually get promoted to product management anyway, so this isn't a new thought.
> This sentiment is going exactly against the trend right now.
It's not.
Engineers are having more and more minutia and busy work taken off their plate, now done by AI.
That allows them to be heads up more often, more of their cognitive capacity is directed towards strategy, design, quality.
Meanwhile, users are building more and more of their own tools in house.
Why pay someone when you can vibe code a working solution in a few minutes?
So product managers are getting squeezed out by smarter people below them moving into their cognitive space and being better at solving the problems they were supposed to be solving.
And users moving into their space by taking low hanging fruit away from them.
No more month long discussions about where to put the chart and what color it should be.
The user made their own dashboard and it calls into the API. What API? The one the PM doesn't understand and a single engineer maintains with the help of several LLMs.
If it's simple and easy: the user took it over, if it's complex: it's going to the smartest person in the room. That has never been the PM.
In my average experience, without interviewing management teams - my observation is that the "smartest person in the room" is rarely the one deciding anything.
This also depends on your definition on "smartest".
> This also depends on your definition on "smartest".
Which the parent conveniently left out a definition of. I sort of ignored that implication and went straight to the point - which is it doesn't matter if the PM is the smartest or not. What matters is who makes the decisions and typically the PM does.
> people who have never used the product and don't think like or accurately represent our users
I agree completely that these are the important qualifications to be setting direction for a product.
> Find your most socially competent engineer, and have them talk to users a couple times a month.
This doesn't necessarily follow from the above, but in Anthropic's case specifically, where the users are software engineers, it probably would have worked better than whatever they have going on now.
In general, it's probably better to have domain experts doing product management, as opposed to someone who is trained in product management.
The ability to reverse is very dependent on the transformation being well known, in this case it is deterministic and known with certainty.
Any algorithm to reverse motion blur will depend on the translation and rotation of the camera in physical space, and the best the algorithm could do will be limited by the uncertainty in estimating those values.
If you apply a fake motion blur like in photoshop or after effects then that could probably be reversed pretty well.
> and the best the algorithm could do will be limited by the uncertainty in estimating those values
That's relatively easy if you're assuming simple translation and rotation (simple camera movement), as opposed to a squiggle movement or something (e.g. from vibration or being knocked). Because you can simply detect how much sharper the image gets, and hone in on the right values.
I recall a paper from many years ago (early 2010s) describing methods to estimate the camera motion and remove motion blur from blurry image contents only. I think they used a quality metric on the resulting “unblurred” image as a loss function for learning the effective motion estimate. This was before deep learning took off; certainly today’s image models could do much better at assessing the quality of the unblurred image than a hand-crafted metric.
Naive self-interest is a characteristic of children.
You didn't stumble upon some ancient wisdom of another culture, you just matured and established a family, which your instincts tell you to put before yourself.
The West is individualistic, but all that means is that individuals choose their circle of concern. Without any further guidance, that means that innate instincts about who is important (family, close friends) dominate, rather than a forced narrative about the collective.
Kids do think about others and cooperate, they do have natural empathy and care too. A lot more in cooperative cultures where they are taught to be like that. Less in individualistic cultures where they are taught to not be empathetic. Even within West, there is range of individualism. Netherland is different then USA and both are different then Spain.
It is not just instinct that makes some people (including kids) dominant, it is also that they are being actively taught to act like that. The natural thing is for parents to teach kids own values, both in a planned and conscious way and in the "by the way" style.
Not the "West", obsessive single minded individualism is a US characteristic. All other western nations (read: Europe) realize that there is significant value to society and that to achieve things we need to work as a group.
Kids have very little agency to begin with, so looking out for #1 is a fully rational strategy from their POV. As an adult, you grow a lot more comfortable with your situation and it becomes natural to "expand the circle of concern" beyond oneself.
I think it has more to do with agency than age except that agency increases with age.
Look at prisoners, people dependent upon disability, people in authoritarian societies, you see all the same stuff. They're just more tactful about it because they're adults.
reply