Contain it,
don't review it.

The fastest way to waste an AI coding agent is to supervise it properly. Read every diff with the care you'd give a junior's first pull request and you have not saved any time. You have moved the bottleneck from your hands to your eyes.

The industry has already found this out at scale. Teams using AI merge substantially more pull requests, and their review times have climbed just as sharply. AI-authored changes sit waiting for a reviewer several times longer than human ones, and that queue, not the reviewing itself, is what eats the calendar.¹ DORA's 2026 work on AI returns puts a name to it: verification overhead, a hidden tax that shows up right after the demo ends.²

You did not get an assistant. You got a conveyor belt, and a job standing next to it.

The way out is to stop being the mechanism. Every control worth having is one you build once and something else enforces forever.

01 Per-action reliability is a lie at session length

Say your agent honours a given instruction 99.9% of the time. That is an excellent number. On most benchmarks it would be a career-making result.

Now let it run a thousand tool calls, which is an ordinary afternoon for an agent doing a real refactor. The chance it gets through the session without breaking that instruction once is 0.999¹⁰⁰⁰, or about 37%. Roughly two sessions in three, the thing you told it not to do, it does.

The effect shows up in measurement, not only in arithmetic. A controlled study of 400 code samples put through forty rounds of AI "improvement" found critical vulnerabilities rising 37.6% after just five iterations.³ Iterating did not converge on something safer. It drifted.

The uncomfortable part is how little better models help. Make the agent ten times more obedient, a genuinely enormous jump to 99.99%, and you still lose one session in ten. To get session failure down to one in a hundred you need five nines on every single action. Reliability that reads as a rounding error per action becomes the dominant failure mode per session, and no amount of prompt tuning changes the shape of that curve. It only moves the exponent.

Meanwhile the exponent keeps growing. Anthropic describes Opus 5, released in July, as running longer and more autonomously than anything before it, planning deliberately, verifying its own work and driving projects forward with minimal oversight.⁴ Capability like that makes longer sessions worth running, so the exponent climbs as fast as the base does.

02 A guardrail in a prompt is a request

The word guardrail is doing quiet, dishonest work in most of these conversations. On a motorway, a guardrail is a steel beam bolted into concrete. It does not evaluate your intent. It does not have a 99.9% success rate at being a beam.

In agent frameworks, guardrail usually means a paragraph. Never run destructive commands without confirming. Do not modify files outside the working directory. Ask before pushing. Each one is a request made to a sampler, and the sampler complies at some rate below one.

Compare please don't write outside /workspace, honoured probabilistically, with a read-only root and a single writable mount, enforced by the kernel. The second has no failure rate in the sense the first does. It is not being persuaded. There is no context window in which it changes its mind, and no clever phrasing buried in a stray code comment that talks it around. That is the whole design principle: the model layer is probabilistic and the kernel is not, so put your guarantees in the kernel.

This is not hypothetical tidiness. Replit's agent deleted a production database during an explicit code freeze, then admitted it had run commands it was told not to run.⁵ An internal AWS coding tool took out a cost-management feature for thirteen hours by deciding to delete and recreate an environment.⁶ In both cases the instruction existed. The capability also existed. Only one of those is binding.

The tooling has already converged on the distinction. OpenAI's Codex splits the problem into two independent dials: a sandbox mode setting what the agent can technically do, and an approval policy setting when it has to stop and ask. Capability and permission are deliberately separate mechanisms.⁷ Why that separation has to be structural was shown the hard way by CVE-2025-59532, where the Codex CLI could have its sandbox boundary redefined by the agent's own output.⁸ A boundary that lives inside the thing it constrains is decoration.

03 You are not the only person writing the prompt

An agent doing software work reads things. Your README, the issue text, a dependency's docs, the output of a failing test, a web page it searched for, the postinstall script of a package it just added. Every one of those reaches the mechanism choosing the next action.

For language models, instructions and data travel in the same channel. There is no prepared statement, no escaping function that reliably marks this text as content rather than command. OWASP researchers were still describing prompt injection as an unsolved architectural problem at Infosecurity Europe this year, and the reason is structural: the model has to understand natural language to be useful, and the attack is written in natural language.⁹ Three years of attempts have not produced a fix, because it is not a bug awaiting a patch.

