Praveen Rajamani put the cleanest framing I've read on what AI did to our jobs. In a piece on DEV, he splits software engineering into two parts. About 80% was execution: writing boilerplate, fixing repetitive bugs, wiring configs, writing tests for behavior you already understood. The other 20% was the thinking: understanding the real problem, designing under constraints, debugging the edge cases nobody predicted, making trade-offs with incomplete information, knowing what not to build.
His one-line summary: "AI ate the 80%. Now the 20% is the whole job."
That sounds like a win until you notice what it does to a workday. The execution work was tedious, but your brain recovered while you did it. It was the low-stakes part of the day where you caught your breath between hard decisions. Take it away and you don't get a shorter day. You get a day made entirely of the parts that were always hard.
What AI absorbed, and what it didn't
The 80% is exactly where the tools are strong. Claude Code and Copilot will produce a CRUD endpoint, a migration, a test harness, a config file faster than you can describe them. The 20% is where they're weakest, because framing a problem and choosing what not to build aren't autocomplete. They're judgment.
So the shape of the job inverted. The cheap, recoverable work left. The expensive, draining work stayed and grew, because now you're doing it without breaks.
Every hour you save on execution goes straight back into harder thinking
The time AI frees up doesn't become slack. It gets reinvested into denser work: reviewing generated code, deciding whether it's right, holding more of the architecture in your head at once. And the evidence that this is a net speedup for experienced engineers is a lot shakier than the marketing suggests.
METR ran a randomized controlled trial with 16 experienced open-source developers on 246 real tasks in repositories they'd worked in for years. With AI tools allowed, they took 19% longer. They'd expected a 24% speedup going in, and still believed afterward that AI had sped them up by 20%. The feeling of going faster and the fact of going faster came apart completely.
At the team level, DORA's 2024 State of DevOps report found that as AI adoption rose, software delivery throughput and stability went down, not up (InfoQ's writeup has the figures: roughly a 1.5% throughput drop and a 7.2% stability drop per 25% increase in adoption). In the same report, 39.2% of developers said they had little or no trust in AI-generated code.
The code itself shows the strain. GitClear's analysis of 211 million changed lines found copy-pasted code rose from 8.3% to 12.3% and, for the first time on record, overtook reused ("moved") code. Refactoring fell from 25% of changes to under 10%. Churn roughly doubled. AI is very good at adding code and not very good at convincing you to reuse what's already there.
And the people doing the work feel it. In Stack Overflow's 2025 survey, trust in AI accuracy dropped to 33%, down from 43% the year before. The single biggest frustration, named by 66% of developers, was "AI solutions that are almost right, but not quite." Almost-right is the most expensive kind of wrong, because someone senior has to read it closely enough to find the seam.
The case for the other side, stated honestly
None of this means the speedup studies are fake. They're not, and ignoring them would be dishonest.
GitHub's own experiment had 95 developers write an HTTP server in JavaScript; the Copilot group finished 55% faster. A larger set of field experiments across Microsoft, Accenture, and a Fortune 100 firm, 4,867 developers in all, found a 26% increase in completed tasks. McKinsey measured documentation and new code written in roughly half the time.
Look at what those gains have in common. A greenfield HTTP server. Documentation. Counted tasks. That's the 80%. AI is fastest exactly where the work was already easy and well-specified, and the productivity numbers concentrate there. They also concentrate on less-experienced people: MIT Sloan reported junior developers gaining 27% to 39% while seniors gained 8% to 13%. The closer the work gets to the hard 20%, the thinner the gains, until METR's experienced engineers cross into negative.
So both things are true. AI made the easy part faster and the hard part harder, and most of the job is now the hard part.
Nobody is talking about the human context window
Every model release brags about a bigger context window. Nobody mentions the one that didn't change. The engineer's context window is the same brain it always was, now asked to hold more architectural complexity per hour because the recovery work that used to pace the day is gone.
Comprehension debt builds up in that gap. Rajamani describes shipping AI-generated code he didn't fully understand and paying for it with a three-week debugging problem later. The code arrives faster than your understanding of it, and the gap doesn't disappear. It moves downstream and compounds.
The engineers who take this seriously treat verification as non-negotiable. Simon Willison's rule is blunt: "If you haven't seen it run, it's not a working system." Martin Fowler tells people to treat every AI change like a pull request from "a rather dodgy collaborator who's very productive in the lines-of-code sense" but whose work you can't trust on sight. Reading and judging that output is real cognitive work, and it lands entirely on the human.
The skills that quietly go missing
Judgment isn't innate. It's the residue of having done the 80% by hand, enough times to recognize when something's off before you can explain why. Remove the practice and you weaken the thing the practice produced.
Researchers at Microsoft and Carnegie Mellon surveyed knowledge workers and found that the more someone trusted the AI, the less critical thinking they applied. Offload the effort and the muscle that produced it gets quieter.
The pipeline that turns juniors into seniors is the part most exposed. Stanford's "Canaries in the Coal Mine" study, using payroll data on millions of US workers, found early-career workers aged 22 to 25 in the most AI-exposed occupations, software development among them, saw a 16% relative decline in employment. Experienced workers in the same fields didn't. If the entry-level work that used to train people is the work AI now does, the obvious question is where the next round of seniors comes from.
Addy Osmani names the thing that survives: "A senior engineer's job is mostly the parts that don't show up in the diff. Specs. Tests. Reviews. Scope discipline. Refusing to ship what can't be verified." Those are the skills that take years and a degree's worth of foundations to build, and they're the ones AI can't hand you.
Why the rate goes up, not down
Here's the part that should change how you price engineering work. You can't get more output for the same money when the remaining work is harder.
A senior engineer running three AI-driven projects at once does produce more than before. But driving the AI, reviewing what it writes, catching the almost-right answers, holding the architecture together, deciding what doesn't get built, is harder labor than the execution it replaced. Higher output at higher cognitive load per hour doesn't argue for a lower rate. It argues for a higher one.
Scarcity points the same direction. The skill that's now abundant is execution, and abundant things get cheap. The skill that's now scarce is the judgment to direct all that execution, and Stanford's data shows the market already protecting it: experienced people kept their jobs while juniors lost ground. When the hard 20% becomes the whole job and fewer people are being trained to do it, the people who can do it well don't become cheaper. They become the constraint everyone is paying to get around.
The architect is the commodity now
The work AI made scarce is the work an experienced software architect does: frame the real problem, design under real constraints, decide what not to build, and stand behind the result. AI commoditized typing. It made judgment the thing in short supply, and short supply is what gives something value.
That's the person IBERANT is built around: senior engineers who point AI at the execution and keep the judgment in human hands, because that's the part that was never the cheap 80% to begin with. If you're trying to figure out how to organize a team around tools whose pricing and capability keep moving, let's talk.