Programming and software development
Also called coding, software engineering, development
The model writes code faster than you can read it. Learning to program now means learning to read, test and reject it — which nobody automated.
The claim Typing the code was never the skill; the difference is that the substitute is now good enough to hide from a beginner which part of the job they are skipping.
There is a measurement worth starting from, because it is the least convenient one available. METR ran a randomised controlled trial with 16 experienced open-source developers on 246 real tasks in repositories they had worked in for an average of five years. With AI tools allowed, they took 19% longer. They had forecast a 24% speedup beforehand and still believed, afterwards, that they had been sped up by 20%. The gap between what the tools do and what using them feels like was roughly forty points, in the direction of overconfidence, among people who write code for a living.
That does not mean the tools are useless — the evidence elsewhere is genuinely positive, and it splits by population. Brynjolfsson, Li and Raymond found a 14% average productivity gain among 5,179 customer-support agents that was 34% for the novices and near zero for the experts: the model was disseminating the best workers' practice to the newest ones. Dell'Acqua and colleagues found consultants inside the model's capability doing better work, faster — and 19 percentage points worse than the control group on the one task that sat just outside it, because they could not tell which task they were on.
For learning specifically, the two findings that matter most point in opposite directions and both are real. Kazemitabaar's controlled study of 69 beginners found that access to a code generator improved code-authoring performance without hurting later manual modification, and helped retention for those with prior block-based experience. Prather's ICER study watched novices work and found the benefit tracked prior metacognitive ability: the students who could already monitor their own understanding accelerated, and the ones who could not finished with an illusion of competence — convinced they had solved problems they had not.
The industry-scale version of the same story is showing up in the code. GitClear's analysis of 211 million changed lines found duplicated blocks rising sharply while refactoring — moved lines, the signature of someone consolidating — fell from 24.1% of changes in 2020 to 9.5% in 2024, the first year copy-pasted lines outnumbered moved ones. DORA's 2025 report, with AI adoption at 90%, found the throughput penalty of 2024 gone but delivery instability still rising: the volume of code went up faster than the systems that review it.
Read together, those give a single instruction for a learner. The model is a fast, confident, unreliable colleague who is best exactly where you are weakest and worst exactly where you cannot tell. So the curriculum below spends its early weeks building the one capability that makes all of that safe — reading code and knowing when it is wrong — and only then turns the speed on.
What actually changed
-
WasWriting your first hundred programs was slow, and the slowness was the tuition — every syntax error taught you the shape of the language.
NowThe first hundred can be generated in a weekend, which feels like progress and leaves the shape unlearned. Do them by hand anyway; that is what the hand is for.
-
WasBeing stuck for three hours was the standard way to learn debugging.
NowBeing stuck is optional, so debugging has to be practised deliberately — including by refusing the hint for the first thirty minutes.
-
WasReading other people's code was an advanced skill you grew into after writing your own.
NowIt is the FIRST skill, because most of the code in front of you was written by something else and your entire value is knowing whether to accept it.
-
WasCode review was one senior engineer's opinion at the end of a week's work.
NowIt is a continuous act performed on a machine's output at generation speed, and DORA measures the consequence of not keeping up as rising instability.
-
WasA junior's ceiling was how much they could build; seniors were paid for judgement.
NowEveryone's ceiling is judgement — which is why the 70% of a feature the model produces has stopped being the hard part, and the last 30% is where careers are now made.
The path
In order. Each stage names what the model may and may not do while you are in it — that rule is the difference between the two arms of every study at the bottom of this page.
-
1 Write it yourself, badly, to completion
Build the mental model of what a computer actually does. This is the stage the tooling most wants to skip and the one everything later rests on.
- Work through one real introductory course end to end — CS50x or The Odin Project — typing every line yourself.
- Write thirty small programs with no completion and no assistant. Numbers, strings, files, loops, a data structure you implement rather than import.
- When you are stuck, sit in it for thirty minutes with a debugger or a print statement before asking anything.
- Explain your program out loud, line by line, to nobody. Where you go vague is where you do not understand it.
What AI may do here Assistant OFF while you write. Afterwards it is a tutor: ask it to explain what your code did, to find the bug you already found, to name the concept you tripped over. Bastani's trial is the whole argument — unrestricted access raised performance 48% during practice and left students 17% worse when it was removed; the hint-only version cost nothing.
You are done when You can write a 100-line program from a plain-English spec, from scratch, with the internet off, and debug it when it fails.
-
2 Learn to read what you did not write
Turn reviewing into your fastest skill, because from here on most code arrives already written.
- Take a real open-source repository and answer questions about it before changing anything: where does a request enter, what owns this state, what breaks if I delete this.
- Fix three bugs in code you did not write. Reproduce first, understand second, patch third.
- Read a code-review guide written by people who do it at scale, then review a friend's pull request and write the comments down.
- Practise reading generated code as adversarially as you would a stranger's: what does it assume, what does it not handle, what did it silently invent.
What AI may do here Use it to summarise unfamiliar code, then verify the summary against the code before you believe it. Never accept a diff you could not have written; if you would not be able to explain it in review, you are not reviewing it, you are laundering it.
You are done when You have caught a plausible, confident, wrong suggestion — and can say what specifically was wrong with it.
-
3 Make it provable
Acquire the thing that lets you accept fast output safely: tests, types, and a habit of reproducing before fixing.
- Write the failing test first, watch it fail, then make it pass. Do this until it stops feeling like ceremony.
- Learn your debugger properly — breakpoints, watch expressions, stepping into a library.
- Add types or assertions at the boundaries where data enters your program.
- Take one thing you built in stage one and give it a test suite good enough that you would let a stranger refactor it.
What AI may do here Let it write tests only for behaviour YOU specified, and read every assertion. A model asked to write both the code and the tests will happily write tests that pass against its own misunderstanding — the failure is invisible and green.
You are done when You can hand a component to someone else, they can change it, and your suite catches the break.
-
4 Build something that has to keep running
Meet the problems that only appear at the second month — state, failure, data, other people.
- Ship a small service with real users, even five, and keep it alive for three months.
- Learn where the data lives and what happens when two things write at once.
- Read one systems book properly — Designing Data-Intensive Applications is the standard — and connect each chapter to something that has bitten you.
- Write down every outage and its cause. That file becomes your judgement.
What AI may do here Fine for scaffolding, migrations and glue you will read. Not for architecture you cannot yet evaluate: this is the jagged frontier, where the confident answer for a common pattern and the confident answer for your unusual constraint are indistinguishable in tone.
You are done when Something you built has survived a failure you did not anticipate, and you fixed it from logs rather than by guessing.
-
5 Direct a machine that writes most of it
Get the speed, deliberately, with the review capacity to absorb it.
- Specify before you generate: what it must do, what it must not do, what you will check.
- Work in small diffs you can hold in your head. The 19% slowdown METR measured is partly the cost of reviewing large ones.
- Keep a running list of the failure modes you have personally caught. It is a better model of the tool than any benchmark.
- Measure yourself occasionally against the clock rather than against the feeling, because the feeling is documented to be wrong by about forty points.
What AI may do here The model may propose any amount of code; you remain the only thing that says yes. Anything you merge without reading is a bet that the next person to read it will be you, at three in the morning, with a customer waiting.
You are done when You can point at a week's merged work and say, for every non-trivial line, why it is there.
Keep these unaided
The gap between what you can do with the tool and what you can do without it is the only honest measure of whether you learned anything. Check it occasionally, on purpose.
- Read a stack trace and find the cause without pasting it anywhere.
- Write a function of moderate complexity from a spec, cold, with no completion.
- Explain the data flow of your own program on a whiteboard.
- Reproduce a bug deliberately before attempting a fix.
- Use a debugger — breakpoints, stepping, inspecting state — rather than print-and-hope.
- Estimate roughly what a piece of code will cost in time and memory at ten times the data.
Where the model genuinely helps you learn
- As a tutor after the attempt: explain the concept you just failed at, in terms of the code you just wrote. This is the guardrailed pattern that did no harm in the PNAS trial.
- As a translator into an unfamiliar language or framework, once you know what you want to say — the syntax is the cheap part to outsource.
- As a reading aid on a large codebase: ask where something is handled, then go and confirm it.
- As a generator of practice problems at exactly your level, and of the counter-example you were too close to see.
- As a rubber duck that answers back when you explain your design out loud — the explaining is doing the work, which is why it helps even when the answer is mediocre.
Traps
- Generating your way through a beginner course. The performance is real, the learning is not, and the bill arrives at the first interview or the first outage.
- The illusion of competence — the specific thing Prather's team observed in novices: strong feelings of progress, weak conceptual models, no way to tell from the inside.
- Trusting the feeling of speed. Experienced developers in a controlled trial were 19% slower and 20% sure they were faster.
- Accepting code you would not have written. It compiles, it passes the test it was given, and it will be your problem in six weeks.
- Skipping the boring middle — testing, debugging, reading — because the model makes the interesting parts so cheap that the boring parts feel optional. They are the entire difference between the 70% and the shipped thing.
- Volume without review. DORA finds instability rising even as throughput recovers; a personal pipeline has the same failure at smaller scale.
What counts as proof now
The artefact stopped being evidence — anyone can generate one. These are the things that still say something about you.
- A project you can be interrogated about — where every design decision has a reason you can state and at least one you would now make differently.
- A bug you found in someone else's code, with the reproduction and the fix.
- A test suite that catches a real regression, written before the fix.
- A service that has been running for months, with the incident notes.
- A pull request you reviewed and rejected, with the reasoning.
Where to learn it
Courses
-
The best free first course there is, and deliberately hard in the right place: it starts in C, so you meet memory before you meet convenience. Slow if you already program.
- The Odin Project Free
A complete, project-driven web curriculum that makes you build rather than watch. Requires real self-discipline — there is nobody to notice when you stop.
-
Shell, git, debugging and the tools every course assumes you already know. A weekend that pays for itself for the rest of your career.
- Nand2Tetris Free
Build a computer from logic gates up to an operating system. The single most effective cure for the feeling that computers are magic. Big time commitment.
Books
-
Write two working interpreters for a real language, free online. Unusually well written, and the fastest way to stop treating your own language as a black box.
-
What actually happens to data under concurrency, failure and scale. The standard systems book for working engineers; too much too early if you have not yet run something in production.
-
Free online. About engineering as programming over time and across people — the part that gets harder, not easier, when code becomes cheap to produce.
Free reading and references
-
Nine subjects, one recommended book and course each, with the reasoning for the choice. The right map once the tutorials stop teaching you anything; not a beginner's first step.
- Exercism Free
Small exercises in 70+ languages with human mentoring available. The mentoring is the part that is scarce elsewhere; the exercises alone are ordinary.
-
A short, concrete standard for what a reviewer looks for. Read it as a description of the skill you now need continuously rather than weekly.
-
The most careful running account of what these tools actually do, by someone who uses them heavily and documents the failures. Read it instead of vendor material.
-
Why the demo is fast and the last stretch is not, and why seniors gain more than juniors from the same tool. An essay, not a study — the numbers in it are illustrative.
Communities and project sources
- Build your own X Free
Step-by-step guides to rebuilding databases, shells, git, browsers. The best source of projects whose difficulty is real and whose solution you cannot copy from your own dependencies.
The evidence
What each source measured, and what kind of source it is. A practitioner study and a randomised trial are both worth reading and are not the same claim.
-
Randomised trial, 16 experienced open-source developers, 246 tasks in their own mature repositories: allowing early-2025 AI tools INCREASED completion time by 19%, while the same developers estimated afterwards that it had cut it by 20%. Preprint; the authors note experimental artefacts cannot be entirely ruled out.
- Prather et al. (2024), ICER Peer-reviewed
Observed novices programming with generative AI: benefit depended on prior metacognitive ability. Some accelerated; others struggled more than without it and finished with an illusion of competence, believing they had performed better than they had.
- Kazemitabaar et al. (2023), CHI Peer-reviewed
69 learners aged 10-17, controlled: access to an AI code generator raised task completion 1.15x and scores 1.8x WITHOUT reducing later manual code-modification performance, and improved retention for those with prior block-based programming experience.
-
5,179 customer-support agents: 14% average productivity gain from an AI assistant, 34% for novice and low-skilled workers, minimal for experienced ones — evidence that these tools transmit expert practice downward rather than lifting everyone equally.
- DORA, State of AI-assisted Software Development (2025) Industry report
With AI adoption around 90%, the 2024 throughput penalty reversed — but delivery instability remained elevated: code is produced faster than review and delivery systems absorb it.
- GitClear (2025) Practitioner study
Across 211 million changed lines: duplicated blocks of five or more lines rose eightfold through 2024, while refactored (moved) lines fell from 24.1% of changes in 2020 to 9.5% in 2024 — the first year copy-pasted lines outnumbered moved ones. A vendor's own dataset, so read the method.
The learning science underneath
None of the advice above is original to this skill. It is the general findings on how humans learn, applied to one job — and each of these pages sets out the evidence for the principle itself.