AI Programming in 2026: Specs, Loops, and Review Gates

AI programming in 2026 works when you treat the model as a fast implementer inside a loop you control, and it fails when you treat it as a conversation partner. Three things separate the two: a written spec, an automated test loop, and a review gate you never skip. The capability question is settled. The workflow question is where the time and money still go, so here is the current data, the arithmetic, and the setup I run every day.

TL;DR

• The 2026 AI Index from Stanford HAI reports that on SWE-bench Verified, which scores agents on real software engineering tasks, performance rose from 60 percent to near 100 percent in a single year. Model capability is not your bottleneck.
• METR's randomized controlled trial, published 10 July 2025, put 16 experienced developers on 246 real issues and measured them 19 percent slower with AI. They believed they had been 20 percent faster.
• The 2025 Stack Overflow Developer Survey found 84 percent use or plan to use AI tools, while 45.7 percent distrust the accuracy of the output against 32.7 percent who trust it. Only 3.1 percent highly trust it.
• GitClear's January 2026 research across 623 million code changes found duplicated blocks up 81 percent since 2023 (40.3 to 73.0 per million changed lines) and refactoring line moves down 70 percent.
• At Google Cloud Next on 22 April 2026, Sundar Pichai said 75 percent of all new code at Google is AI-generated and approved by engineers, up from 50 percent the previous fall. The word doing the work in that sentence is "approved."

The capability jumped. The workflow did not.

Two numbers tell the whole story of the last year. Stanford's AI Index has SWE-bench Verified going from 60 percent to roughly 100 percent. METR has experienced developers getting 19 percent slower on their own repositories. Those are not contradictory findings. They measure different things: one measures whether the model can produce a correct patch, the other measures whether a human plus a model ships faster than a human alone.

Adoption is not the gap either. Google's 2025 DORA report, published 23 September 2025 from nearly 5,000 technology professionals, found 90 percent using AI at work and more than 80 percent believing it increased their productivity, while 30 percent reported little or no trust in the code it produces. GitHub's Octoverse, published 28 October 2025, counted about 1.13 million public repositories importing an LLM SDK, a 178 percent jump year over year. Everyone is using it. Most people do not have a process around it.

DORA's own framing is the useful one: AI is an amplifier. It makes a team with tests, small diffs, and fast CI noticeably faster. It makes a team without those things produce broken work at a higher rate. The tool is the same in both cases.

Write the spec before you write the prompt

The single change that moved my hit rate the most was refusing to prompt until I had written down what "done" means. Not a document. Five to ten lines, in the repo, before the model sees anything.

Here is a real one from the pipeline that builds these posts:

• Change: build-blog.mjs should accept --hero <path> for a local file, not just a URL.
• Must not change: the existing URL path, the JSON-LD output, or src/data/blog.json field order.
• In scope: scripts/build-blog.mjs only.
• Done when: node scripts/build-blog.mjs test-slug --hero ./x.png writes the image into public/blog/ and the existing URL flow still passes.
• Failure mode to avoid: silently falling back to the offline banner when the path is wrong.

That last line is worth more than the other four combined. Models default to graceful fallbacks, which is exactly how you end up shipping a post with the wrong hero image and no error. Naming the failure mode up front costs you eight seconds and removes an entire round trip.

The general shape: what changes, what must not change, which files are in scope, how you will know it worked, and what wrong-but-plausible answer you refuse to accept. If you cannot write those five lines, the task is not ready for a model, and it probably was not ready for you either. I go deeper on the artifacts an AI project needs in AI development in 2026.

Run a loop, not a conversation

A conversation is you pasting an error into a chat box and pasting code back out. A loop is the model running the command itself, reading the real output, and patching. The difference in throughput is not subtle, because in a conversation you are the message bus between the compiler and the model.

The rule that makes this work: step 03 has to be a single command. Not "run the tests, then check types, then start the dev server and look at it." One command that exits non-zero when anything is wrong. If a model has to ask you what happened, the loop is broken and you are back to a conversation.

