A 2025 telemetry study from Faros AI, covering more than 10,000 developers across 1,255 teams, found something that should stop you mid-standup. Teams with heavy AI adoption merged 98% more pull requests per developer and finished about 21% more tasks. Good news, until you read the next line: review time on those PRs went up 91%, average PR size grew 154%, and bug counts ticked up 9%. At the company level, the DORA delivery metrics didn't move at all.
Read that twice. Output roughly doubled. Delivery stayed flat. The work didn't disappear — it moved. And where it moved tells you exactly how the job is changing.
The keystroke was never the point
For a long time we let "writing code" stand in for "engineering," because typing was the visible, billable, blocking part of the loop. It isn't anymore. An agent can now hold a task for far longer than a copilot ever could — Anthropic's 2026 Agentic Coding Trends Report describes sessions that run from minutes to hours, including a single seven-hour run that touched a 12.5-million-line codebase. That's not autocomplete. That's a junior engineer who never gets tired and never asks a clarifying question unless you force it to.
But the same report is refreshingly honest about the ceiling: developers now use AI in roughly 60% of their work, yet report being able to fully delegate only 0–20% of tasks. The gap between "AI touched this" and "AI finished this" is the entire job now. Someone has to specify the task well enough that an agent can execute it, and then verify that what came back is actually correct, secure, and the thing anyone wanted. Both of those are engineering. Neither of them is typing.
Directing is a discipline, not a vibe
The failure mode I see most often is treating an agent like a search box — one line of intent, then relief when green text appears. That produces exactly the 154%-larger, harder-to-review PRs the data warns about. Directing well looks more like writing a brief for a capable contractor you won't get to interrupt.
Concretely, the artifact you hand off shifts from the implementation to the specification plus its acceptance criteria:
# Task: add rate limiting to the public API
Constraints:
- token-bucket, 100 req/min per API key, sliding window
- no new hard dependency; reuse the existing IDistributedCache
- enforce in middleware, not in a controller
Reject if:
- a 101st request within the window does not return 429
- existing auth/integration tests go red
Done when:
- integration test proves 100 pass / 101st = 429
- added p99 latency < 2ms under the existing load test
Notice what that is. The constraints encode architecture decisions I'm not willing to delegate. The "reject if" block is a verification contract — it tells the agent (and me, at review time) what "wrong" looks like before a single line exists. This is the code-judo move: the specification does the work that used to be spread across implementation, review comments, and the bug you'd have caught in three weeks. Write it once, up front, and most of the back-and-forth never happens.
The bottleneck moved to review — plan for it
Here's the part teams keep learning the expensive way. If generation gets cheap and review doesn't, review becomes the whole cost. The Faros numbers are that story in one chart: 98% more PRs, 91% longer to review each of them. Reading every line of machine-written code — "white-box" review — does not scale when an agent can produce thousands of lines in an afternoon.
The uncomfortable evidence sits underneath. In a controlled trial run by METR between February and June 2025, sixteen experienced open-source developers worked on tasks in repositories they'd maintained for years. With AI tools they were 19% slower. They had predicted a 24% speedup; even after finishing, they still believed AI had made them about 20% faster. The tooling didn't just fail to help — it convinced its users of the opposite of what happened.
The people best positioned to catch that illusion are the ones who can read an agent's output and know, from experience, that it's confidently wrong.
That's why this shift is seniority-biased. Architecture intuition, systems judgment, and the taste to reject a plausible-looking diff are exactly the skills agents don't have and can't fake. If you can't verify, you can't direct — you can only hope.
So build the review pipeline as deliberately as you build the app:
- Shrink the unit of review. Direct agents toward small, single-purpose PRs. A brief with tight constraints produces one; "make it faster" produces a 154% monster.
- Make verification executable. The acceptance criteria in your brief should be tests and gates, not prose. Machine-checkable "done" is the only kind that scales.
- Point agents at review, too. A second agent reading the first one's diff against your constraints catches the obvious misses before a human ever opens the PR.
- Watch the right number. Generation speed is a vanity metric now. Review latency and change-failure rate are the ones that tell you whether you're shipping or just producing.
What actually gets more valuable
The framing I've come to trust, echoed in Fortune's reporting on the emerging "supervisor class" of engineers, is that your primary value is no longer the manual production of code — it's the orchestration and verification of it. Success stops being measured in lines authored and starts being measured in bugs prevented, architecture that survives contact with scale, and whether the thing solves the problem someone actually had. Roughly a quarter of AI-assisted work in Anthropic's data is net-new — features that only got built because generation got cheap — which means the scarce skill isn't producing options, it's choosing the right ones and saying no to the rest.
None of this makes engineering easier. It relocates the hard part from "can I write this" to "can I specify this precisely and prove it's right." That was always the harder half.
The concrete takeaway: before you scale up generation, scale up verification. This week, take one real task and write the brief the way I showed above — constraints, reject-if, executable done — before you let an agent touch it. Then measure how long the resulting PR sits in review, not how fast it appeared. If review is your bottleneck, generating twice as much code just makes the queue longer. Fix the constraint you actually have.
Sources: Faros AI — The AI Productivity Paradox, Anthropic — 2026 Agentic Coding Trends Report, METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Fortune — The supervisor class: how AI agents are remaking the developer's career