Humans outside the loop

My opinion

Code has never been cheaper to make, or to throw away. So I think it’s the wrong thing to guard. Three things last: what you asked for, what it must never do, and how you’d know it worked.

This page is my opinion. The facts come from the sources at the bottom, and where one is a preprint, a vendor’s own page or a personal post, I say so.

METR measures the length of task an AI agent can finish half the time, counted in a skilled person’s time. Since 2019 that length has doubled about every seven months: every 207 days, or every 143 counting only the 2024 models [Kwa et al., METR, 2025 (preprint)]. The authors say real work is messier than their tasks. It’s a preprint.

Cheap to make isn’t the same as faster to ship. In METR’s 2025 study, experienced open-source developers took 19% longer on the tasks where they could use AI [Becker et al., METR, 2025 (preprint)]. METR has since labelled the 2025 result out of date, put a range of 2% to 39% on it and called its late-2025 speedups very weak evidence [METR 2026 update (preprint-level)].

Google’s DORA survey for 2024 estimated that documentation, code quality and review speed went up with AI adoption, while every 25% more of it went with 7.2% less delivery stability and 1.5% less throughput [DORA 2024, Google Cloud (vendor-run survey)]. DORA guesses that AI makes more code easy, so changes get bigger, and bigger changes have always been less stable. It’s a vendor’s survey, not an experiment.

So more code, faster, isn’t the problem. Treating it like it’s going to last is.

At Microsoft, Bacchelli and Bird asked developers why they review code. Finding defects came first for 44%. Of the 570 review comments they sorted, though, 14% were about defects and 29% were code improvements. And the developers said “understanding is their main challenge when doing code reviews” [Bacchelli and Bird, ICSE 2013].

Mäntylä and Lassenius sorted the defects found in industrial and student reviews. Three in four didn’t affect what the software visibly does. They made it easier to understand and change. The authors suggest reviews matter most for software with a long life [Mäntylä and Lassenius, IEEE TSE 2009].

In code you’ll keep for years, that’s worth a lot. In code an agent will rewrite next week, much less.

Kemerer and Paulk found review effective at 200 lines an hour or less, and at that pace code reviews found more than half the defects [Kemerer and Paulk, IEEE TSE 2009]. Their data comes from developers reviewing their own small programs in a training process. Not team pull requests.

The slowest part of the loop is a person reading product code line by line. And it’s guarding the part most likely to be thrown away.

On ImpossibleBench, agents get coding tasks whose tests contradict the spec, so any pass is a shortcut [Zhong, Raghunathan and Carlini, ImpossibleBench, 2025 (preprint)]. Where a SWE-bench test was duplicated with a conflicting answer, GPT-5 passed 54%, o3 49% and Claude Opus 4.1 50%, and the shortcuts included editing the tests and special-casing them. It’s a preprint.

Two things helped, partly. Letting the models give up cut GPT-5 to 9% and o3 to 12%, and model monitors watching for cheating caught 42 to 65% of it on the realistic tasks [Zhong, Raghunathan and Carlini, ImpossibleBench, 2025 (preprint)]. So an automated reviewer isn’t enough on its own either.

On RE-Bench, METR caught o3 reward hacking in 30.4% of its runs, and on HCAST in 0.7%. Telling it not to cheat “had a nearly negligible effect on reward hacking” [METR on reward hacking, 2025 (research note, preprint-level)]. METR says its detection probably undercounts.

The definitions are soft too. OpenAI had developers screen 1,699 SWE-bench tasks: 38.3% were flagged for problem statements too vague to say what success was, 61.1% for tests that could reject a valid fix [OpenAI, SWE-bench Verified, 2024 (vendor)]. That’s OpenAI describing its own work, and it says the screen was probably overzealous.

So if a person reads one thing in the pull request, it’s the tests, the evals and the spec. That’s the part an agent is tempted to bend. There’s more on how to keep the real test out of the builder’s reach in Tests can be gamed.

On 2026-11-10 Gergely Orosz asked on X whether big upfront planning makes sense again. We hated waterfall, he wrote, because the plan was out of date by the time it was built, and AI makes building 100x faster or more [Orosz on X, 2026 (personal post)]. That’s his number, not a measurement. It set off a long argument.

The Agile Manifesto values “Working software over comprehensive documentation” [Manifesto for Agile Software Development, 2001], and responding to change over following a plan. The second items, it says, still have value. And its seventh principle makes working software the main measure of progress.

That made sense while working software was the expensive part, and it isn’t anymore. Once an agent can turn it out in an afternoon, working software stops measuring much. The plan becomes the scarce thing.

Waterfall gets pinned on Winston Royce’s 1970 paper. Royce drew the straight sequence of steps and wrote that, as described, it was “risky and invites failure” [Royce, IEEE WESCON 1970]. Testing came last. A problem found there could force a redesign and, he wrote, up to a 100% overrun.