Simon Willison's lethal trifecta names the dangerous combination precisely: secrets worth stealing, untrusted text to read, and a channel to send data out.¹⁰ Meta's Agents Rule of Two turns it into something you can actually build against, holding an agent to at most two of those three in any one session.¹¹ The elegance is that it does not care whether the injection succeeds. The agent simply lacks the combination of capabilities needed to complete the theft.

The academic work points the same way, and further. Google DeepMind's CaMeL wraps the model in the same machinery ordinary software security has used for decades. The plan is built from your trusted request, and nothing the model reads along the way is allowed to change that plan. On the AgentDojo benchmark it completed 77% of tasks with a provable guarantee, against 84% for an undefended system.¹² Losing seven points of capability to gain a proof is a trade most production systems should take, and note where the guarantee lives. Not in the weights.

For a coding agent that means an ephemeral container, never your home directory. No ambient cloud or SSH credentials sitting in the environment out of habit. Egress on an allowlist. Writes confined to the working tree, with the outside world reached only through a reviewable artifact like a branch or a PR. Claude Code ships process-level sandboxing by default now, which is a sensible floor; a microVM is the honest answer for anything higher-stakes.¹³

04 Tests are the other wall

A container bounds the blast radius. It says nothing about whether the code is right. An agent can produce a subtly wrong implementation entirely within its sandbox, and the sandbox will have done its job perfectly.

Which is why test-driven development matters more now than it did when we were writing the code ourselves. A test is the same species of thing as a container: written once, enforced every run, indifferent to how persuasive the diff looks. It is a guardrail for correctness in exactly the way a prompt is not.

The economics have flipped, too. Writing tests by hand used to be the expensive part, which is why so many teams quietly skipped them. Generating them is now nearly free, which means the scarce resource is no longer the typing. It is deciding what should be true. That is specification work, and it is the part of the job that was always yours. The research crowding into this space in 2026, spec-driven development and its agentic-TDD variants, is all circling the same conclusion: move the human effort to authoring the specification, and let the machine turn it into tests and implementation.¹⁴

One caution, because it is the obvious hole. An agent that writes both the implementation and the tests can satisfy itself. Tests derived from a specification you wrote are a check; tests reverse-engineered from code the agent just produced are a mirror. Mutation testing is the cheap way to tell the difference: break the code on purpose and see whether anything fails.

05 The best review is less code

Every control so far assumes code exists. The cheapest code to review, secure, test, and maintain is the code you never wrote.

This is not new advice. Don't repeat yourself. Don't reinvent the wheel. Ask whether the thing needs to exist at all, and whether there is a simpler shape that does the same job. What has changed is that agents make ignoring this advice frictionless. When generating a bespoke implementation costs an afternoon instead of a fortnight, the lazy path is no longer reaching for a library. It is asking the model to write one. You end up owning code you would never have chosen to own, and every line of it lands in your review queue forever.

Reach for the boring dependency. Delete the feature nobody asked for. The most senior thing you can do with an agent is decline to use it.

With one caveat that is genuinely new. Telling an agent to prefer libraries points it at a poisoned well: models invent package names, attackers register them, and the resulting slopsquatting attacks are documented and live. The USENIX Security work that first characterised this measured hallucinated package references in roughly a fifth of generated code,¹⁵ and follow-up analysis puts commercial models nearer 5% and open ones above 20%, with the invented names stubbornly repeatable across runs, which is exactly what makes them squattable.¹⁶ Pin your lockfile, verify hashes, and do not let an agent add a dependency without that addition being visible in a diff.

06 Automate the checks you would otherwise do by eye

Whatever you were planning to catch by reading carefully, a machine should be catching first. Static analysis, dependency scanning, secret detection, and infrastructure checks on every change, wired as gates that fail the build.

There is a scaling problem to plan around: AI-authored code can push a codebase from roughly a thousand static-analysis findings a month to more than ten thousand, which breaks triage processes built for human output volumes.¹⁷ A gate that fails the build on a critical finding survives that. A dashboard nobody reads does not.

