Why AI is unexpectedly good at code

Code is the work current models do best, and the measured results are still messier than the marketing. Millions of developers pay for AI coding tools. GitHub Copilot reported 4.7 million paid subscribers in January 2026, Cursor over a million. On money and daily use, this is one of the largest applications of AI anywhere.

Whether that buys speed is less settled than the marketing suggests. The research group METR ran the trial properly: experienced developers, repositories they knew well, real tasks, AI allowed or withheld at random. The AI group took 19% longer. Asked afterwards, the same developers believed AI had made them about 20% faster. A rerun with newer tools flipped the result to a modest speedup, with uncertainty wide enough to include no gain at all, and probably understated, because the developers keenest on AI would not join a study that made them work without it.

DORA, which surveys software teams every year, finds the pattern that fits: AI adoption now lifts how much a team ships and still worsens delivery stability. More gets built, and more of what gets built breaks something. 90% of developers surveyed use AI at work; 30% say they have little or no trust in the code it writes.

Heavy use and unsettled results sit together here, and the reason is in what code is.

Code is unusually structured text

Most code is text. It is written in languages with strict grammar. It follows predictable patterns. It is heavily annotated in comments and surrounding documentation.

Four properties make pattern-matching far more powerful on code than on ordinary prose.

A finite vocabulary. Most programming languages have a few dozen keywords, a few hundred commonly used library functions, and a fairly bounded set of names engineers actually give things. Natural language has no such limit.

Clear structural rules. Indentation, brackets, semicolons, the way a function is declared: the structure of code is rigorous and consistent, and a model can learn it exactly. In prose, structure is fuzzier. Comma placement and paragraph breaks are matters of style.

Heavy repetition. The same patterns appear thousands of times across millions of projects. “Open a file, read the lines, close the file” looks roughly the same everywhere it is written. The model has seen each pattern many times over and learned it deeply.

Output a machine can check. Code either runs or it doesn’t. Tests either pass or they don’t. The output can be checked in seconds, by a machine, with no argument about the result. There is no equivalent for “is this paragraph well written?”

The training data advantage

A model trained on the public internet has been fed enormous quantities of code. GitHub holds over 600 million repositories, a large share of them open to anyone. Tutorials, documentation, books and forum posts add billions more lines. When that material feeds into pre-training, the model learns the grammar of dozens of languages, the common library patterns, the naming conventions, the standard solutions to standard problems, and above all the link between a description in English and the code that satisfies it.

Code is also unusually well explained. A typical Stack Overflow answer arrives as one package: the problem in plain English, working code, and a paragraph on why it works. Across more than 20 million questions, that is close to purpose-built teaching material for turning intent into code and code back into an explanation. Few other kinds of work have training data anywhere near this quality. Mathematics has some. Most business writing has none.

New questions on Stack Overflow have since collapsed, because developers ask the model instead. The archive that taught this generation is no longer growing the way it did.

The feedback loop in production

That explains the base capability. One more thing explains why coding agents do better still than the model alone would suggest.

When the model writes code, the world tells it immediately whether the code worked. The compiler says “syntax error on line 7.” The test suite says “expected 5, got 3.” The browser says “no element with that ID.” These signals are fast, clear and automatic.

A coding agent runs on those signals:

1. Model writes a piece of code.
2. Agent runs the code, or the checks written against it.
3. If something fails, the failure message goes back into the model.
4. Model tries again, usually with a smaller, more targeted fix.
5. Repeat until the checks pass.

Nothing tells a model within seconds whether a customer email was the right one to send. So a coding agent can keep correcting itself until the checks pass, and an agent working anywhere else has to produce its answer and wait for a person to say whether it was right.

What code AI is genuinely good at

Repetitive groundwork. Setting up a new project. Writing the standard save, read, update and delete operations that every application needs. Generating configuration files. Writing checks for functions that already exist. The work that takes real time in every project.

Translation. Moving code from one language to another, say Python to TypeScript. Updating a codebase to a newer version of its own language. Moving from one framework to another.

Explanation. Reading a piece of code and saying what it does, in prose. Tracing how a function works. Answering “why is this built this way?”

