AI Didn't Make Programming Easier. It Just Made It Differently Difficult

A July 2026 CACM opinion piece by Jeremy Osborn (DOI 10.1145/3795534, CC-BY). What separates it from most writing in this area is that it argues from the empirical literature on programming cognition rather than from personal workflow, and it doesn't pick a side in the is-AI-good-for-programming fight — its claim is that difficulty moved rather than fell.

Programming was high-memory work

The starting point is decades of research treating programming as a memory-bound cognitive activity. Brooks (1977) described it as maintaining multiple interacting abstractions. Pennington (1987) showed programmers depend on mental models of control flow and data flow to design, understand and modify code. Soloway, Bonar and Ehrlich (1983) found that correctness rose sharply when a loop construct matched the programmer's own internal plan — evidence that the work is guided by cognitive preferences retrieved from long-term memory, not just syntax knowledge. Siegmund et al. (2014) put people in an fMRI and found code comprehension lighting up working memory, attention and language networks.

The consistent finding is that these mental models are expensive to build, fragile, easily destroyed by context switching, and costly to rebuild if undocumented.

AI as external memory

Osborn frames coding assistants as external memory systems and reaches for three existing theories rather than inventing one. Hutchins' distributed cognition holds that cognitive systems routinely extend past the individual into the environment. Cognitive load theory says the tools cut extraneous load — syntax recall, boilerplate — freeing working memory for intrinsic reasoning. The Extended Mind Hypothesis goes furthest: an assistant that is reliably available, habitually used and trusted becomes a component of the programmer's cognitive architecture rather than a tool they consult.

The empirical hook is Barke, James and Polikarpova's Grounded Copilot (2023), which found developers offloading typing, API details and unfamiliar syntax while shifting their effort toward validating and integrating what came back. Osborn's reading: the assistant is not a faster search engine, it's partly an extension of the cognitive architecture.

What doesn't get offloaded

He's careful about the limit. AI reduces the penalty for imperfect recall — you can request a common API pattern without precise memory of it. It does not remove the need to understand program structure well enough to spot code that is syntactically fine but semantically wrong, and it does not touch architectural reasoning, impact analysis, or long-term maintenance, all of which need structural understanding of the codebase.

Two studies are cited against over-optimism, and both cut against the article's own framing rather than supporting it:

• Shihab et al. (2025): students using Copilot completed brownfield tasks substantially faster with more solution progress, but in exit interviews many reported not understanding how or why the suggestions worked.
• Alanazi et al. (2025), a meta-analysis of controlled studies of ChatGPT and Copilot in programming education: task performance and efficiency improve, but gains in learning and ease of understanding are small and statistically unstable.

The warning that follows is the one worth keeping: stable mental models are what let programmers navigate a codebase and simulate its execution, so outsourcing too much thinking weakens the very models the remaining work depends on. That's skill-atrophy-supervision-paradox arrived at from the cognitive-science side.

The core claim

In other words, the hard part moves from recall ("How do I write this?") to judgment ("Does this actually make sense?").

Traditional programming demanded large internal libraries of syntax, patterns and idioms. AI-assisted programming instead demands evaluative frameworks for assessing correctness, coherence and appropriateness. The burden didn't disappear — it relocated from retrieval to reasoning. AI also speeds up writing code while increasing the time spent checking it, so the total isn't obviously lower. recall-to-judgment carries this as a standalone concept.

His analogy is medicine: diagnostic tools lowered the cost of memorizing obscure clinical detail and raised the stakes on interpretation and error detection. Expertise shifted from recall to reasoning without becoming easier.

Four shifts

1. The field opens. People who would have bounced off the overhead of memorizing libraries, syntax variants and error-handling idioms now have a path in. But there's a paradox attached: as the barrier to producing code falls, the barrier to producing good code may rise, because judgment is harder to develop than recall ever was.
2. The work becomes differently difficult, not simpler. Novices used to struggle with syntax errors; now they struggle with whether a generated solution is appropriate, maintainable and consistent with system constraints. That's a more demanding form of difficulty requiring real software-engineering understanding rather than language surface knowledge.
3. Education shifts. Less syntax memorization, more systems thinking — architecture, interface design, state management, failure modes, constraint negotiation, test construction, security, maintainability. Code becomes one representation of thought among several.
4. The programmer stays essential — not as a knowledge vessel but as the orchestrating agent who understands how parts fit, maintains system integrity, and decides what matters. The best developers won't be the fastest typists or the deepest memorizers, but those who hold deep mental models while offloading whatever interferes with that. He calls the model a cognitive prosthetic: fast and useful, but unable to finally determine semantic correctness or coherence.

Where it sits

This is the closest thing the wiki has to the "serious technical analysis of what would have to be true for LLM-assisted dev to work well" that anti-llm-discourse lists as missing from the cluster — it's peer-reviewed, cites its evidence including the evidence against itself, and refuses both the productivity-boosterism and the refusal framings.

It agrees on mechanism with reviewing-ai-code (validation cost rises as generation cost falls) while declining Depierre's conclusion that this caps output. It supplies the cognitive-science underpinning for control-the-ideas-not-the-code and vibe-engineering — both are bets that judgment about design is what remains after recall is offloaded — while its "mental models weaken if you outsource too much" caution is exactly what their critics press on. Against no-silver-bullet-llms it's complementary rather than opposed: Bennett says the essential difficulty can't be automated away, Osborn describes what happens to the person now that the accidental difficulty largely has been.

Cross-references

• recall-to-judgment — the central shift as a standalone concept
• skill-atrophy-supervision-paradox — the mental-model erosion risk
• programming-as-theory-building — Naur's version of the same claim about what really lives in the programmer's head
• control-the-ideas-not-the-code, vibe-engineering — practices that assume this shift has already happened
• reviewing-ai-code, no-silver-bullet-llms — the skeptical readings
• measuring-ai-coding-productivity — why the efficiency-vs-learning gap is hard to measure