The stat everyone reads wrong
At a typical company, a quarter of the code merged today came from AI, not a human at a keyboard. Where developers open an AI tool daily, the share climbs higher. DX's Q4 2025 survey of over 85,000 developers found AI-authored code sits at 22% for the median company and 24% among daily AI users. 91% of those developers had adopted an AI tool at work.
People see numbers like these and panic about jobs. Wrong worry, wrong question. The shift worth watching isn't "AI writes code now." It's who wins inside engineering teams once it does. And the winners aren't the people still typing the most.
Typing fast used to be the job
Tech culture rewarded volume for twenty years. Lines shipped. Commits per week. Pull requests merged. I've sat through enough performance reviews where "prolific" meant "good," full stop.
This measuring stick is broken. GitClear's analysis of production repositories found copy/paste code rose 48% between 2021 and 2024, while refactoring dropped from roughly a quarter of changes to under 10%. Developers are producing more code and thinking about it less. Volume went up. Judgment went down. If your review process still rewards whoever commits the most, you're rewarding the wrong behavior.
From coder to conductor to orchestrator
Addy Osmani, a senior Chrome engineering lead at Google, laid out a framework worth stealing in a February 2026 O'Reilly piece. He splits the developer's evolving job into three stages:
- Implementer. Writes every line by hand. The job most of us trained for.
- Conductor. Works with one AI agent in a tight loop: backend, then frontend, then tests, checking each step before moving on.
- Orchestrator. Directs several agents running in parallel, sets the goals up front, and reviews finished work once it lands.
Osmani's own description of the orchestrator's day is worth sitting with: "the human's effort is front-loaded (writing a good task description or spec for the agent, setting up the right context) and back-loaded (reviewing the final code and testing it), but not much is needed in the middle."
Read it twice. Almost none of the job left is typing. Nearly all of it is deciding what to build and judging whether the output earns a merge.
BairesDev's Q4 2025 Dev Barometer backs this up from inside engineering teams: 58% of developers expect teams to get smaller and leaner in 2026, and 65% expect employers to redefine their roles. The job title survives. The job underneath it doesn't.
Orchestrating badly still loses
Here's where I part ways with the breathless version of this story. Directing five agents instead of typing one function isn't automatically a win. Veracode's 2025 testing across 100+ models found 45% of AI-generated code carries a security flaw, and 72% in Java specifically. A December 2025 CodeRabbit analysis of 470 pull requests found AI-generated code carries 1.7 times more major issues than code a person wrote by hand.
Orchestration only pays off when the human on the other end still knows enough to catch a bad merge. Skip the review stage and you haven't built faster. You've built a bigger pile of debt with better handwriting. The engineers pulling ahead right now aren't the ones who let five agents run unattended. They're the ones who front-load a sharp spec and back-load a merciless review, exactly as Osmani describes it.
Trust in the output backs this up too. Stack Overflow's 2025 survey found only 29% of developers trust AI accuracy, down from 40% the year before, and 66% named "AI answers landing almost right, but not quite" as their biggest frustration. The developers winning right now treat every AI output as a first draft from a fast, occasionally reckless junior, not as finished work.
What this means if you hire or promote engineers
Stop interviewing for typing speed. If your technical screen still measures how much code someone produces in 45 minutes, alone, unbroken, you are testing for the wrong job. Test instead for whether someone:
- Writes a spec tight enough to keep an agent from wandering off halfway through.
- Catches a subtle security flaw in someone else's code, or something else's.
- Knows when to stop delegating and write the tricky part by hand.
- Reviews AI output with the same suspicion they'd bring to a stranger's pull request.
None of this shows up on a leaderboard of commits. All of it shows up in production six months later, in the incidents nobody had to clean up and the technical debt nobody had to pay down.
I run my own site this way
I'm not writing this from the sidelines. I build, deploy, and maintain this site... the one you're reading right now... by directing a team of AI agents, not by typing every line myself. I write the spec for a task once. Different agents research the topic, generate images, compress them for the web, deploy them, write the post, and check the copy against my own style rules before anything goes live. My job is deciding what the post should say and making sure the finished result is good enough to publish under my name.
This work split is orchestration, not automation, and the difference matters. Automation runs unattended and hopes for the best. Orchestration still needs someone with judgment reviewing every seam before it ships.
The real question for your team
The developer writing the least code by hand isn't lazy or replaceable. They moved up a level, from typing to deciding. The ones still grinding out every line solo aren't wrong exactly. They're optimizing for a job the industry already retired.
So ask yourself honestly: is your best engineer the fastest typist on the team, or the one you'd trust to write the spec and catch the mistake nobody else saw?