Refactoring. Restructuring code without changing what it does. Pulling a repeated section out into one place. Renaming things consistently. Splitting a large file into smaller ones.

Writing automated checks. Small programs that run the real code with known inputs and confirm it gives the expected answers. Models often catch edge cases a person would miss, having seen a great many of these.

Narrow, well-defined bug fixes. The error message says “undefined variable on line 42” and the model fixes it. The code fails in one specific case and the model writes a guard against it.

First-draft code review. Reading a proposed change before it goes into the product and pointing out what looks wrong. The model is a useful first reader. A person is still the last one.

Where code AI still struggles

Whole-system understanding. The model sees the function in front of it, the file, sometimes the project. It does not hold the overall architecture, the business domain, or how the separate parts of the system depend on each other. It can make a confident local change that breaks something three layers away.

Novel problems. It is a brilliant pattern-matcher, not an inventor. Where no established pattern exists, it tends to produce something that looks right and doesn’t solve the problem: a perfectly plausible function with subtly wrong behaviour.

Security-sensitive code. The model learned from real codebases, and real codebases contain real security mistakes. The commonest one: text a customer types into a form ends up being treated as an instruction rather than as data, because nothing checked it on the way through. The model has seen that mistake thousands of times and reproduces it. Independent testing through 2026 lands in the same place each time: a little over half of the code models write in security-relevant situations comes out safe, and the failures cluster where the check means following data across several files rather than spotting an obvious pattern. Code AI does not replace security review.

Legacy or unusual frameworks. Internal frameworks nobody outside the company uses, very old languages, obscure libraries. Less training data, weaker output, and the weakness is easier to see here than elsewhere.

Knowing when not to change something. Asked to “improve” working code, the model will. Sometimes the improvement breaks behaviour. Code AI leans towards acting, and well-run teams put checks around that rather than relying on the model to restrain itself.

Long-running plans. A coding agent told to “build me a SaaS application” will not produce a working SaaS application. It will produce many half-built pieces. Agents work on clearly bounded tasks, not open-ended ones.

What code AI actually does to an engineering team

It makes engineers substantially faster. It does not replace them, and the gain is uneven across the team:

• A senior engineer gets meaningfully faster on routine work and ships more reliably on hard work. They already know what good output looks like, and the AI produces a first cut of it.
• A mid-level engineer reaches senior-level output on familiar problems. On hard ones they still need senior review, because the AI does not supply the judgement of someone who has watched things break in production.
• A junior engineer becomes useful faster and still needs code review and mentoring. The AI carries them past the stage of fighting the language itself. It does not teach them why one design is better than another.
• A non-engineer using AI “instead of an engineer” usually produces code that runs and is fragile, insecure or unmaintainable. The constraint was never typing. It was knowing what to build, what to test, and when to stop.

One effect catches teams out. Writing code gets much cheaper and reviewing it does not, so reviewing becomes the constraint. Where the amount shipped doubles and reviewing does not speed up, review becomes the queue, and teams lean harder on automated checks. That is the practical reason a team can adopt AI, ship more, and still feel slower.

The framing that code AI lets a company “fire the engineers” misreads what changed. The framing that holds up: a team of engineers ships more and ships faster with code AI inside their loop than without, and the checking has to be funded alongside it. Different conclusion. Different staffing plan.

What this chapter tells you about AI generally

The 4 properties are a test, and the test is not about code. Most business work has some of them and rarely all 4. The closer a task sits to structured, repetitive and checkable in seconds, the better AI handles it.

Tasks that score well on the same test, and where AI works correspondingly well:

• Data transformation. A spreadsheet goes in, structured output comes out, and the output can be checked against the input.
• Extraction from documents into fields. Checkable against the source document.
• Classification into clear categories. Checkable against known labels.
• Drafting in an established format, such as a status report. Checkable against an agreed standard.

Tasks unlike code, meaning subjective, fuzzy, novel or with no way to tell quickly whether the answer is right, are where AI is weaker and where a person has to supply the verdict. Where AI fits reaches the same test from the other end, starting from the task rather than from the technology.