+24506 -3938. One pull request, with a description written by the AI that wrote the code. Six more behind it in the queue.
Normal Monday, 2026. You weren't on holiday. You were at your desk on Friday. Over the weekend your team shipped more change than they used to produce in the weeks you spent away.
Rewind to 2020. You're the most senior person on the team and you own code quality and architecture. Good practices are in place. You review PRs from people less experienced than you and work at keeping the codebase healthy. Then you take a few weeks off, and you come back to a mess: everyone merged everyone else's PRs without paying much attention, someone bolted a pile of new tables onto the database to denormalise it because that was easier, and someone added Kafka with no solid evidence the team needed it.
It's okay. You can fix that.
Those decisions were always this bad. What changed is throughput. Implementation costs close to nothing now, so the scarce thing on a team is the person who can explain why the system looks the way it does, and that scarcity is heading for the payslips.
AI removed the speed limit
Weak engineering culture used to fail slowly. Now it fails fast enough to watch.
People used to sit down and argue about how they'd build something before writing any of it. Now they prompt an agent for a few hours and open a PR.
The tragic part: to the untrained eye it works. Pull the branch, test it, you get something roughly functional. So they keep going. Again and again, until nobody knows how anything works.
It's someone buying a luxury car on a credit card. You don't see the debt. You see the car.
Then users report a weird bug. Fourth time the team has tried to fix it. Fourth time they've asked AI to fix it, more precisely. This time not even Fable can work it out.
So you go and talk to the person who built the feature.
- "So where does the data come from?"
- "Hmm. Actually, I don't know. Let me ask Claude."
You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true. Claude sounds very sure.
"Let's turn on ultracode and get it to double-check." That one will take a while, so you talk about the latest drama on X while it runs.
An answer comes back.
- "Does this make any sense to you?"
- "I'm not sure."
- "Didn't you build this, like, last week?"
Silence.
The project has picked up so many layers and services that nobody on the team could hold it in their head. Fixing it would take a colossal amount of work you couldn't begin to justify to management, and a few months later it would look exactly the same anyway. So:
- "Let's just ask Claude to fix it."
- "I'll create a loop and a goal so it doesn't stop until it's checked everything works."
- "Sounds good."
- "Actually, I ran out of Fable usage for today. I'll run it tomorrow."
Another coffee. Thirteen PRs left to review. One of them makes no sense to you, so you message the author.
- "Why are we doing this here?"
They send you a link to a Claude conversation. Somewhere in it, between Claude confidently recommending an architecture, apologising, changing its mind, your coworker asking it to reconsider, and fifteen more rounds of changes, sits the design decision behind the code.
- "Which part should I read?"
- "Probably all of it."
Whenever I bring this up, someone tells me that nobody ever fully understood large systems anyway. True. You were never expected to know every service and every database yourself. But someone did, and they'd explain it when you asked. Now that person asks an LLM, because they don't know either.
Every failure in that story has a name
Every team has competent people who make the project possible, and people who make it harder for everyone else. Volume is what changed: anyone in either group can now produce more code in a day than they used to write in a year.
So name the failures. The engineer who opened a 25,000-line PR should have stopped the agent long before it got there, understood what it was doing, split the work into smaller pieces and questioned every new abstraction it introduced. The reviewer should have refused to look at something that size instead of giving in. The person who added Kafka should have been able to say precisely why it was needed. The engineer who built the feature should have been able to explain where the data came from without pasting a chat log.
None of that is an argument against technical debt. A shortcut is fine as long as you know it's a shortcut and somebody is still carrying it on the books. The failure is shipping an agent's shortcut as a finished decision, with nobody holding the reason for it.
The ten-minute change you can't undo
So use AI to clean up what AI made. Fine, except reverting a bad decision is hard. Very hard.
How long does an LLM need to add a dozen tables and columns to the database? Ten minutes. Now take them out. Once data lives there you need a migration plan, a way to avoid disrupting the people who pay to use the system every day, a decision about what happens if the migration fails, and a guarantee you won't leave orphaned foreign keys behind. The best model you can buy doesn't shrink any of that.
Meanwhile the PRs keep arriving. More code, more abstractions, more decisions. One person generates 20,000 lines in an afternoon and someone still has to sit there and work out what those lines actually do. By the time you've untangled one bad decision, five more have merged.
Why six-figure salaries survive "software is solved"
Bad engineers were always a liability, decades before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated, teams ended up maintaining systems nobody really understood. The limit was how fast a human could type.
That limit is gone.
Implementation is cheap. You're paid for judgment: software that scales while the complexity underneath stays manageable.
Ask why companies pay six-figure salaries to engineers in London or San Francisco at all. If they only needed someone to turn a specification into working code, why pay that much when the same output was already available cheaply elsewhere? And why do the companies announcing that software is solved still compete so hard for the best people they can attract?
My bet is that AI pushes salaries further apart. There's a bar you have to clear to be employable, and the bar is whatever the best model du jour already does on its own.
Good engineers got more valuable, because AI lets them move fast without a crowd around them doing the implementation work. Bad engineers got much more expensive to hire, because their mistakes now compound at agent speed. I made a version of this argument when I wrote that the vibe coder career path is doomed. Prompting an agent is the baseline everyone already has. You have to contribute past it. If you lack the judgment to evaluate what the LLM recommends, asking it for more judgment gets you nowhere. Someone still has to know what's going on, and that person is the most valuable one in the room. Everyone else gets cheaper to hire or replaced outright, while the money funnels toward a shrinking group who can be trusted with the decisions.
I don't think this stays inside software engineering. Most knowledge work is next. AI makes the best people far more productive and the weak ones almost impossible to justify hiring. There used to be a decent chance somebody would catch a bad decision before it travelled too far. Now the changes land faster than anyone nearby can review or understand them.
Which puts you back at the Monday queue: seven PRs before the coffee, thirteen after it, and one person in the building who can tell you what any of it is for.
