AIArticle Converging evidence says AI assistants don't remove difficulty — they relocate it into verification, review, and system understanding.
Mariana Souza A Communications of the ACM opinion piece by Jeremy Osborn hit the Hacker News front page this week with a thesis that lands because it names something most working developers have felt but haven't articulated: AI didn't make programming easier. It redistributed the difficulty. Coding assistants act as external memory — off syntax recall, boilerplate, and API trivia to the machine — while the genuinely hard parts of the job, reasoning and architectural judgment, get more important, not less. The programmer, in Osborn's framing, shifts "from knowledge vessel to orchestrating agent."
It's a clean formulation. It's also, at this point, the best-supported claim in the entire AI-coding debate. What reads as an opinion column is really a synthesis of two years of converging evidence — and the convergence is worth spelling out, because it changes what teams should actually do.
The receipts were already in #
Start with METR's randomized controlled trial from July 2025: 16 experienced open-source maintainers, 246 real tasks on mature repos, Cursor with Claude 3.5/3.7 Sonnet. Developers with AI access finished 19% slower — while estimating afterward that AI had sped them up by 20%. METR now flags the result as historical, and agentic tooling has improved since. But the perception gap is the durable finding. Generation felt like the work, so when generation got fast, the work felt done. The time went somewhere else: reading, verifying, repairing. Nobody's internal clock counted it.
A CHI 2026 study put a name on that missing time. "When Help Hurts" found AI assistance genuinely cut task time and reported workload — and simultaneously shifted effort into verification, with checking and repair burden climbing across tasks. The authors had to invent a "verification load" metric because our existing instruments literally couldn't see where the difficulty went. That's Osborn's argument in lab conditions: the effort wasn't destroyed, it was relocated somewhere we weren't measuring.
Zoom out to production and the same shape appears. Google's DORA research found in 2024 that every 25% increase in AI adoption came with a 7.2% drop in delivery stability; the 2025 follow-up showed throughput recovering while the stability penalty stubbornly remained. GitClear's analysis of 211 million changed lines found duplicated code blocks up eightfold in 2024, and — for the first time in their dataset — copy/pasted lines exceeding refactored ones, with refactoring collapsing from roughly a quarter of changed lines in 2021 to under 10%. Faster generation, more duplication, less consolidation, shakier releases. Difficulty conserved, then deferred with interest.
We've seen this movie, in a control room #
None of this should surprise anyone who's read Lisanne Bainbridge's 1983 "Ironies of Automation." Automate the routine parts of a job and you don't eliminate the human — you leave them the residue: monitoring, exception handling, intervening when the automation goes wrong. Those residual tasks are harder than the originals, and worse, the human is now out of practice at exactly the skills intervention requires. Swap "control room operator" for "developer reviewing an agent's 400-line diff" and the paper reads like it was written last month.
The deeper reason this bites programmers specifically comes from Peter Naur's 1985 essay "Programming as Theory Building": a program's real value isn't the text, it's the theory in the builders' heads — why it's shaped this way, what it must never do. Every prior abstraction wave preserved theory-building. Compilers hid assembly, but you still authored the logic. Stack Overflow gave you snippets small enough to internalize. An AI agent is different in kind: it produces working code while transferring no theory to you. The comprehension debt used to be paid at write time, sentence by sentence. Now it's a balloon payment due at review — or worse, during an incident.
That's the honest version of "differently difficult," and it's why the compiler analogy that AI boosters reach for doesn't hold. You never audited your compiler's output because it was deterministic and formally trustworthy. LLM output is neither, so verification can't be skipped — only skipped for now.
What to change on Monday #
If difficulty has moved to verification and comprehension, then teams still optimizing generation are tuning the cheap side of the pipeline. The practical moves follow directly from the evidence: Budget review as first-class work. Treat agent output like PRs from a prolific, plausible, occasionally wrong contractor. If AI doubled your diff volume and review capacity stayed flat, your bottleneck didn't shrink — it moved to the person you didn't staff for.Keep batches small. DORA's stability data points straight at the failure mode: cheap generation tempts you into big risky changes. The disciplines that contain them — small PRs, feature flags, fast rollback — just became more valuable, not obsolete.Make verification mechanical where you can. Types, property tests, contract tests, and CI gates are how you spend cheap machine effort to reduce expensive human checking. Writing the test before pointing an agent at the implementation is the highest-leverage prompt engineering there is.Schedule refactoring on purpose. GitClear's numbers say consolidation is quietly dying. Agents duplicate because duplication always locally works. Someone with the system theory has to force the merge.
The distributional consequences are uncomfortable. Seniors who carry deep system models and read code fast just got a leverage multiplier. But the traditional junior ramp — build the mental model by writing thousands of small things — is exactly what's being automated, while the skills now at a premium (skeptical review, architectural judgment) were historically acquired through that ramp. Osborn's optimistic take is that the field opens to new practitioners. True at the entry, but the ladder's middle rungs are missing, and no one has convincingly rebuilt them yet.
The tools are genuinely good and getting better; this isn't a case against them. It's a case against measuring them wrong. Programming's difficulty didn't evaporate — it moved downstream of the cursor, into the parts of the job that never showed up in a demo. The teams that win the next few years will be the ones that saw where it went and reorganized around it, instead of celebrating how fast the easy half got.
Sources & further reading #
[AI Didn't Make Programming Easier. It Just Made It Differently Difficult](https://cacm.acm.org/opinion/ai-didnt-make-programming-easier-it-just-made-it-differently-difficult/)— cacm.acm.org -
[Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)— metr.org -
[When Help Hurts: Verification Load and Fatigue with AI Coding Assistants](https://dl.acm.org/doi/10.1145/3772318.3791176)— dl.acm.org -
[Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/)— dora.dev -
AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones— gitclear.com
Mariana Souza· Senior Editor Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 0 #
No comments yet
Be the first to weigh in.