Summary: "AI had made our team faster. That was the problem." Ozcay's dashboards looked excellent — more pull requests, shorter cycle times, more features reaching staging. What the dashboards did not show was that his senior engineers had stopped writing code and were reviewing it: not juniors' code, not each other's, but AI's, and there was a lot of it. The cost of generating code had collapsed. The cost of understanding software had not — it had moved upward, onto the people accountable for deciding whether the code was safe.

The first six months looked like a success

Nobody announced that software engineering was changing. Coding agents arrived through small requests — generate the test cases, refactor this class, write the API client, find out why the integration test fails — until someone asked the obvious question: why are we doing this manually?

The gains were real. A developer could describe a change in natural language and get a working implementation in seconds: boilerplate, migration, endpoint, tests, explanations of unfamiliar code. That is what made the next part so hard to see.

Because generation got faster, but the responsibility for the code did not move anywhere. Someone still had to understand it, review it, and decide whether the generated abstraction made sense. Someone still had to notice that the retry logic would turn a temporary dependency failure into a traffic amplifier, that a query was now running inside a loop, that a test was technically correct and completely useless. Increasingly, that someone was the same small group.

Juniors got faster; the review load went up

This was the part everyone celebrated. A junior who needed half a day for a small feature now produced something in an hour. A developer unfamiliar with a framework could have the agent explain it. Someone uncomfortable writing tests could generate dozens. The velocity charts moved, and management noticed: "we're getting more done," "we're increasing engineering leverage," "AI is removing the boring work." All true.

The untracked metric was senior review load. A junior did not need less senior guidance because AI wrote the code. Sometimes they needed more — because now the code looked finished. It compiled, the tests passed, the pull request was clean, the PR description was excellent. And the implementation was completely wrong.

The dangerous AI code isn't bad code

Bad code is easy to reject. AI-generated code often is not bad enough to reject. It is plausible: it follows conventions, uses the right libraries, has reasonable names, carries comments and tests, and looks like something a competent engineer wrote.

That is a different review problem. The reviewer cannot only ask "does this work?" They must ask "what assumptions did the model make?" and then "are those assumptions true in our system?" That is far more expensive, because the reviewer is no longer reviewing an implementation — they are reconstructing the reasoning behind an implementation they did not create.

Priya became the safety mechanism

The team's best engineer — called Priya here — was who you wanted in a difficult incident. If Redis started timing out she could tell you where to look; if latency doubled she knew which dashboards mattered; if a deploy caused a strange failure she could reconstruct what changed from a handful of signals. Pattern recognition: the thing that does not fit into a coding benchmark. She was also extremely good at code review. Maybe too good.

After the agents arrived, the harder pull requests started routing to her. "Can you take a quick look?" "AI generated this — does it seem right?" "Tests pass, but something feels off." Five minutes became twenty, twenty became an hour, and the requests kept coming.

She was not coding less because she had less work. She was coding less because she had become the safety mechanism. Her day had changed from build → test → ship to read → verify → challenge → correct → explain → approve. She had become a human compiler for machine-generated decisions — except compilers do not get tired.

Production sent the bill

The incident was undramatic, which is what makes it useful. A service showed elevated latency after a routine release. Nothing crashed, error rates were not catastrophic, dashboards were mostly green — but p99 climbed.

The cause was an AI-generated optimization that changed how requests were batched. The implementation was perfectly reasonable in isolation. Tests passed. The benchmark passed. The PR description explained why it should improve performance. But production traffic did not look like the benchmark, and under real concurrency the optimization increased contention.

The code wasn't stupid. The code was locally correct and globally wrong.

The person who eventually found it was Priya — the same person who had approved dozens of AI-generated changes that month. She had not missed the pattern because she was not smart enough. She was exhausted, having been made the pattern-recognition layer for an entire team's generated code.

The bottleneck moved, and nobody moved with it

PR count was up. Senior review time was up too. AI had reduced the cost of producing code; it had not reduced the cost of understanding software. That cost moved — upward, from the people generating code to the people responsible for deciding whether it was safe.

The demo measures prompt → code. Production measures code → consequences. Those are different metrics, and only one of them was on the dashboard. This is the specific, 2026 form of the pattern Symptoms of a broken product culture describes generally: an output metric improving while the constraint quietly relocates somewhere nobody is counting.

It also updates the forecast in How AI coding companions will change the way developers work. That 2023 argument for broad productivity gains from AI assistants holds at the generation step — the gains Ozcay describes in his first six months are real and were correctly predicted. What three years of field evidence adds is that a portion of the gain is transferred rather than eliminated, landing on review and verification. Not a refutation; a maturity update, of the same kind as the conflicting METR and rework evidence aired in The Solo Developer Gets More From SDD Than a Team.

The career asymmetry

Juniors get leverage from AI. Seniors get responsibility for the output of that leverage. Measured on individual velocity this looks excellent, but if senior engineers spend increasing time reviewing generated code, investigating subtle failures and correcting architectural mistakes, their own output declines — not because they became less productive, but because they became the quality-control department for everyone else's productivity. That is not the same job, and it is rarely the job description or the compensation band.

This is the AI-era instance of the trap in Maker vs Multiplier: the multiplier role is real leverage right up to the point where it consumes the maker capacity that made the person valuable, and nothing in the metrics notices.

What they changed

They stopped treating AI-generated code as just another PR — not because AI was bad, but because the risk profile was different. The review questions changed:

Instead of They asked
Does this implementation work? What assumptions does this implementation make?
Do the tests pass? What important behaviour is not represented by these tests?
Can AI implement this? Should we delegate the implementation of this decision at all?
— Who owns the judgment?

That last question became the most important one. It is the same gate The AI-Native SDLC Playbook formalizes as "humans remain accountable for every decision that requires judgment" — and the playbook's answer to Ozcay's problem is structural: move verification earlier and make it automatic, so human review concentrates on intent and risk rather than mechanical correctness. Ozcay's team discovered the need; the playbook proposes the machinery.

The paradox

AI did not make senior engineers less valuable. It made their valuable work easier to overlook. If AI writes 80% of the code, the remaining 20% becomes dramatically more important — architecture, trade-offs, failure modes, security, performance, production behaviour, business constraints, long-term maintainability, judgment. The things that do not fit neatly into a prompt.

So the near future is not AI replaces engineers. It is AI increases the amount of software one engineer can produce — which means organizations will need better engineers to determine what should actually ship. The generation layer is becoming cheap; the verification layer is not. That is precisely the conclusion Spec-Driven Development Will Collapse reaches from the opposite direction.

Six months on, asked whether the new process felt better, Priya said:

"I don't mind reviewing AI code. I mind being responsible for code I didn't have time to understand."