The second rule: the model reads raw output, not your summary. A stack trace has the file, the line, and the value. Your paraphrase has none of that. I wrote up the full pattern, including the prompt structure that keeps a loop from wandering, in Write Loops, Not Prompts.

The gate is where you pay the quality tax

Speed without a gate produces a specific, measurable kind of damage, and we now have the numbers. GitClear's January 2026 analysis of 623 million changes found within-commit copy/paste up 41 percent since 2023, code block duplication up 81 percent, error-masking constructs up 47 percent, and two-week churn up 15 percent, while refactoring line moves fell 70 percent against 2022.

That pattern makes sense once you know how a model writes code. Asked to add a feature, it writes a new block. Reusing the helper that already exists three directories away requires context it usually was not given. The output compiles, passes review at a glance, and quietly doubles your surface area.

Gate 01 is the one people fight and the one that pays. A model will happily hand you a 900-line diff, and nobody reviews 900 lines honestly. Cap it, and the model has to decompose the work, which is also how you find out it misunderstood the task at line 40 instead of line 700.

Gate 03 is cheap to automate. A duplication check in the same command as your tests catches the copy-paste growth before it compounds. Gate 05 has no automation, which is why it is the first to go on a Friday, and why Google's 75 percent number is stated as "AI-generated and approved by engineers" rather than just "AI-generated."

Where AI programming still costs you time

The Stack Overflow survey named the tax precisely: 66 percent of developers said their top frustration is "AI solutions that are almost right, but not quite," and 45.2 percent said debugging AI-generated code is more time-consuming. Trust has been falling while adoption rises. Stack Overflow's own analysis, published 18 February 2026, notes that trust dropped from about 40 percent in 2024 to 29 percent in 2025 while usage climbed to 84 percent.

Here is the arithmetic on a two-hour task, roughly the average size in the METR study. Without AI: 30 minutes reading the surrounding code, 60 writing, 30 testing. Total 120.

With AI, writing drops to 15 minutes. But three new costs appear: 10 minutes assembling context and writing the prompt, 25 minutes reading a diff you did not write, and 20 minutes on the one function that looked correct and was not. Total: 30 + 10 + 15 + 25 + 20 + 30 = 130 minutes. Eight percent slower, and the model wrote most of the code. That is METR's 19 percent in miniature.

A better model does not fix this. Cutting the 25 and the 20 does. The spec cuts the 20, because the acceptance criteria and the named failure mode are in front of the model before it writes. The loop cuts the 25, because the tests read the diff before you do, so you are reviewing a change that already passes rather than hunting for whether it works. Choosing the right tier for the job matters here too, and I broke that down in how to choose an AI model.

The setup I actually run

Nothing exotic. Five pieces, and every one of them exists because skipping it cost me a day at some point.

1. A CLAUDE.md at the repo root with the stack, the commands, the conventions, and the three things that break if you touch them. This is context the model would otherwise guess at every session.
2. One command for verification. Mine runs tests, type check, and lint together and exits non-zero on any failure. The model runs it, not me.
3. A spec file per task, five to ten lines, written before prompting, deleted after merge.
4. A diff cap. If it crosses 200 lines, I stop and split the task rather than skim.
5. Evals for anything where the model is in the product, not just in my editor. Different problem, same principle: write the pass condition before the feature. That workflow is in how to test an AI agent.

If you want the prompt patterns that go inside this, they are collected in The Code Book, which is the reference I keep open while working.

The bottom line

AI programming stopped being a capability question when SWE-bench Verified went from 60 to near 100 in a year. It is now a process question, and the process is unglamorous: write down what done means, put the model in a loop that runs its own tests, and hold every diff to a gate. Teams that do this report real gains. Teams that skip it generate 81 percent more duplication and call it velocity.

The 19 percent slowdown METR measured is not an argument against the tools. It is a measurement of what happens without a workflow around them. Build the workflow and the same tools go the other direction.

Start with one repo this week. Write the CLAUDE.md, collapse your checks into a single command, and cap your diffs at 200 lines. Then grab The Code Book for the prompt patterns that run inside that loop, and join the newsletter for the builds and numbers I publish before anyone else sees them.