How To Stop AI From Shipping Bad Code

Ten AI agents can write a week of code in an afternoon. The uncomfortable part is that nobody has figured out how to review a week of code in an afternoon, and that gap is exactly where broken software slips into production.

For most of the history of software, the slow step was writing the code. You hired engineers, you paid them well, and you waited while they turned an idea into working features. Everything downstream, the reviews, the testing, the deploys, was shaped around the assumption that new code arrived slowly. Now that assumption is gone. A coding agent can open a dozen pull requests before lunch. The writing is fast, cheap, and tireless. What has not scaled with it is the human judgment that decides whether any given change is safe to merge.

The bottleneck quietly moved, and most teams have not noticed

I keep meeting owners and small teams who are thrilled that an agent can produce features overnight, and then baffled a month later when their app keeps breaking in ways nobody can trace. The two feelings are connected. When code was scarce, a broken change was rare and easy to spot. When code is abundant, broken changes hide in the flood. The volume that feels like a superpower is also what makes quality control the new hard problem.

This is not an argument against AI writing code. I think handing routine implementation to an agent is one of the best moves a small business can make. It is an argument that the safeguards have to move to wherever the new risk lives, and right now the risk lives in the merge, not the keystroke. If you are going to let software write software, you need a way to prove each change works before it reaches a customer, and you need that proof to be cheap enough to demand every single time.

Why parallel agents fight each other on one machine

Picture the naive version of this setup. You run several agents on your laptop or on one server. They all share the same database, the same ports, the same file system, the same background services. The first agent changes the shape of a database table to add a feature. That change is perfectly reasonable in isolation. But every other agent is now working against a database that no longer matches the code it was writing. One session quietly poisons all the others, and you spend the afternoon untangling failures that have nothing to do with the features themselves.

Even without a database change, the collisions pile up. Two agents try to start a development server on the same port. A third rewrites a shared configuration file mid-run. A fourth installs a dependency that conflicts with what a fifth expected. None of these are exotic bugs. They are the ordinary friction of shared state, and shared state is precisely what you have when many workers occupy one environment. The more agents you add, the worse it gets, and the whole point of using agents was to add more of them.

The instinct is to isolate the code. Tools that give each task its own working copy of the repository help, because at least the edits do not overwrite each other. But a copy of the files is not a copy of the running system. To actually test a change, you need the app alive: a server responding, a database holding data, the whole thing behaving the way it would for a real user. File isolation without runtime isolation still leaves every agent sharing the one live environment, and that is where the collisions come back.

The move that fixes it: give every agent its own disposable world

The version that works is almost boring once you see it. Each agent gets its own isolated cloud box. Not a shared server with careful rules, but a genuinely separate environment: its own database, its own dev server, its own everything. The agent does its work there, in a world it cannot break for anyone else, because nobody else is in it. When the work is done and verified, the box deletes itself. No cleanup, no leftover state, no slow corruption of a machine that has been running for months.

Throwaway is the key word. A box that warms up, runs one job, proves the result, and then vanishes has no history to accumulate problems. You can run as many of these in parallel as your budget allows and none of them can touch another. The thing that made parallel agents dangerous, shared state, simply does not exist anymore. Ten agents become genuinely independent workers rather than ten roommates fighting over one kitchen.

The other half of the workflow is how you get code into and out of these boxes without drowning your repository in noise. The naive way is to commit every experimental change so the cloud box can pull it, which spams your history with dozens of junk commits per feature. The better pattern syncs your uncommitted local changes straight to the box, so you can retest in seconds without polluting the repo. You keep the fast feedback loop and a clean commit history at the same time, which matters more than it sounds like when you are iterating twenty times an hour.

Evidence, not vibes, is what makes a merge safe

Here is the discipline that turns all of this from a clever setup into an actual safety system. Do not let an agent tell you the change works. Make it show you. Every pull request should arrive with proof attached: a screenshot of the feature rendering correctly, a short screen recording of the flow working end to end, the output of the tests running green in that isolated box. The reviewer's job stops being archaeology and becomes verification. You are not reading five hundred lines of diff trying to imagine whether they behave. You are looking at evidence that they already did.

