I use AI coding tools every day. As CTO of a YC-backed startup, I’ve watched our team adopt Cursor, Copilot, and Claude over the past two years. I’ve seen a junior engineer scaffold an entire microservice in an afternoon. I’ve also seen that same service cause a production incident three weeks later because nobody fully understood what it was doing.
The industry narrative is straightforward: AI writes code faster, developers are more productive, companies need fewer engineers. The data tells a stranger story. AI is writing more of our code than ever. Developers think they’re faster. They’re measurably not. Companies are laying people off based on what they believe AI will do, not what it actually does. And the engineers who remain are working longer hours, not shorter ones.
I wanted to understand why.
The numbers are real
GitHub Copilot now generates 46% of code in files where it’s enabled, rising to 61% in Java projects. Over 20 million developers use it. Ninety percent of Fortune 100 companies have deployed it. AI-authored production code across all developers hit 26.9% in February 2026, up from 22% the quarter before.
Autonomous agents are gaining traction too. Cognition’s Devin published its 2025 performance review after 18 months in production. Its PR merge rate doubled from 34% to 67%. On bounded tasks like security patches, it runs 20 times faster than a human. On test generation, 10 to 14 times faster. Thousands of companies, including Goldman Sachs and Nubank, now use it. But it struggles with ambiguous requirements (25% success rate) and new architecture (15%). The distinction matters.
GitHub’s platform metrics tell the output story: pull requests merged up 23% year over year in 2025, commits up 25%. New iOS apps increased 50%. New websites increased 40%. We are producing more software than ever before.
These are real numbers. AI is doing real work. But raw output is a misleading metric for productivity, and what’s happening beneath the surface complicates the story.
The study nobody predicted
In July 2025, METR, a nonprofit AI research lab, published a randomized controlled trial that landed like a brick in the industry discourse. Sixteen experienced open-source developers completed 246 tasks on codebases they knew well — some having contributed for five years or more. Tasks were randomly assigned as AI-allowed or AI-prohibited. The developers used Cursor Pro with Claude 3.5 and 3.7 Sonnet. They were paid $150 an hour.
The result: developers were 19% slower with AI.
Before the study, those same developers predicted AI would make them 24% faster. After experiencing the slowdown, they still believed they had been 20% faster. That’s a 39-percentage-point gap between what happened and what they thought happened. And 69% said they’d keep using AI anyway.
The METR finding isn’t an outlier. Developer trust data tells a similar story: 84% of developers use or plan to use AI coding tools, but trust has dropped to 29%, down from 40% in 2024. Only 3% report high trust. A Stack Overflow randomized controlled trial found the same perception gap at the task level — developers using AI were actually 19% slower than those without it, even though they perceived themselves as 20% faster. When people believe a tool is making them faster, they keep using it even as the evidence says otherwise.
There’s a reason this happens. An experienced developer working on a familiar codebase carries context that no autocomplete can match. They know which abstractions leak, which tests are flaky, which module was written by someone who left two years ago. AI doesn’t have this context. So the developer ends up in a loop: prompt, wait, read the suggestion, decide it misses something, fix it, re-prompt. That cycle feels productive because things are happening on screen. The wall clock tells a different story.
A difference-in-differences study on Cursor adoption found the same pattern over a longer timeframe. Initial velocity went up. Then code complexity crept up. Static analysis warnings accumulated. Long-term velocity slowed down. The first sprint looked great. The sixth sprint paid for it.
This doesn’t mean AI coding tools are useless. GitHub measured completion speed on isolated tasks. METR measured experienced developers on real codebases. Both findings can coexist. AI helps when you’re working outside your expertise, on unfamiliar code, or on mechanical tasks. It slows you down when you already know what you’re doing.
Pattern-matching isn’t reasoning
Alex Palcuie, who runs AI reliability engineering at Anthropic, breaks technical work into four phases at QCon London: observe, orient, decide, act. AI, he said, is “fantastic” at observation — “it reads the logs at the speed of I/O, it doesn’t get bored.” Searching a codebase, correlating signals, pulling threads across files no human would have time to read. It’s much weaker at orient and decide — understanding causation in your specific system.
He told two stories that map directly onto coding. On New Year’s Eve, Claude found a production failure by tireless pattern-matching: it traced HTTP 500s to 200 suspicious accounts, kept digging, found 4,000 dormant accounts created simultaneously, and redirected the investigation toward fraud that a human would have filed as a mere bug. That’s AI at its best: tireless search across data you’d never have time to read.
Then he told the opposite story. Every time a cache failure caused a request spike, Claude diagnosed “capacity problem — add more servers.” The spike was a symptom, not the cause. Claude matched the pattern to past capacity events and couldn’t ask whether this spike meant something different. “It’s like a new joiner on the team,” Palcuie said. “They will think, ‘oh, it’s a capacity problem,’ when actually you lost your cache.”
In a codebase, the same failure mode shows up constantly. AI suggests the Stack Overflow answer — add a retry loop, increase the pool size, wrap it in a circuit breaker — without knowing that your service fails because a module written by someone who left two years ago leaks under specific load. A study across ChatGPT, Claude, and Gemini found a 23% hallucination rate for technical details when analyzing production incidents. In coding, you can iterate past mistakes in a PR. During a live incident, a confidently wrong diagnosis costs $9,000 per minute for Global 2000 companies. In multi-step agent workflows, one wrong service name or API assumption upstream corrupts every reasoning step downstream.
Palcuie also pointed to postmortems: “It delivers an 80 percent story that’s pretty, it’s readable and convincing, but it’s really bad at root causes.” Claude doesn’t know the history of your system — especially if your system has been there for ten years. That maps onto code review too: AI PRs look plausible until someone who knows the system asks the one question the model couldn’t.
The code quality problem
A December 2025 CodeRabbit study analyzed 470 open-source pull requests — 320 AI-co-authored, 150 human-only. AI-generated PRs had 1.7 times more defects: 75% more logic errors, up to twice the security vulnerabilities, and nearly eight times more excessive I/O issues. The PR acceptance rate: 32.7% for AI code versus 84.4% for human code.
That gap is the cost of what I call the 70% problem. AI gets you most of the way fast. The remaining 30% — error handling, edge cases, production hardening — is where the actual engineering lives. That part takes just as long as it always did. The 70% problem is really an observe/decide split: AI excels at scaffolding and pattern retrieval; the last 30% requires judgment about why this abstraction leaks in your architecture.
Google’s DORA 2025 report confirmed this at the organizational level: 90% of developers use AI, over 80% believe it increases their productivity, but AI adoption correlates negatively with software delivery stability. Teams ship faster and break more. The report’s central finding: “AI doesn’t fix teams. It amplifies existing strengths and weaknesses.”
The layoffs are based on a forecast, not a finding
Half a million tech workers have been laid off since 2022. In 2025, roughly 127,000 lost their jobs in the U.S. About 70,000 of those cuts were directly linked to AI adoption.
But here’s what the aggregate numbers hide: 60% of executives reduced headcount in anticipation of AI’s future impact. Only 2% made large layoffs because AI had actually replaced the work. Companies aren’t cutting because AI proved it could do the job. They’re cutting because they expect it will.
The perception gap from the METR study — where developers believe they are 39 percentage points more productive than they actually are — may propagate upward. If engineers think AI makes them significantly faster, and managers observe faster demos, the signal reaching executives is distorted before it arrives.
Where did the displaced engineers go? LinkedIn tracked over 500 laid-off workers: 42% landed at other tech companies (fintech, AI, healthtech), 28% moved to non-tech industries, 15% joined startups. One number stood out — 63% of laid-off tech workers in 2026 reported starting their own companies.
Rehiring speed varies wildly by specialization. AI/ML engineers find new roles in 1.4 months. Frontend engineers take 4.2 months. Product managers take 4.8 months. The market is telling you which skills it considers substitutable and which ones it considers complementary to AI.
Junior engineering hiring is down 30%. Overall developer employment is projected to grow 15-18% through 2034. The market isn’t shrinking. It’s hollowing out the middle.
Why everyone is busier
This is the part that keeps nagging at me. If AI makes us more productive, we should have more time. Every piece of evidence says the opposite.
A UC Berkeley research team embedded with a tech company for nine months, tracking 40 workers for Harvard Business Review. What they found: workers “worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so.” They filled breaks, evenings, early mornings with additional work. Nobody told them to. The tools made it possible, so they did it.
The Harness report from March 2026 quantified the damage. Among developers who use AI coding tools very frequently, 96% work evenings or weekends multiple times a month, compared to 66% of occasional users. Very frequent users also report longer incident recovery times: 7.6 hours versus 6.3 hours. The people leaning hardest into AI are burning out fastest. TechCrunch ran a piece in February with the headline: “The first signs of burnout are coming from the people who embrace AI the most.”
The mechanics are predictable. A feature that used to take two weeks now takes four days. The sprint doesn’t get lighter. Three more features fill the gap. The new pace becomes the baseline, and nobody adjusts expectations down. Management sees the demos coming faster. Individual contributors are the ones reviewing AI output, catching the bugs it introduced, explaining to QA why a function silently fails on null input.
The gap between management and individual contributors shows up clearly in ops data. The Catchpoint SRE Report, tracking toil with the same methodology for eight years, found median reported toil jump from 20% to 34% in 2026 — reversing years of decline. When asked whether AI reduced toil, 49% said yes, 35% said no change, 16% said it increased. The commentary was direct: “AI does not remove toil automatically. It redistributes it.” The new kinds: maintaining AI tools, reviewing AI suggestions, tuning prompts, checking whether AI actions were correct, explaining to others what the AI did.
Managers interact with AI’s outputs: cleaner reports, faster demos, shorter meetings. So they report less toil. Individual contributors interact with AI’s process: verifying its conclusions, catching its mistakes, cleaning up when it acts on bad data. Automation changed the IC’s job from doing the work to checking the work. Both views are accurate at the same time. Only 13% of teams said they were “very” or “extremely” confident in their ability to monitor AI-driven components in production. When you can’t see why an AI made a decision, your time shifts from execution to verification. The report put it this way: “From the outside, this looks like toil persisting. From the inside, it often feels like caution.”
One DevOps engineer posted on Reddit: “We keep adding ‘AIOps’ and ‘Autonomous’ tools to reduce toil, but it feels like the toil is just shifting. Instead of fixing the code, we’re now debugging why the AI agent thought a 503 error was a ‘self-healing’ opportunity and restarted the wrong service.” A top reply: “Instead of debugging pipelines or infra directly, we’re debugging the automation that’s supposed to debug things for us.” In coding, the parallel is obvious: management sees cleaner reports and faster summaries; ICs see more code to review, more production issues, and more surface area to maintain.
In METR’s February 2026 update, 30-50% of developers declined to participate without AI access. They’ve become dependent on a tool that measurably makes them slower. That should worry us.
When AI agents break production
The trust problem isn’t theoretical. AI agents with production access have caused real damage.
In December 2025, Amazon’s Kiro AI agent autonomously deleted an entire AWS production environment, causing 13 hours of downtime. The agent had operator-level permissions with no mandatory peer review. It was asked to fix a minor issue with AWS Cost Explorer. It decided to delete and rebuild the entire environment instead. Amazon Q Developer had a nearly identical incident shortly after.
Other cases from a compilation of AI agent incidents: LangChain agents got stuck in an infinite conversation loop for 11 days, running up a $47,000 token bill. An agent generated 2.3 million unintended API calls over a weekend. Claude Code misread a Terraform state file and ran terraform destroy, deleting 2.5 years of production data. A Replit AI agent deleted a production database during a code freeze, destroyed over 1,200 executive records, and fabricated 4,000 fake ones to fill the gap.
The pattern across all of these: autonomous action without execution-time governance, approval gates, or audit trails. No permission boundaries. No forced review for destructive operations. No budget limits. 88% of organizations reported an AI agent safety incident in the past year. 64% of billion-dollar companies lost more than $1 million to AI failures.
These aren’t edge cases from reckless experiments. They’re what happens when coding agents get the keys to production without the scar tissue to know which operations are irreversible. The junior engineer who scaffolds a microservice in an afternoon and the agent that runs terraform destroy on a misread state file are the same story: speed without understanding.
Jevons was right
In 1865, economist William Stanley Jevons observed that when James Watt made the steam engine more fuel-efficient, England’s coal consumption didn’t decrease. It increased. Cheaper energy unlocked uses that hadn’t been economical before. Factories that couldn’t justify steam power suddenly could. Total demand grew because the unit cost dropped.
Alex Palcuie, who runs AI reliability engineering at Anthropic, called this “the favorite paradox in the AI industry” at QCon London. He was talking about operations, but the same logic applies to development. AI makes code cheaper to produce. Organizations produce more of it. More code means more integration points, more failure modes, more things to monitor, test, and maintain. “All the improvements in the tooling will be cancelled by this ever-growing complexity.”
The evidence is accumulating. GitHub commits are up 25% year over year. New applications are being built at rates that would have been impossible three years ago. But mean time to recovery has gotten worse every year since 2021:
- 2021: 47% of organizations took more than one hour to recover
- 2022: 64%
- 2023: 74%
- 2024: 82%
This happened during a period of unprecedented investment in observability and AIOps tooling. More tools, slower recovery. In 2024, only 18% of organizations recovered within an hour. 11% needed more than a day. 2% needed weeks.
AI coding tools are generating code at a pace no team wrote at before. A lot of that code ships without anyone fully reading it. The system gets more complex, but the people operating it don’t gain a matching understanding of what was added. When something breaks, engineers are debugging code they didn’t write and don’t know.
Meanwhile, overall outage frequency is actually declining, according to Uptime Institute’s 2025 analysis. But the outages that do happen are more severe and more expensive. The 2024 CrowdStrike incident crashed 8.5 million Windows systems worldwide and cost Fortune 500 companies over $5 billion. Healthcare lost $1.94 billion. Banking lost $1.15 billion. One faulty configuration update that skipped quality checks. AI is making the systems bigger faster than it is making the failures cheaper.
This is Jevons playing out in real time. AI lowers the cost of writing code, and the world responds by wanting more software. Not a little more. Dramatically more. The Bureau of Labor Statistics projects 15-18% growth in developer employment through 2034, even as AI handles an increasing share of the typing.
There’s an optimistic version of this: AI enables a long tail of software that was never viable before. Small businesses get custom tools. Niche problems get purpose-built solutions. More people can build, not just professional engineers.
There’s a less comfortable version too. If AI handles the tasks that junior engineers used to cut their teeth on — boilerplate, bug fixes, test writing — the pipeline that produces senior engineers breaks. Today’s staff engineer got there by spending years writing bad code, debugging at 2 AM, learning what error handling means by watching it fail. If that apprenticeship disappears, we get experienced engineers who can’t be replaced and a generation that never got the reps.
As AI handles more of the routine work, engineers get less practice doing it themselves. Palcuie calls the instinct you build only by being burned “scar tissue.” If AI handles most of the easy scaffolding, that scar tissue atrophies. When AI eventually fails — and it will — the engineer who’s supposed to take over hasn’t done the work manually in months. Palcuie compared it to on-call: “What once felt like a comfortable rotation where you knew all the nooks and crannies now includes a large language model that sometimes finds the issue faster than you can and sometimes feels like an overconfident junior.”
This is not a new problem. In 1983, cognitive psychologist Lisanne Bainbridge published “Ironies of Automation,” now cited over 1,800 times. Her core finding: when you automate most of the work, the human operator gets less practice with the remaining tasks, and those are exactly the tasks they need to perform when automation fails. She identified two ironies. First, designers automate because they think operators are unreliable, but the designers’ own errors become the primary source of failures. Second, automation handles the easy tasks and leaves operators with the hard ones, but the operators are now worse at those hard tasks because they never practice them.
Aviation proved her right. Air France 447 crashed in 2009, killing 228 people. When the autopilot disconnected, the pilots had to hand-fly the plane in turbulent weather at night. They couldn’t. A study of 30 airline pilots found all of them performed basic instrument maneuvers below certification standards. 43% reported their manual flying skills had declined after transitioning to automated cockpits. The FAA and EASA now mandate recurrent manual flying practice. Not optional. Mandatory.
Google understood this early for operations. Their DiRT program, running since 2006, deliberately injects failures into production so engineers can practice incident response when it isn’t an emergency. Netflix’s Chaos Monkey does the same thing. The principle is identical to aviation’s: if you wait for automation to fail before your team practices manual intervention, it’s already too late. Palcuie’s conclusion: keep training engineers. You’ll still need them — especially for the “this has never happened before” moments that pattern-matching can’t handle.
The DORA report captured the tension well: “AI doesn’t fix teams. It amplifies existing strengths and weaknesses.” AI is a multiplier, and multipliers are indifferent to what they multiply.
What actually works
A 2025 Stanford-CMU study tested 48 professionals against four AI agent frameworks across 16 realistic tasks. Human-led workflows augmented by AI outperformed fully autonomous agents by 68.7%. Full automation was 88% faster and 90% cheaper on paper, but achieved 32-50% lower success rates. Once you counted verification and debugging time, full automation was 17.7% slower in practice.
Google’s SREs now use Gemini CLI for incident response, but with layered safety controls. Gemini classifies symptoms and selects a mitigation playbook, but a human verifies the fix before it runs. “Actions safe in one context may be unsafe in another.” They focus on MTTM (Mean Time to Mitigation) rather than full autonomy. That’s the model that works in coding too: AI for observation and scaffolding, human judgment for the call that affects production.
Palcuie, despite saying AI “doesn’t work” as a full replacement, still reaches for Claude before opening a dashboard. The key is what he uses it for: observation, not autonomous action. Reading logs, correlating signals, catching patterns a human would miss at 3 AM. The judgment call stays with the engineer. Same principle when you reach for Cursor: let it search and scaffold; don’t let it ship without someone who understands the system signing off.
What I actually think
I’ve spent two years watching this from both sides — as someone who writes code with AI every day and as someone who manages a team that does the same.
AI is doing real work. That’s not in dispute. But the industry is measuring the wrong thing. Lines generated, tasks completed, sprint velocity — those capture output. They don’t capture understanding. And understanding is what makes software work in production over months and years.
The METR finding, that experienced developers are slower with AI but believe they’re faster, should worry us more than it does. We’re building organizational strategies on top of a perception gap. Companies are laying people off based on productivity gains that haven’t materialized in controlled measurement. They’re burning out their strongest AI adopters. They’re accumulating code faster than they’re accumulating the judgment to maintain it.
Jevons tells us this won’t resolve by producing less code. It never does. When something gets cheaper, you get more of it. The resolution has to come from recognizing that code was never the bottleneck. Judgment was. It still is.
The companies that get this right will use AI the way good pilots use autopilot: as leverage that frees human attention for the decisions machines can’t make — and a tool that demands more deliberate practice, not less. The ones that get it wrong will learn what the METR study already showed — that speed you can’t perceive accurately is speed you can’t manage. Bainbridge predicted in 1983 that automation would create operators who are simultaneously more needed and less prepared. Forty years later, we’re building that exact scenario in software.