Using AI to Write Code More Slowly Is the Point — Here's Why the Developers Who Get That Are Pulling Ahead

The counterintuitive finding reshaping how serious developers actually use AI coding tools.

The Productivity Promise Has a Hidden Catch

You've seen the pitch: AI coding tools make you a 10x developer. You autocomplete your way through functions, the next line always looks right, and the whole thing ships faster. Except experienced developers on Hacker News have been pushing back hard on this story — and a controlled study from Anthropic gives them serious ammunition. Think of it like using GPS navigation. Turn-by-turn directions get you to the destination faster, but ask yourself six months later whether you actually know the city. You followed every prompt correctly and still couldn't draw the map. The Anthropic research found that AI assistance sped up coding tasks slightly — but the speed gain didn't reach statistical significance. What did reach significance was this: developers using AI scored 17% lower on a quiz covering concepts they'd used just minutes before. That's nearly two letter grades of lost comprehension, on material they had literally just worked with. The tool moved them forward while the understanding stayed behind.

Local Coherence vs. Global Coherence — Why the Next Line Being Right Is the Problem

Here's the core tension that the HN thread keeps circling back to: AI autocomplete is extraordinarily good at making the *next line* look correct. It reads your current context and produces something that fits. This is local coherence — the code reads smoothly, the syntax is clean, the logic of that particular block holds together. But software architecture is a global problem. The question isn't whether this function looks right in isolation — it's whether this function should exist at all, whether it belongs in this module, whether the data model underneath it will survive contact with the next feature request. That's global coherence, and autocomplete has no opinion on it whatsoever. When you let AI fill in the blanks at speed, you're optimising for the wrong level. The decisions that actually determine whether a codebase is maintainable in six months happen before you write the first line — in the design thinking, the naming choices, the boundaries between components. Slowing down forces you back to that level. Speeding up lets you skip it entirely while feeling productive. The METR developer productivity study, cited in Augment Code's spec-driven development research, found developers using AI tools were 19% slower on average despite reporting higher confidence — largely because unstructured prompts created debugging loops that consumed the time saved on generation.

The Calculator Debate, Reloaded

This exact argument played out in mathematics education when calculators became widespread. The concern wasn't that calculators were wrong — they're faster and more accurate than mental arithmetic. The concern was about which thinking disappears when you offload computation. The answer turned out to be nuanced: calculators don't replace mathematical thinking, they change which mathematical thinking you have to do consciously. You no longer need to hold long division in your head, but you need stronger number sense to know when the calculator's answer is plausible. The tool shifts the cognitive load, it doesn't eliminate it. AI coding tools work the same way. The Anthropic study found that not everyone using AI lost comprehension equally. Participants who maintained strong mastery used AI assistance not just to produce code but to build comprehension while doing so — asking follow-up questions, requesting explanations, posing conceptual questions while coding independently. They treated the AI as a thinking partner rather than an answer machine. The tool was the same. The posture toward it was different, and that posture determined whether understanding grew or eroded.

Where AI Actually Helps vs. Where You Should Deliberately Stay Slow

The practical split that emerges from both the Anthropic research and the spec-driven development tooling landscape is cleaner than the debate suggests. **Let AI accelerate:** boilerplate generation, syntax you know cold but type slowly, test scaffolding for logic you've already designed, translating a clear spec into implementation, documentation of code whose architecture you already understand. These are tasks where the thinking is done and you're executing. Speed here is genuine gain. **Keep it deliberately slow:** system design, data modelling, API boundary decisions, naming that will propagate through a codebase, any decision that will be expensive to reverse. The spec-driven development tools highlighted by Augment Code exist precisely because teams kept discovering the same failure mode: write a prompt, get plausible code, then find the implementation missed edge cases buried in requirements nobody had thought through. Spec-driven approaches make the specification the primary artifact — the thinking happens before the generation starts. Anthropics's own Claude Code product ran into a version of this problem internally: when they reduced the tool's default reasoning effort from high to medium to cut latency, users pushed back hard enough that the change was reverted. Given the choice between faster and smarter, developers chose smarter.

What to Watch Next

The tooling landscape is actively responding to this tension. The emergence of spec-driven development as a tracked technique on the Thoughtworks Technology Radar signals that the industry is formalising the 'think first, generate second' workflow into actual products — tools like Intent, Kiro, and GitHub Spec Kit each take a different approach to keeping specifications alive and synchronised with code as it evolves. The deeper question the Anthropic study raises is one that workplaces haven't fully confronted yet: if AI assistance can measurably reduce skill formation in junior developers, what does an onboarding programme look like in an AI-assisted environment? The researchers note this has broad implications for how to design AI products that facilitate learning and for broader societal resilience — not just individual productivity. The developers pulling ahead right now aren't the ones who've automated the most. They're the ones who've figured out which parts of the craft to protect from automation — and why.