This changes the review from the slowest step back into a fast one, which is the whole game. When a human has to mentally simulate every change, review cannot keep pace with generation and the queue backs up until people start rubber-stamping merges just to clear it. Rubber-stamped merges are how broken code reaches customers. When the proof comes in the pull request, a reviewer can clear a legitimate change in a minute and confidently reject one that lacks evidence. The bottleneck reopens.

There is a marketing lesson buried in this that I cannot resist pointing out, because it is the same principle in a different costume. The reason evidence works is that it is verifiable and specific rather than a general claim. The exact same thing is true of the ads and landing pages a business runs. A vague promise converts worse than a concrete proof, which is why a screen recording of a product working outperforms a paragraph swearing that it does. If you run Facebook and Instagram ad campaigns, the creative that shows the result beats the creative that merely asserts it, and the reason is identical to why an agent's screenshot beats its say-so.

Defining the box once so any agent can rebuild it

For this to be repeatable rather than a hero effort, the environment has to be described in code. A single container definition plus a small configuration file captures everything the app needs to run: the language runtime, the dependencies, the database, the startup commands. Once that description exists, any agent can spin up an identical box on demand, run its work, and tear it down. The environment stops being a fragile thing that lives on one person's laptop and becomes a recipe anyone, human or agent, can execute perfectly every time.

That reproducibility is what lets you scale the count. If every box is built from the same definition, box number one and box number fifty behave the same way. There is no drift, no "works on my machine," no special server that only one person knows how to restart. The environment is disposable because it is defined, and it is defined because you need it disposable. The two properties reinforce each other, and together they are what let a small team run agents the way a large team runs employees.

A worked example: a small software shop drowning in merges

Consider a four-person product studio that builds and maintains web apps for a handful of clients. They started using coding agents heavily and their output shot up, but so did their breakage. In a representative bad month they logged eighteen broken merges, changes that passed a casual review and then failed in production, each one costing an hour or two of emergency fixing and a chunk of client trust. The agents were fast, but the studio was shipping the mess straight to customers because review could not keep up.

They restructured around isolated boxes. Each agent task now runs in its own disposable cloud environment built from one container definition. Uncommitted changes sync straight into the box, the agent runs the app and the full test suite there, and it captures a screen recording plus green test output that gets attached to the pull request automatically. The reviewers changed their rule to something blunt: no evidence, no merge. Nothing gets looked at seriously until the proof is in the request.

By the fourth week, broken merges dropped to around seven. The reviewers were no longer trying to imagine whether changes worked because they could watch that they did. By the twelfth week the number settled near two, and the ones that slipped through were genuinely subtle edge cases rather than obvious regressions. The illustrative math is worth stating plainly: if each broken merge costs roughly two hours of firefighting plus the softer cost of a nervous client, cutting from eighteen to two saves something like thirty hours a month of pure recovery time, and it converts the client relationships from anxious to confident. None of that came from the agents writing better code. It came from refusing to merge anything that had not proven itself in a world where it could not hurt anyone.

That studio also noticed a second-order benefit. Because their environment was now defined in code and their leads and project data lived in a tidy CRM and website stack, onboarding a new client project took hours instead of days. The same discipline that made merges safe made everything else reproducible. When your systems are described rather than improvised, you spend your time on the work that only you can do rather than on rebuilding the same scaffolding over and over.

Where this leaves a business owner deciding what to automate

The takeaway is not that AI code is dangerous and you should avoid it. It is that abundance changes where you have to be careful. When something becomes cheap and fast, the scarce resource becomes the judgment about whether it is any good, and your systems should concentrate there. Isolate every agent so it cannot break the others, make every change prove itself with evidence in an environment where failure is harmless, and merge only what has been shown to work. Do that and you get the speed of many agents without the chaos of many agents.

You can absolutely build this harness yourself if you enjoy the plumbing, and plenty of capable owners do. The setup is not exotic; it is disposable boxes, a defined environment, a sync step, and an evidence rule. But wiring it so it runs reliably across every project, with the container definitions and the proof pipeline dialed in, is the kind of thing that eats a few weeks of trial and error the first time. If you would rather have that foundation built and handed over working, so your team simply ships with confidence from day one, that is exactly the kind of setup worth a focused conversation. Either way, the principle holds: in a world where code writes itself, your edge is the discipline that keeps the broken code out.