> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO.
I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled, Domain-Driven Design, Implementing Domain-Driven Design, Design Patterns, The Art of Agile Software Development, 2nd Edition, Clean Architecture, Smalltalk Best Practice Patterns, and Tidy First?. I'm a far better software engineer than I was in 2024. I've also vibe coded [1] a whole lot of software [2], some good and some bad [3].
[1]: As defined in Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge, wherein you still take responsibility for the code you deliver.
Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.
The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.
Actually the opposite is the case. UI design was best when designers were systematic in their approach, employing concepts from human psychology and rigorously testing and timing how long it took to perform actions on the computer, optimizing for efficiency, discoverability, and ease of use. Today's UI designers copy from designs they've seen before, often poorly, and when they do apply data and metrics it's to bullshit KPIs like "engagement".
I think it all boils down to, which is higher risk, using AI too much, or using AI too little?
Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astounding that CEOs haven't made that connection yet).
The latter, you may be less productive than optimal, but might the hands-on training and fundamental understanding of the codebase make up for it in the long run?
Additionally, I personally find my best ideas often happen when knee deep in some codebase, hitting some weird edge case that doesn't fit, that would probably never come up if I was just reviewing an already-completed PR.
> my best ideas often happen when knee deep in some codebase
I notice that I get into this automatically during AI-assisted coding sessions if I don't lower my standards for the code. Eventually, I need to interact very closely with both the AI and the code, which feels similar to what you describe when coding manually.
I also notice I'm fresher because I'm not using many brainscycles to do legwork- so maybe I'm actually getting into more situations where I'm getting good ideas because I'm tackling hard problems.
So maybe the key to using AI and staying sharp is to refuse to sacrifice your good taste.
Yeah, I get this too. Still, I think sometimes being forced to grind on something will spur the "oh wait" moment that leads to new ways of thinking about things. Whereas when the LLM is doing the grinding, you don't see it. You just get a final PR with only the answer to the problem at hand, and you miss the bigger opportunity.
That said, maybe it's not a big deal. Kind of like way back when I moved from C++ to GC code, I remember I missed memory leaks, because having it all automatically taken care of for free felt like giving up control and encouraging of lazy practices and loose ends. Turns out it wasn't really a big deal at all.
It definitely comes up if you're just reviewing an already-"completed" PR. Even if you're not going to ship AI-generated code to prod (and I think that's a reasonable choice), it's often informative to give a high-level description of what you want to accomplish to a coding agent and see what it does in your codebase. You might find that the AI covered a particular edge case that you would have missed. You might find that even if the PR as a whole is slop.
Coaxed into dead-end architecture is the exact issue I have had when trying agentic coding. I find that I have the greatest success when I plan everything out and document the implementation plan as precisely as possible before handing it off to the agent. At which point, the hard part is already done. Generating the code was not really the bottleneck.
Using LLMs to generate documentation for the code that I write, explaining data sheets to me, and writing boilerplate code does save me a lot of time, though.
I see AI coding as something like project management. You could delegate all of the tasks to an LLM, or you could assign some to yourself.
If you keep some for yourself, there’s a possibility that you might not churn out as much code as quickly as someone delegating all programming to AI. But maybe shipping 45,000 lines a day instead of 50,000 isn’t that bad.
"they don’t produce useful layers of abstraction nor meaningful modularization. They don’t value conciseness or improving organization in a large code base. We have automated coding, but not software engineering"
Which frankly describes pretty much all real world commercial software projects I've been on, too.
Software engineering hasn't happened yet. Agents produce big balls of mud because we do, too.
i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN...
idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.
The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace myself.
> A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times!
It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.
Speaking just for myself, AI has allowed me to start doing projects that seemed daunting at first, as it automates much of the tedious act of actually typing code from the keyboard, and keeps me at a higher level.
But yes, I usually constrain my plans to one function, or one feature. Too much and it goes haywire.
I think a side benefit is that I think more about the problem itself, rather than the mechanisms of coding.
tl;dr - author cites a study from early 2025 which measured developer speed of “experienced open source developers” to be ~20% slower when supported by AI, while they’ve estimated to be ~20% faster.
Note: the study used sonnet-3.5 and sonnet-3.7; there weren’t any agents, deep research or similar tools available. I’d like to see this study done again with:
1. juniors ans mid-level engineers
2. opus-4.6 high and codex-5.2 xhigh
3. Tasks that require upfront research
4. Tasks that require stakeholder communication, which can be facilitated by AI
I’d be thrilled if that AI could finally make one of our most annoying stakeholders test the changes they were so eager to fast track, but hey, I might be surprised.
I think people got fatigued by reviewing already. Most code is correct that AI produces so you end up checking out eventually.
A lot of the time the issue isn't actually the code itself but larger architectural patterns. But realizing this takes a lot of mental work. Checking out and just accepting what exists, is a lot easier but misses subtleties that are important.
I suggest move the sanity check to the point of employing the parrot.
"Fixing defects down the road during testing costs 15x as much as fixing them during design, according to research from the IBM System Science Institute."
That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code:
Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via the products they are now giving almost entirely to coding agents.
It's not entirely surprising. You can prompt the AI to write code to pretty much any level of detail. You can tell it exactly what to output and it will copy character for character.
Of course at a certain point, you have to wonder if it would be faster to just type it than to type the prompt.
Anyways, if this was true in the sense they are trying to imply, why does Boris still have a job? If the agents are already doing 100% of the work, just have the product manager run the agents. Why are they actively hiring software developers??
Exactly. The fact that people laugh at the prediction like it's a joke when I and many others have been at 90%+ for a long time makes me question a lot of the takes here. Anyone serious about using LLMs would know it's nothing controversial to have it write most of the code.
And people claiming it's a lie are in for a rough awakening. I'm sure we will see a lot of posters on HN simply being too embarrassed to ever post again when they realize how off they were.
I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively.
The differences are subtle but those of
us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatically more efficient than the previous era? 1000%. Some of the things I’ve done in the past month I really didn’t think were possible. I was skeptical but I think a new era is upon us and everyone should be hustling to adapt.
My favorite analogy at the moment is that for awhile now we’ve been bowling and been responsible for knocking down
the pins ourselves. In this new world we are no longer the bowlers, rather we are the builders of bumper rails
that keep the new bowlers from landing in the gutter.
I think most of the issues with "vibe coding" is trusting the current level of LLM's with too much, as writing a hacky demo of a specific functionality is 1/10 as difficult as making a fully-fledged, dependable, scalable version of it.
Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional demo of a saas product, but they are far from being able to one-shot the entire engineering effort of a company like slack.
However, I don't see why the rate of improvement will not continue as it has. The current generation of LLM's haven't been event trained yet on NVidia's latest Blackwell chips.
I do agree that vibe-coding is like gambling, however that is besides the point that AI coding models are getting smarter at a rate that is not slowing down. Many people believe they will hit a sigmoid somewhere before they reach human intelligence, but there is no reason to believe that besides wishful thinking.
I think tech journalism needs to reframe its view of slot machines if it's to have a productive conversation about AI.
Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.
I’ve learned the hard way that in coding, every line matters. While learning Go for a new job, I realised I had been struggling because I overused LLMs and that slowed my learning. Every line we write reflects a sense of 'taste' and needs to be fully controlled and understood. You need a solid mental model of how the code is evolving. Tech CEOs and 'AI researchers' lack the practical experience to understand this, and we should stop listening to them about how software is actually built.
People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years.
Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.
Of course people think that, because that is exactly how those agents are being sold. If you tell management that this speeds up the easy part, typing the code, they are convinced you are using it wrong. They want to save 90% of software development cost and you are telling them that’s not possible.
>Anthropic CEO Dario Amodei predicted that by late 2025, AI would be writing 90% of all code
Was this actually a failed prediction? A article claiming with 0 proof that it failed is not good enough for me. With so many people generating 100% of their code using AI. It seems true to me.
78 comments
[ 2.7 ms ] story [ 75.4 ms ] threadFortunately, I've retired so I'm going focus on flooding the zone with my crazy ideas made manifest in books.
I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled, Domain-Driven Design, Implementing Domain-Driven Design, Design Patterns, The Art of Agile Software Development, 2nd Edition, Clean Architecture, Smalltalk Best Practice Patterns, and Tidy First?. I'm a far better software engineer than I was in 2024. I've also vibe coded [1] a whole lot of software [2], some good and some bad [3].
You can choose to grow in both areas.
[0]: https://kerrick.blog/articles/2025/kerricks-wager/
[1]: As defined in Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge, wherein you still take responsibility for the code you deliver.
[2]: https://news.ycombinator.com/item?id=46702093
[3]: https://news.ycombinator.com/item?id=46719500
Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astounding that CEOs haven't made that connection yet).
The latter, you may be less productive than optimal, but might the hands-on training and fundamental understanding of the codebase make up for it in the long run?
Additionally, I personally find my best ideas often happen when knee deep in some codebase, hitting some weird edge case that doesn't fit, that would probably never come up if I was just reviewing an already-completed PR.
I notice that I get into this automatically during AI-assisted coding sessions if I don't lower my standards for the code. Eventually, I need to interact very closely with both the AI and the code, which feels similar to what you describe when coding manually.
I also notice I'm fresher because I'm not using many brainscycles to do legwork- so maybe I'm actually getting into more situations where I'm getting good ideas because I'm tackling hard problems.
So maybe the key to using AI and staying sharp is to refuse to sacrifice your good taste.
That said, maybe it's not a big deal. Kind of like way back when I moved from C++ to GC code, I remember I missed memory leaks, because having it all automatically taken care of for free felt like giving up control and encouraging of lazy practices and loose ends. Turns out it wasn't really a big deal at all.
There is zero evidence that LLM's improve software developer productivity.
Any data-driven attempts to measure this give ambivalent results at best.
Using LLMs to generate documentation for the code that I write, explaining data sheets to me, and writing boilerplate code does save me a lot of time, though.
If you keep some for yourself, there’s a possibility that you might not churn out as much code as quickly as someone delegating all programming to AI. But maybe shipping 45,000 lines a day instead of 50,000 isn’t that bad.
Which frankly describes pretty much all real world commercial software projects I've been on, too.
Software engineering hasn't happened yet. Agents produce big balls of mud because we do, too.
Also, it prevents repetitive strain injury. At least, it does for me.
idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.
It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.
But yes, I usually constrain my plans to one function, or one feature. Too much and it goes haywire.
I think a side benefit is that I think more about the problem itself, rather than the mechanisms of coding.
Note: the study used sonnet-3.5 and sonnet-3.7; there weren’t any agents, deep research or similar tools available. I’d like to see this study done again with:
1. juniors ans mid-level engineers
2. opus-4.6 high and codex-5.2 xhigh
3. Tasks that require upfront research
4. Tasks that require stakeholder communication, which can be facilitated by AI
I’d be thrilled if that AI could finally make one of our most annoying stakeholders test the changes they were so eager to fast track, but hey, I might be surprised.
I would have thought sanity checking the output to be the most elementary next step.
A lot of the time the issue isn't actually the code itself but larger architectural patterns. But realizing this takes a lot of mental work. Checking out and just accepting what exists, is a lot easier but misses subtleties that are important.
"Fixing defects down the road during testing costs 15x as much as fixing them during design, according to research from the IBM System Science Institute."
https://fortune.com/2026/01/29/100-percent-of-code-at-anthro...
Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via the products they are now giving almost entirely to coding agents.
Of course at a certain point, you have to wonder if it would be faster to just type it than to type the prompt.
Anyways, if this was true in the sense they are trying to imply, why does Boris still have a job? If the agents are already doing 100% of the work, just have the product manager run the agents. Why are they actively hiring software developers??
https://job-boards.greenhouse.io/anthropic/jobs/4816198008
And people claiming it's a lie are in for a rough awakening. I'm sure we will see a lot of posters on HN simply being too embarrassed to ever post again when they realize how off they were.
The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatically more efficient than the previous era? 1000%. Some of the things I’ve done in the past month I really didn’t think were possible. I was skeptical but I think a new era is upon us and everyone should be hustling to adapt.
My favorite analogy at the moment is that for awhile now we’ve been bowling and been responsible for knocking down the pins ourselves. In this new world we are no longer the bowlers, rather we are the builders of bumper rails that keep the new bowlers from landing in the gutter.
Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional demo of a saas product, but they are far from being able to one-shot the entire engineering effort of a company like slack.
However, I don't see why the rate of improvement will not continue as it has. The current generation of LLM's haven't been event trained yet on NVidia's latest Blackwell chips.
I do agree that vibe-coding is like gambling, however that is besides the point that AI coding models are getting smarter at a rate that is not slowing down. Many people believe they will hit a sigmoid somewhere before they reach human intelligence, but there is no reason to believe that besides wishful thinking.
Not sure why we'd want a tool that generates so much of this for us.
Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.
People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years.
Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.
Was this actually a failed prediction? A article claiming with 0 proof that it failed is not good enough for me. With so many people generating 100% of their code using AI. It seems true to me.