Answer
How do you make an AI coding agent work safely in a large repository?
Narrow what it can reach, work on a branch, and review the diff rather than the description of it.
Narrow the scope to the area the task belongs in, work on a branch that can be discarded, and review the diff rather than the summary. Size raises the cost of an unnoticed change, not the odds of one.
Scale changes the consequences rather than the behaviour. An agent is no more likely to touch something it should not in a large repository, but the change is far less likely to be noticed, because no one person reviews everything and the affected area may belong to a team that was not involved. The controls that matter are therefore about containment and visibility rather than about caution.
The first is scope. Point the agent at the area the task belongs to and say so explicitly, rather than at the repository root with a goal. This improves the work as well as containing it: search is more effective in a narrower tree, and the resulting diff is reviewable by the person who owns that area. Where the change genuinely spans areas, that is worth knowing at the start rather than discovering in the diff.
The second is the branch, which is the cheapest strong control available. Work that happens on a discardable branch cannot damage anything, can be abandoned without negotiation, and produces a diff as its natural output. Any repository already has this; the discipline is only to insist on it, including for changes that seem too small to bother with. Small changes are where this gets skipped and where the surprises live.
The third is reviewing the actual diff rather than the account of it. An agent's summary of what it changed is written to be convincing and is frequently incomplete in one specific way: incidental changes — a reformatted file, an import reordered, a generated artefact updated — are not mentioned because they were not the point. Those are exactly what causes trouble later in a large repository, and they are visible in the diff and nowhere else.
The fourth is the pre-existing enforcement layer: owner rules, protected paths, required reviewers, checks that must pass. These exist in most large repositories for the same reason and apply here without modification. The useful realisation is that an agent should be subject to them rather than around them, which means giving it the same route a person takes — a branch and a request — rather than direct access.
Finally, watch the size of the change. A diff that is much larger than the task warranted is the most reliable signal that something else happened, and it is available before any reading. A change of eleven files for a task that should have touched two is worth investigating even if every file looks reasonable, because the reason for the extra nine is the thing you want to know.
In a small repository a stray change is found in a week; in a large one it is found by whoever inherits it.
Siddharth Sharma, Context Theory
Related questions
Should an agent have write access to the main branch?
No, for the same reason a person should not. The value of the branch-and-request route is not distrust; it is that it produces an artefact, a point of review and a rollback path, all of which matter more as the repository grows. Direct access removes all three in exchange for saving a step.
How do you handle a change that legitimately spans many areas?
Split it, and use the fact that it spans areas as information. A change touching several owners is a change several people need to see, which is a coordination problem rather than a tooling one. An agent can prepare the pieces separately, which makes each reviewable by the right person instead of producing one diff nobody is qualified to approve.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Software | Repository scale increases the cost of an unnoticed change rather than its likelihood, because no single reviewer sees everything and an affected area may belong to a team not involved in the work. | Checking whether the review process for a change guarantees that an owner of every touched area sees it. |
| Workflow | An agent's change summary omits incidental modifications such as reformatting, reordered imports and regenerated artefacts because they were not the point of the task, and those are visible only in the diff. | Comparing an agent's summary of its change against the file list in the resulting diff. |
| Constraint | Subjecting an agent to the repository's existing owner rules, protected paths and required checks by routing it through a branch and a request applies controls that already exist, whereas direct access bypasses all of them. | Checking whether the agent's write path triggers the same required reviews as a human contribution. |
| Response | Diff size relative to task scope is a pre-reading signal of unintended work, so a change touching substantially more files than the task warranted merits investigation regardless of whether each file looks reasonable individually. | Comparing the file count of a change against the number the task should have required. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one