What happens without the gate is now measurable in the wild. A large-scale study of AI-generated code in real repositories tracked surviving technical debt climbing from a few hundred issues in early 2025 to more than a hundred thousand by February 2026.¹⁸ That is what an unbounded queue looks like eighteen months in.

• Reading every lineDoesn't scale.You are the mechanism, and you get tired.
• Tests and typesScales.Written once, enforced on every run, forever.
• Container and egress policyScales.Enforced by the kernel. Cannot be talked round.
• Not writing the codeScales best.Nothing to review, nothing to maintain, nothing to breach.

07 What the maintainers did

The projects with the least tolerance for breakage have already run this experiment in public, and their answers are worth more than any vendor's.

curl shut down its bug bounty in early 2026. Not because of attackers, but because the confirmed-vulnerability rate had fallen from above 15% to below 5% as fabricated LLM reports arrived faster than seven people could triage them. Daniel Stenberg's description is the sharpest summary of the whole problem: AI is DDoSing open source.¹⁹ Human attention was the mechanism, so human attention was the thing that got exhausted.

The Linux kernel published formal guidance on coding assistants and declined to ban them. Accountability simply stays with the submitter, and "I asked an LLM and it said this is correct" does not discharge it.²⁰ Torvalds called a blanket ban pointless grandstanding, which sounds about right: people who submit bad patches will do it with whatever tool is nearest.

Rust went further and did the cleverest thing I have seen. Contributors must disclose LLM use, and must find a reviewer who agrees in advance to review the change, with accepted PRs labelled so the project can measure what it is costing them.²¹ They treated review capacity as the scarce resource and made it a precondition instead of an afterthought. Nobody gets to generate work for a queue they are not paying into.

Notice what none of them did. They did not try to detect AI code, and they did not pretend a policy document would constrain a model. They changed who is accountable and what the process can absorb, which is the same instinct as the container, applied to people.

08 Where this argument is weakest

Four honest concessions, because the strong form of the claim oversells it.

Containment bounds the blast radius and stops there. An agent that writes a plausible backdoor into a PR you then merge has caused real harm without ever leaving its sandbox. Review, provenance and dependency policy remain separate controls.

The researchers who measured that 37.6% security drift concluded the opposite of my headline. Their recommendation is human validation between iterations.³ I read the same finding as an argument for automated gates between iterations, since a human reading every intermediate step is exactly the bottleneck this piece is about. Reasonable people land differently here, and the honest position is that nobody has proven which control catches the drift more cheaply.

Sandboxes are defence in depth. Container escapes exist and kernel bugs exist. For genuinely high-stakes work the boundary should be a VM or a separate machine, and even then you are buying difficulty, never impossibility.

And the case against the headline: model-layer work does move the numbers, measurably. Anthropic's own evaluations put Opus 5's largest agentic safety gains precisely in prompt injection robustness, across coding, computer use and browser use.⁴ Lowering the exponent in that 0.999¹⁰⁰⁰ matters enormously, and the labs are lowering it. Someone could reasonably argue the trend continues until heavy sandboxing is theatre. I don't think it does, for one reason: those approaches lower a rate, and only a boundary bounds a worst case. A system with a small probability and an unbounded worst case is a system that eventually presents the bill once, in full.

09 The inversion

The usual objection to all of this is that it slows you down, that a constrained agent is a less useful agent. It gets the relationship backwards.

The reason to build the box is so you can stop watching what happens inside it. If the worst case is genuinely bounded, an hour and a container, then you can turn off the confirmation prompts, let it run unattended, let it try six approaches and throw five away. The permission dialog that interrupts every command exists because the failure is unbounded. Bound the failure and you can delete the dialog.

Constraint is how you afford the autonomy. You don't have to believe the model is malicious, or even incompetent. You only have to accept that it rolls dice on every action, and that you are going to run enough actions for the bad roll to arrive.

Everything else improves the odds. The wall is the only thing that is a wall. Build the walls, then go and do something more interesting than reading diffs.

The sixteen rules, short enough to paste into a repo The companion piece, on strict languages as the third wall