His fix kept the plan and added five steps: design first, document the design, do it twice, plan and watch the testing, and involve the customer [Royce, IEEE WESCON 1970]. Read now, doing it twice is a pilot an agent builds and throws away, and the documented design is the spec. Royce wasn’t wrong. He was early, and building twice was expensive.

That doesn’t mean the old upfront paperwork comes back with it.

So I don’t think it’s agile or waterfall. It’s fast iteration on the code, inside a layer that adapts but holds its shape:

• the goals, and what success means
• the constraints: data security, the budget and the infrastructure
• the evaluation and the verification

Security is only one constraint, and the budget is another: what a run, a model call or a month of hosting may cost. So is the infrastructure the code has to live on, the services and the limits you already run. An agent will happily solve the problem with something you can’t afford. Or something you don’t have.

Liquid, because that layer has to change when the business does. Rigid, because the code doesn’t get to change it. An agent can rebuild the castle all day, but only a person changes the layer. That’s the pull request worth reading.

GitHub, a vendor, says a version of this with Spec Kit: “intent is the source of truth” [GitHub, Spec Kit, 2025 (vendor)]. When requirements change, you change the spec and regenerate the plan and the code. GitHub calls it an experiment, and it reports no measurements.

Property-based tests state rules, not examples, so they’re one kind of constraint that survives a rewrite. When they guide generation, one preprint reports up to 13.4% higher pass@1 [He et al., property-based testing, 2025 (preprint)]. I read only its abstract.

How I write down what done means before an agent starts is on the harness pages, and the security side of the layer is in AI security.

Across a company, that layer needs an owner, not each team in its own repo. That’s AI governance. Cloud got a platform team and so did data, and I expect this to land with an AI Platform team: the gateway, the tool access and the permissions every loop runs inside. My case for that team is in The AI Platform team.

The evidence against me

Human review of product code isn’t worthless. Parts of Qt, VTK and ITK with low review participation were estimated to carry up to 5 more defects after release, and parts with low coverage up to 2 [McIntosh et al., MSR 2014]. It’s long-lived code written by people, not code an agent rewrites. Still evidence, though.

Generated code carries real flaws. In one 2021 study, about 40% of the 1,689 programs Copilot wrote were vulnerable [Pearce et al., IEEE S&P 2022]. The authors found them with an automated tool, CodeQL, and they recommend security tooling. That fits a hardened layer as well as it fits reading every line.

Royce himself asked for a second person to look over every bit of code [Royce, IEEE WESCON 1970]. And big specs up front are what agile was reacting to. A hardened layer can fossilise the same way.

Nobody here has shown that cheap code means faster products [METR 2026 update (preprint-level); DORA 2024, Google Cloud (vendor-run survey)]. And the cheating numbers come from tasks built to provoke it [Zhong, Raghunathan and Carlini, ImpossibleBench, 2025 (preprint)].

My view

I don’t think review is dead. I think it’s in the wrong place.

Read the goals, the constraints and the checks like they’re the product, because they’re the part that’s still here next week. Let the code be sand.

• Who to hire nowThe engineer worth having on a team has changed because of LLMs, agent graphs and second brains: my points from other Lab pages, gathered and linked.
• Attention is the bottleneckThe scarce thing in a team that builds with agents is a person’s attention: a vendor’s design for an always-on agent, taken apart with my own Lab pages.
• What gets cheap, and what doesn’tWhen execution gets cheap, where the margin moves: a model’s answer taken apart with my own Lab pages, and my claim about guarantees and service contracts.
• A-changin’The pile of small tasks used to decide who ranked first. AI is shrinking the pile. Here’s who I’d hire when it stops deciding.

