The problem is that skill at coding is not exactly the same thing as skill at developing and maintaining software, and AI can help there as well, but a swarm of cowboy coder agents will get you to a legacy codebase very very quickly.
And even if the AI is better than most humans, the speed means that you get more defects and issues! If a human developer has a change failure rate of say 10%, (1 in 10 changes causes a defect or issue), and AI is twice as good and only introduces bugs 5% of the time, but submits 10x as many changes, then you go from 1 bug per unit of time to 5 bugs per unit of time, so your velocity is up 10x but your defect rate is up 5x...
That excellent post talks about searching for bugs in extant code, but a similar maxim applies to new code:
With AI, you can choose your position on the speed/quality trade-off curve. You can vibe code crap, you can guide/review more closely and get a higher quality product more slowly.
And that choice can extend past non-AI coding: with AI you can produce software even more slowly but even higher quality than you did in the past before AI.
One straightforward way to achieve this is to code manually and use AI to more thoroughly review & audit your code. But that's not the only way to get there -- you can use AI for coding assistance and still produce higher quality code slower. It's tricky, though.
with AI you can produce software even more slowly but even higher quality than you did in the past before AI
I hadn't thought about it before, but this is precisely what I did in one project.
After replacing a webhook that I've been monkey-patching for ten straight bugs, I had enough of an idea of how the software worked and what edge cases to look out for to reproduce the software without the bugs and with a well-modelled, well-tested foundational client library.
After testing the foundational client library with all the methods I know (unit tests, property tests, mock tests, integration tests, and live tests), I had a race condition in my live tests that accidentally turned into a fuzz test of the live service the client connects to, and discovered a bug in the server.
The actual webhook has been brewing for a long time. For weeks I've just casually added more tests. Nothing interesting happened. I've went live with it now, and nothing comes up. So on to make a load test with mock endpoints.
I love how AI makes advanced, extensive testing techniques (and TDD) take little enough time to justify using them all.
As someone who taught CS for some years, it is very satisfying to finally come to a point where "we're not testing" cannot be justified from an economic perspective, it is purely a cultural (or lack of cultural) decision, and a lack of knowledge of any testing techniques beyond unit testing.
Comments
The problem is that skill at coding is not exactly the same thing as skill at developing and maintaining software, and AI can help there as well, but a swarm of cowboy coder agents will get you to a legacy codebase very very quickly.
And even if the AI is better than most humans, the speed means that you get more defects and issues! If a human developer has a change failure rate of say 10%, (1 in 10 changes causes a defect or issue), and AI is twice as good and only introduces bugs 5% of the time, but submits 10x as many changes, then you go from 1 bug per unit of time to 5 bugs per unit of time, so your velocity is up 10x but your defect rate is up 5x...
You forget to account for the rate of error correction.
You can just choose how many bugs you want now:
https://nolanlawson.com/2026/08/16/you-can-just-choose-how-m...
That excellent post talks about searching for bugs in extant code, but a similar maxim applies to new code:
With AI, you can choose your position on the speed/quality trade-off curve. You can vibe code crap, you can guide/review more closely and get a higher quality product more slowly.
And that choice can extend past non-AI coding: with AI you can produce software even more slowly but even higher quality than you did in the past before AI.
One straightforward way to achieve this is to code manually and use AI to more thoroughly review & audit your code. But that's not the only way to get there -- you can use AI for coding assistance and still produce higher quality code slower. It's tricky, though.
I hadn't thought about it before, but this is precisely what I did in one project.
After replacing a webhook that I've been monkey-patching for ten straight bugs, I had enough of an idea of how the software worked and what edge cases to look out for to reproduce the software without the bugs and with a well-modelled, well-tested foundational client library.
After testing the foundational client library with all the methods I know (unit tests, property tests, mock tests, integration tests, and live tests), I had a race condition in my live tests that accidentally turned into a fuzz test of the live service the client connects to, and discovered a bug in the server.
The actual webhook has been brewing for a long time. For weeks I've just casually added more tests. Nothing interesting happened. I've went live with it now, and nothing comes up. So on to make a load test with mock endpoints.
I love how AI makes advanced, extensive testing techniques (and TDD) take little enough time to justify using them all.
As someone who taught CS for some years, it is very satisfying to finally come to a point where "we're not testing" cannot be justified from an economic perspective, it is purely a cultural (or lack of cultural) decision, and a lack of knowledge of any testing techniques beyond unit testing.
How many new bugs get introduced in those fixes?
As many as you allow.
You mean “a codebase of high technical debt” I think