The question is fair, and we hear it more and more: if AI can write code, why bother learning programming? The short answer: because your value in the AI era lies precisely in your ability to judge the code AI writes — and that ability cannot be generated for you by AI. This article defends that argument with two studies you can check yourself, limits stated honestly. We will not claim AI is weakening programmers’ brains — the evidence is not that strong yet — but handing the entire process of writing code over to AI has a cost, and that cost is borne by your own skills.
What does research say about over-relying on AI?
The most frequently cited preprint is “Your Brain on ChatGPT” by Kosmyna and colleagues at the MIT Media Lab, published on arXiv in 2025. They measured the brain activity of 54 participants with EEG while they wrote essays in three groups: using an LLM, using a search engine, and with no tool at all. The LLM group showed the weakest neural connectivity of the three, and many members struggled to quote essays they had just written. The authors frame this as “cognitive debt” — debt that accumulates when the work of thinking is offloaded to a machine.
Those two limits matter, and we repeat them because they vanish when this paper is quoted on social media. First, it is a preprint: not peer-reviewed, and the authors themselves ask readers not to over-generalize. Second, the task was writing SAT essays, not code — no programmers took part. So the finding is suggestive, not final: for one cognitive task, full delegation to an LLM correlates with lower brain engagement and worse recall of one’s own work. A reason for caution, not a verdict.
Why is “almost right” code more dangerous than obviously wrong code?
Because obviously wrong code refuses to work, while almost-right code works — until one day it doesn’t. That is the mechanism of skill atrophy in programming, and it operates even without any change in your brain.
AI shifts the work from writing to verifying. That sounds lighter, but verification is not a lesser skill — it is the same skill in a purer form. To judge whether a function an AI produced is correct, you must read it, understand its intent, spot the edge cases it misses, and recognize when it solves the wrong problem in the right way. That knowledge is built only by writing and fixing code yourself, over years.
LLM output makes this worse through its style: code that looks confident, with tidy naming, idiomatic structure, sometimes even comments. It passes a quick glance. Its errors — a division by zero on a particular input, a race condition under load — hide behind a convincing surface. Experienced developers read with trained suspicion; a beginner who never built anything alone has no basis for it. That is how atrophy works: not because AI makes you lazy, but because every fully delegated task is one practice repetition lost — and those repetitions build the ability to verify.
What did the METR study find about experienced developers?
The most surprising finding came from METR on July 10, 2025: in a randomized controlled trial, experienced open-source developers were 19% slower when using AI tools — while believing themselves about 20% faster.
The participants were not beginners: developers with years of experience on large repositories they knew well. METR randomly assigned real tasks from those repositories to two conditions, with and without AI, then measured completion time. The developers’ own forecasts, and those of experts asked to guess, predicted a speedup. What was measured was a 19% slowdown. Part of the cause, according to METR, was time spent reviewing and correcting AI output — prompts composed, responses read, almost-right code fixed. The perception gap is itself a finding: people feel faster because they type less, while the clock says otherwise.
There is a second, subtler lesson. These developers could catch errors in AI output precisely because they were experienced: they knew how code in those repositories should look, so small deviations felt wrong immediately. Experience made verification possible and expensive at once. Picture a developer without it: same output, same subtle errors, nobody to catch them. The 19% slowdown is the price seniors paid to stay accurate; a junior who never built the skill pays a different price — errors that slip into production.
Who is most at risk of skill atrophy?
The risk is not evenly distributed. Three situations we see as most vulnerable:
A student deciding whether fundamentals still matter. The temptation is real: assignments can be finished with one prompt, so why memorize data structures? The answer sits in the studies above — without fundamentals, there is no way to judge AI’s answers on problems harder than coursework. A degree earned through full delegation has no skill behind it, and that shows up in the first job.
A career switcher in an AI-heavy bootcamp. Many programs now teach “building apps with AI” as a shortcut — useful for motivation and a fast portfolio, but dangerous as the only mode of learning. If every practice project was written by AI, what got trained is prompting, not programming — and the job market still tests the latter in technical interviews.
A senior developer whose skills quietly rust. The case discussed least. A senior who delegated all code writing for two years will not notice what is missing, because the work still ships. Atrophy surfaces only when they must debug a system without AI, write something the AI is bad at, or move to a different toolchain. A skill you stop using fades slowly and announces itself only when needed.
How do you learn with AI without being weakened by it?
The principle fits one sentence: treat AI as a tutor, not a substitute for thinking. Among developers the rule is “read the diff” — AI output may enter the codebase, but only through your understanding. Here is the protocol we suggest, labeled clearly: this is our editorial practice, not a tested protocol from the research above.
- Try it yourself first. Before opening AI, write your own version — even a bad one, even pseudocode. That initial struggle is what learning research calls desirable difficulty: the difficulty is what makes the explanation stick.
- Ask for explanations, not solutions. When stuck, ask the AI to explain the concept or point out a direction, then write the code yourself. A pasted answer leaves nothing in your head.
- Read every diff. No AI output goes in unread, line by line. A line you cannot explain is a cue to ask again — not to ignore.
- One no-AI build each week. Build something small by hand, from scratch. Not nostalgia: it tests whether the skill is still yours and keeps up the repetitions behind verification intuition.
This kind of healthy adoption — tools speeding up people who stay competent instead of replacing their competence — is also part of the AI consulting and training we offer teams.
Isn’t this the same argument people made about calculators?
On the surface, yes, and the analogy deserves a serious answer. The classic version: people once worried calculators would destroy arithmetic ability, but calculators only freed us for higher mathematics. Why is AI not the same?
Because one difference is decisive: calculators are deterministic and verifiable. 7 × 8 is always 56, on any calculator, and you can check it by a method independent of the calculator. LLM output has neither property. The same question can yield different answers on two calls, there is no independent check other than your own understanding, and a wrong answer arrives in the same confident tone as a right one. The more honest analogy is not the calculator but the co-pilot in a cockpit: useful, even necessary, but the pilot must still be able to fly — the co-pilot can be wrong and will not say when.
The analogy holds one truth: tools shift what is worth learning. Memorizing syntax matters less now, and that is fine. What has not shifted is the ability to read, judge, and fix code — all born from the practice of writing.
What about the view that “AI will handle everything, so just learn prompting”?
This view should be steelmanned, not laughed at. Its strongest version: model capability keeps rising, much programming work will move to problem formulation and agent orchestration, so the skill worth building is writing specifications and managing output — not loops.
Part of that is correct. Roles are shifting, and writing good specifications is a real skill we value. But it fails in two places. First, good specification and orchestration demand deep technical understanding: you cannot tightly specify a system you do not understand, nor evaluate an agent working in a foreign domain. Second, the view bets on a future that has not arrived. The METR study — early-2025 models, highly experienced developers, repositories they knew — showed the tools do not yet speed up even their best users. Betting your career on “the models will be smart enough later” is betting on a promise, not a measurement.
And verification does not disappear when work moves to agents. Agentic systems need more disciplined evals, guardrails, and output review, because an agent’s errors multiply across every step it takes alone. This is work we do daily in our AI agents service, and none of it can be done by someone who does not understand the code underneath.
What are the limits of this argument?
Honestly, several. The neurological evidence is one unreviewed preprint on essay writing, not programming, with 54 participants. METR measured experienced developers on familiar repositories with early-2025 tools; the result does not automatically transfer to beginners, newer models, or other work. None of the cited research prescribes a curriculum — the protocol above is a practice we suggest, not a scientific finding. This article also deliberately skips which first language or resources to pick.
Sources were checked on October 1, 2026. If your team wants to adopt AI while still building its members’ core skills, talk to us.