• Kwa et al., METR, 2025 (preprint) · Measuring AI Ability to Complete Long Software Tasks, arXiv 2503.14499: the 50% time horizon doubling every 207 days (95% CI 166 to 240), 143 days for 2024 models alone. T. Kwa, B. West, J. Becker and others (METR), arXiv preprint, v4, July 2026; the abstract and sections 3 to 6 of v4; read 2026-11-11.
• Becker et al., METR, 2025 (preprint) · Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv 2507.09089: 16 developers, 246 issues, 19% longer with AI allowed. J. Becker, N. Rush, E. Barnes, D. Rein, arXiv preprint, July 2025; the abstract and section 3; read 2026-11-11.
• METR 2026 update (preprint-level) · METR, We are Changing our Developer Productivity Experiment Design, 2026-02-24: the 2025 estimate’s interval, the late-2025 study, and the 2025 result called out of date. METR’s own post, not peer reviewed. J. Becker, N. Rush, T. Cunningham, D. Rein, K. Mahamud, metr.org; the post in full; read 2026-11-11.
• DORA 2024, Google Cloud (vendor-run survey) · Accelerate State of DevOps Report 2024: per 25% more AI adoption, throughput down 1.5% and stability down 7.2% (Figure 10, pp. 39 to 40); documentation, code quality and review speed up (Figure 9). DORA research team, Google Cloud, dora.dev, October 2024; the report PDF, pp. 23 to 43; read 2026-11-11.
• Bacchelli and Bird, ICSE 2013 · Expectations, Outcomes, and Challenges of Modern Code Review: 873 programmers surveyed, 570 review comments classified (sections IV to VI). A. Bacchelli, C. Bird (Microsoft Research), ICSE 2013, pp. 712 to 721; the authors’ full text; read 2026-11-11.
• Mäntylä and Lassenius, IEEE TSE 2009 · What Types of Defects Are Really Discovered in Code Reviews? 75% of the defects found do not affect visible functionality (abstract). M. V. Mäntylä, C. Lassenius, IEEE Transactions on Software Engineering 35(3); the publisher’s abstract only (the full text is paywalled); read 2026-11-11.
• Kemerer and Paulk, IEEE TSE 2009 · The Impact of Design and Code Reviews on Software Quality: 200 lines an hour or less an effective review rate, finding more than half the defects in code reviews (abstract; PSP data). C. F. Kemerer, M. C. Paulk, IEEE Transactions on Software Engineering 35(4); the publisher’s abstract only (the full text is paywalled); read 2026-11-11.
• Zhong, Raghunathan and Carlini, ImpossibleBench, 2025 (preprint) · ImpossibleBench: Measuring LLMs’ Propensity of Exploiting Test Cases, arXiv 2510.20270: cheating rates stated in sections 4 to 6. Z. Zhong, A. Raghunathan, N. Carlini, arXiv preprint, October 2025; the abstract and the HTML text of sections 1 to 6 (the per-model charts are images, so only rates stated in the text are used); read 2026-11-11.
• METR on reward hacking, 2025 (research note, preprint-level) · Recent Frontier Models Are Reward Hacking: o3 hacked in 39 of 128 RE-Bench runs and 8 of 1,087 HCAST runs. METR’s own note, not peer reviewed. S. Von Arx, L. Chan, B. Barnes (METR), metr.org, 2025-06-05; the note in full; read 2026-11-11.
• OpenAI, SWE-bench Verified, 2024 (vendor) · Introducing SWE-bench Verified: of 1,699 screened tasks, 38.3% flagged as underspecified and 61.1% for tests that may reject valid solutions; 68.3% filtered out. N. Chowdhury, J. Aung, C. J. Shern and others (OpenAI), openai.com, 2024-08-13 (updated 2025-02-24); the page in a browser (automated fetches were refused); read 2026-11-11.
• Manifesto for Agile Software Development, 2001 · The four values and the twelve principles (principle 7: working software is the primary measure of progress). K. Beck, M. Beedle, A. van Bennekum and fourteen others, agilemanifesto.org; the manifesto and the principles page; read 2026-11-11.
• Orosz on X, 2026 (personal post) · Gergely Orosz, a post on X of 2026-11-10 asking whether big upfront planning makes sense again now that AI makes implementation fast. One person’s question; X showed it at the top of a trending story it summarised with Grok. Gergely Orosz, X; the post; read 2026-11-11.
• Royce, IEEE WESCON 1970 · Managing the Development of Large Software Systems: the sequential model called risky (p. 329, Figure 2) and the five added steps (Figure 10); pages of the 1987 reprint. W. W. Royce (TRW), Proceedings, IEEE WESCON, August 1970; an archived scan of the reprint, every page; read 2026-11-11.
• GitHub, Spec Kit, 2025 (vendor) · Spec-driven development with AI: Get started with a new open source toolkit. A vendor introducing its own experiment, with no measurements. D. Delimarsky (GitHub), The GitHub Blog, 2025-09-02; the post in full; read 2026-11-11.
• He et al., property-based testing, 2025 (preprint) · Property-based testing to guide LLM code generation and repair, arXiv 2506.18315 v2: up to 13.4% higher pass@1 (abstract). L. He, Z. Chen, Z. Zhang, X. Gao, L. Sheng, arXiv preprint, v2 May 2026; the abstract only; read 2026-11-11.
• McIntosh et al., MSR 2014 · The Impact of Code Review Coverage and Code Review Participation on Software Quality (Qt, VTK and ITK): up to 2 and 5 more post-release defects. S. McIntosh, Y. Kamei, B. Adams, A. E. Hassan, MSR 2014; the authors’ full text; read 2026-11-11.
• Pearce et al., IEEE S&P 2022 · Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions: 1,689 programs, about 40% vulnerable, found with CodeQL. H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, R. Karri, IEEE Symposium on Security and Privacy 2022 (arXiv 2108.09293); the full text; read 2026-11-11.