"AI didn't make programming easier, it just made it differently difficult" - CACM lands the anti-hype line

A CACM article cuts through the noise: AI hasn't simplified programming, it has shifted the difficulty. The new job: arbitrating the outputs of a model that we only partially understand.

In plain terms - CACM (the ACM's flagship opinion venue) has published an essay arguing that AI-assisted programming isn't easier - it's differently difficult. The centre of gravity of the work has moved from "write the code" to "evaluate whether the code is right".

Contexte

The past 18 months of engineering leadership commentary - Karpathy on autocomplete, Nathan Lambert on "6 months to live", geohot on harnesses - have converged toward a shared observation: LLM-assisted coding accelerates the low-friction parts (boilerplate, initial scaffolding, small refactors) and concentrates effort on the parts that were already hard (system design, invariants, edge-case reasoning, debugging emergent behaviour of code you didn't write yourself).

Analyse

Three claims from the essay worth pulling out:

1. Evaluation is now the bottleneck. When the model can output plausible code in seconds, the engineer's marginal minute is spent judging whether the output is correct - against specs that are often themselves fuzzy. Reading unfamiliar code at speed is a genuinely hard skill, not the "easy" side of programming.

2. Debugging shifts from your bugs to the model's. The failure modes of LLM-generated code are different from human ones: subtly wrong invariants, non-idiomatic patterns that pass tests but drift at runtime, silent hallucinated API calls. The debugging playbook you learned on human-written code doesn't transfer cleanly.

3. Cognitive load rises, not falls. Even when velocity rises, the engineer has to hold two mental models - the intent, and the generated implementation - and check the consistency between them. That's costly, and it's what burns senior engineers.

The essay is not anti-AI. It is anti-hype: the productivity claim ("10× faster") is real for narrow tasks, misleading for the full engineering job.

What to do with this

• Individual craft : invest in code-reading speed, spec writing, and evaluation checklists. Those compound now more than raw typing throughput.
• Team practice : test suites are load-bearing again. Property-based testing and invariant checks catch classes of LLM-generated errors that unit tests miss.
• Architecture : the "small pieces loosely coupled" school gets a second life - when each unit is short enough to evaluate, LLM-generated code is safer.

Scénarios

• Base case (60%) : the profession converges on "evaluator + specifier" as the core competencies of a senior engineer.
• Deskilling (25%) : orgs cut the eval role and ship anyway; a wave of production incidents follows in 18-24 months.
• New tooling (15%) : formal-methods-adjacent tooling (property tests, semantic diff) becomes the new junior-engineer entry point.

Implications

For an engineering leader: hire and train for evaluation, not throughput. For a CTO: your test-suite investment just got a new ROI justification. For an early-career engineer: read more code than you write.