Production outran verification, and the queue is growing
Start with the structural one, because most of the rest follows from it.
Your team can now produce three times as much change per week. Your capacity to review, test, integrate and understand that change is roughly what it was. That is not increased throughput. That is a queue with a growing input rate and a fixed service rate, and queueing theory is not interested in how you feel about it.
The symptoms are recognisable: pull requests waiting four days, reviews getting shallower as the pile grows, change failure rate creeping up, and everybody describing themselves as busier and less effective than a year ago.
Codebases get bigger faster than they get better
It is now cheaper to generate a new 200-line helper than to find the one that already exists and understand whether it fits. So duplication rises. Three date-formatting utilities. Four slightly different HTTP retry policies, one of which retries POSTs. Two ways of representing a user.
Nothing in the process pushes back on this. Adding is easy and always locally justified. Deleting requires knowing that nothing depends on it, which requires understanding the whole, which is the expensive thing. The default direction is accumulation, and if you want consolidation you have to schedule it as work.
Nobody has the mental model any more
The quiet advantage of hand-written code was that someone remembered writing it. At 3am, that person could say "check the cache invalidation, it's always the cache invalidation."
When a service was largely generated, the author's memory is a chat log they no longer have. The first person to genuinely understand that code is whoever is debugging it under pressure, and they are doing it at the worst possible time.
This is not an argument against the tools. It is an argument for writing down why, for keeping changes small enough that someone read them properly, and for treating "can any human on this team explain this service" as an operational property, like backups.
Architectural coherence has no natural defender
Models are excellent locally and indifferent globally. Each change fits its immediate surroundings. Nothing objects to the system slowly acquiring fifteen ways to do the same thing, because no single diff is where that decision gets made.
Coherence was previously maintained partly by accident: writing code was slow enough that people reused things out of laziness. That accident is gone. Consistency is now a thing someone has to be responsible for, deliberately, or you do not get it.
Security surface expands quietly
More code, more dependencies, more configuration, and less of it examined line by line. Add the specific risks: package names that do not exist until an attacker registers them, generated code reproducing patterns that were common in training data and are now known-vulnerable, secrets pasted into contexts they should not enter, and permissions widened because narrowing them takes longer.
None of these is new in kind. All of them are new in volume, and volume is the thing your security review was already struggling with.
The judgement tax
A less discussed cost: you now make more decisions per hour than you used to, and decision quality falls with volume in a way that output quality does not.
Reviewing nine diffs is more tiring than writing two, even though it looks like less work on a calendar. If you finish the day drained after shipping what looks like a light week, that is why. Nobody has good numbers on this yet, but most people who have worked this way for a while report the same thing.
Estimation broke
The first 80% of a feature now takes an hour. The last 20% — the edge cases, the integration, the migration, the thing nobody thought about — takes the same three weeks it always did.
So everything looks nearly done almost immediately, and then appears to stall. This distorts your estimates, your stakeholders' expectations, and your own sense of whether things are going well. If you estimate from how complete the demo looks, you will be wrong every time, in the same direction.
What to actually do
- Put verification in the plan as an explicit line, with a named person and real hours.
- Cap work in progress. If review is the constraint, adding more parallel work makes delivery slower, not faster.
- Keep architecture decisions with humans and write them down where the code is.
- Schedule consolidation. Something as blunt as one deletion-focused day a month beats nothing.
- Measure change failure rate and time to restore, not commits, lines or pull requests.
The honest summary
The job got more interesting and less comfortable. The part that felt most like craft — sitting down and writing the thing — is the part that got automated. The parts that got heavier are judgement, responsibility and attention: deciding what should exist, confirming it does what you meant, and answering for it when it does not.
That is a harder job than the one before, and it is worth being clear-eyed that many people liked the old one better.
Before you move on