AI software factory limits: tests, maintenance and review

Imagine that an agent adds a feature and all its tests pass. It adds a second feature with the same result. Then a small rule change requires finding three copies of the same code. The earlier tests did not tell you how hard that next task would be.

What passing tests do not tell you#

A test checks the behaviour it was written to check. It may not cover a missing requirement or reveal that several parts of the application implement the same rule differently. Even a feature that works exactly as specified can solve a problem users do not have.

Release success answers another limited question. The application may start correctly, but the team may still be unable to restore the previous state after a bad data migration. Do not treat “the tests passed” or “the deployment finished” as an answer to every question about the change.

Try changing the same rule a second time#

In this illustrative example, browser uploads have a size limit. An administrator screen copies the comparison, and a batch importer copies it again. Ordinary uploads pass through all three paths. The tests for those cases pass too.

Now the application needs a customer-specific limit on every path. Updating one validator is not enough. The developer or agent must find all three copies and make sure they follow the same rule.

New requirement: use a customer-specific upload limit on every entry path.

Copied decisions

• Browser upload↓Local limit rule · change here
• Admin upload↓Local limit rule · change here
• Batch import↓Local limit rule · change here

Find and update each copy; check that they still agree.

One shared policy

• Browser upload
• Admin upload
• Batch import

↓

Shared limit policy · change here

Change the shared decision; still test every entry path.

The design conditionSharing helps only when these paths genuinely follow the same policy. Different rules should not be forced together because the code happens to look alike.

Illustrative dependency map, not a measured speed-up. Fewer policy definitions reduce one maintenance obligation; they do not remove integration testing.

Putting a genuinely shared rule in one place can reduce the number of decisions that must change together. It does not remove the need to test the callers. A helper can be correct while one upload screen never calls it.

First check that the rules really are the same. Administrative uploads may intentionally have a different limit. Forcing them into one abstraction could hide a useful distinction. The question is not simply “Is any code duplicated?” It is “Which behaviour must stay the same when this rule changes?”

Check what a benchmark measures#

SWE-bench evaluates fixes to repository issues using tests. That can help compare performance on those tasks. It does not by itself show how easy the resulting code will be to change over the next year.

Before applying a result to your own factory, check what counted as success and which attempts were included. Did later tasks build on earlier generated changes? Did the evaluation include a person’s review and correction time? Those questions matter when the aim is to maintain an application rather than solve isolated tasks.

A successful demo does not establish a universal success rate. One difficult example does not establish universal failure either. Describe the observable result and its setting. Do not infer a provider’s undisclosed training objectives from one disappointing output.

In his August 2026 interview, Dex Horthy argues for roughly two to three times faster production coding while preserving quality, rather than assuming tenfold gains. This is his practitioner assessment, not a controlled benchmark or a universal ceiling. Measure your own workflow, including planning, review and corrections, before treating any multiplier as an expectation.

Write checks for rules the team has agreed on#

Once the team agrees that every upload must use one policy, it can add checks for that rule. A code-structure test might reject a dependency in the wrong module. Behaviour tests can exercise uploads through each screen and importer. Neither test decides which policy the product should have.

The tools and checks around an agent are often called its harness. OpenAI’s February 2026 engineering report describes using architecture checks and recurring cleanup in one agent-built repository. It also leaves longer-term design questions open. The practical idea is to test a known rule where possible, not to assume that automated checks settle every design choice.

Anthropic’s long-running-agent report describes incremental work, saved progress and end-to-end checks. These are changes you can try against a specific failure. Adding another agent or a longer prompt without identifying the problem gives you less to evaluate.

In the upload example, another coding attempt cannot decide which customers should receive a larger allowance. An authorised person must settle that question. The harness guide explains how tools can enforce an agreed restriction; 12-factor agents explains how to keep proposed actions, approval and execution separate.

Choose autonomy by what can be checked#

Compare two proposed tasks. One tries to reduce test-job runtime while preserving the required tests and equivalent runner conditions. The other decides which customers should receive a larger upload allowance. The first has an agreed comparison that can guide experiments. The second still needs a product decision; more generated candidates do not settle it.

This is why the AutoResearch experiment pattern and early human design review serve different needs. A measured result can guide the next candidate within a defined task. People still decide what should be measured, which consequences matter and whether the result is appropriate to release. A runtime improvement alone says nothing about an untested permission check.

Before removing a review step, try to construct a change that passes the checks but violates the goal. Skipping required tests makes a job faster without improving it. Use that counterexample to improve the checks or retain the human decision. This is a proposed evaluation method, not proof that any particular task is safe to automate.

Do not create more work than people can review#

Suppose, as an illustrative example, agents produce ten proposals in a day while the team can properly review two. Eight proposals are still waiting. Faster code generation has not yet increased the number of accepted changes.

The factory can pause new tasks when too many reviews are waiting. It can also avoid duplicate proposals and give reviewers clearer test results. These changes address work that people actually have to do. Starting more coding agents does not solve a shortage of review time.

This kind of limit is called backpressure: the next stage’s capacity affects how much work the previous stage starts.

The target is useful, maintainable changes with less avoidable human work, not the largest diff someone can just manage to approve. Count time spent clarifying the request and correcting mistakes as well as final review time. A shorter review that merely moves the same work into planning has not, by itself, saved effort.

Discuss important decisions before coding#

In the example, agree whether the upload limit is a shared rule before more clients copy it. Likewise, discuss changes to public interfaces, stored data and rollout requirements before the implementation makes those choices expensive to reverse.

Keep the discussion small enough to be useful. A plan should explain the decisions and their reasons, not duplicate the eventual code line by line. The planning guide shows how to keep that review focused. Reviewing an implementation twice under different names does not necessarily save effort.

An approved plan is still only a plan. Review the resulting code and test the requested behaviour. Decide what else needs inspection based on the possible consequences. A change that permanently deletes data needs more care than a reversible text correction.

Practise taking over a failed task#

Before allowing more unattended work, practise a failure in a non-production environment. Can the responder find the deployed code version and relevant logs? Can they stop further writes? Do the operating notes explain how to restore service without reconstructing a long agent conversation?

A Git revert restores code changes; it does not undo every consequence of running that code. A release may already have changed records or sent requests to another service. Recovery must account for those effects. Sometimes there is no safe automatic reversal.

Small, understandable changes and saved run records make a handover easier. They do not replace the need for a person who knows how to respond. Include the failure case when deciding whether more automation would help.

A trial with two related changes#

Try a follow-up requirement on top of the first accepted change. The sequence below is a proposed evaluation, not a reported benchmark.

Record review time, corrections and missed cases as well as model and environment costs. Include failed attempts. Keep the model, tool configuration and repository versions with the results so you know what you compared.

The measurement guide explains how to choose a baseline; cost per merged change explains which costs to count. Expand the kind of work that the trial supports. Do not give every task the permissions used for the easiest example.

Questions people also ask

3 QUESTIONS

▸ Can a maintenance task run without human review every time?

Sometimes. A team can approve that approach for a clearly defined kind of task after testing the checks and failure handling. That does not grant the same permission to other changes. A spelling correction and a change that deletes stored data need different treatment.

▸ Is the number of changed files a useful risk limit?

It can reveal an unexpectedly broad change, but it does not measure the consequences. A one-line permission change can matter more than a rename across many files. Inspect what the change does as well as how large it is.

▸ Can an AI reviewer replace all other checks?

No. A reviewer can find defects, but it can also share the coding agent's mistaken assumption. Tests, restricted permissions and a way to handle failures still have their own jobs. Measure what the reviewer catches and what a person still needs to check.