AI Agents in Your Repo: Gate, Log, Review
LET THE BOTS IN, SAFELY
Autonomy levels, bot-authored PRs, and guardrails: how to let AI coding agents work in your repo without losing review coverage or the audit trail.
TL;DR: Coding agents change the question from "how do developers use AI?" to "who is allowed to change the repo, how much at a time, and who checks it?" The stable answer is three verbs. Gate: agents get scoped permissions and autonomy matched to blast radius, decided per area rather than by default. Log: agents work under their own identities, so every change is attributable forever. Review: agent code merges through the same human gate as everyone else's, with explicit, boring exceptions. Teams that set this up early get tireless contributors; teams that don't get a fast stranger with push access.
What changes when the AI opens the PR
Assistants suggest; agents act. An agent takes a task, edits files across the repo, runs tests, opens a pull request - sometimes several a day, sometimes overnight. That shift breaks the quiet assumption underneath every engineering-process control you have: that a change is something a human did, understands, and answers for.
The volume side alone deserves respect. GitClear's 623-million-change dataset found heavy AI users out-producing non-users by 4-10x, with the honest asterisk GitClear attaches itself: most of that gap pre-dated AI, and against their own past selves those users gained about 25% velocity. Even the modest reading is more change per author, and that's assisted humans, not autonomous agents running while the team sleeps. Meanwhile DORA's 2024 report estimated that a 25% increase in AI adoption was associated with a 7.2% decrease in delivery stability even as individual productivity rose. More change, entering faster, through controls designed for human pace: that's the problem statement. Banning agents doesn't answer it, and neither does trusting them. The same three verbs that made human collaboration safe at scale do.
Gate: autonomy is a dial, not a default
Skip "should agents have access?" and ask "how much autonomy, where?" Think in levels:
- Suggest - the agent proposes diffs a human applies. Blast radius: zero. Fine everywhere.
- Branch and PR - the agent commits to its own branches and opens PRs. Blast radius: whatever review misses. Fine wherever review is genuinely healthy.
- Merge on green - the agent lands changes gated only by CI. Blast radius: whatever your tests don't cover. Defensible only in areas with strong tests, easy rollback, and low consequence: dependency bumps, docs, generated code.
- Deploy - the agent's work reaches production without a human in the loop. This is the level teams reach by accident, by stacking level 3 onto continuous deployment without ever deciding to.
The gate is a decision per area. The repo directory where three seniors review everything can host level 2 tomorrow; the payments module with thin tests and one maintainer should probably stay at level 1. If you've mapped where your review and test coverage is actually strong (the same map an AI readiness check produces), you already have the autonomy map. And enforce gates with scoped tokens, branch protection and CODEOWNERS rather than social convention. An agent doesn't feel awkward pushing to main; only permissions stop it.


Log: every agent under its own name
The cheapest rule in this article buys the most: agents never work under a human identity. A dedicated account per agent (or per agent-task class) buys you, permanently:
- Attribution. Agent commits count themselves - no detector guesses, no debates. This is the autonomous half of the measurement story in how much of our code is AI-written.
- Accountability that lands correctly. When an agent-authored change breaks production, the trail leads to the agent, its task, and the human who approved the PR, not to whoever's laptop it ran on.
- Analyzable behavior. Volume, churn, revert rate, and review outcomes of agent work become ordinary queries. If agent PRs churn at twice the rate of human PRs in some area, that's your signal to turn the autonomy dial back down, with evidence attached.
Log the task, too: the PR description should say which agent, what instruction, and what it was allowed to touch. Six months from now, "why does this code exist?" must have a better answer than a shrug. Unexplained code is a bus-factor problem regardless of who wrote it. The fully human version of that failure mode is vibe coding; agents industrialize it if you let them.
Review: the human gate holds, exceptions are explicit
At Google, essentially every change to the main codebase is reviewed before landing - a discipline maintained across ~9 million changes, with a median reviewer response under four hours and small changes seeing first feedback within an hour. That's the standard worth copying, and agents don't get an exemption from it. They're the reason it exists. Review is the last point where a human can acquire understanding of a change before the org depends on it.
Three agent-specific failure modes to design against:
- Volume drowns reviewers. A tireless author against tired reviewers is a losing matchup. Keep agent PRs small - the SmartBear/Cisco research found defect detection drops sharply past ~500 lines reviewed per hour, and agents will happily generate past any human's reading budget. Cap PR size in the agent's instructions, and watch reviewer load as agent volume grows.
- Rubber-stamping creeps in. The tenth green-CI agent PR of the week invites a reflex approval. Track review coverage on bot-authored PRs separately from human ones; it's the number that erodes first.
- Agents reviewing agents. AI review tools are useful assistants with known limits, but an agent PR approved only by another model means no human understands the change. For production code, at least one human approval, full stop.
Then make the exceptions boring and written down: lockfile updates, formatting, regenerated assets can merge on green at level 3. An exception list everyone can read is a policy; an exception habit nobody wrote down is erosion.


The door: adopt agents like you'd onboard a contractor
You already know how to integrate a fast, capable stranger: limited access on day one, own credentials, everything reviewed, trust expanded as the work proves out. Agents deserve exactly that onboarding, minus the coffee.
Start at level 1-2 in your healthiest areas, under named bot identities, with PR-size caps and separate coverage tracking. Expand autonomy where the agent's churn and revert numbers stay boring; contract it where they don't. In a quarter you'll have something rare in this hype cycle: an agent policy backed by your own repo's receipts, instead of a hope backed by a demo.
Frequently asked
Should AI agents commit under their own account or the developer's?
Their own, always. An agent committing under a human's name destroys the audit trail, makes attribution impossible, and quietly assigns accountability for unread code to someone who didn't write it. A dedicated bot identity costs minutes to set up and makes every later question (volume, churn, review coverage of agent work) a simple query.
Do agent-written PRs really need human review?
For anything that ships to production, yes. An agent PR merged on another agent's approval is code nobody understands entering your main branch with a green checkmark. Scoped exceptions (lockfile bumps, generated assets) are fine if they're explicit, listed, and boring. The rule isn't ceremony; it's that at least one human can explain the change.
How much autonomy should we give a coding agent?
Match autonomy to blast radius and reversibility. Suggestion-level autonomy is safe everywhere; branch-and-PR autonomy is safe wherever review is healthy; merge autonomy belongs only in areas with strong tests, easy rollback, and low blast radius, if anywhere. Expanding autonomy is fine; doing it by default, without deciding, is how repos rot.