Your Main Branch Has Code Nobody Read. Whose Name Is On It?

Who is accountable for AI-generated code? The engineer who merges it. That answer hasn't changed since 2023. What changed is the volume behind it.

Google's own number: just over a quarter of new code AI-generated in October 2024, roughly half by late 2025, 75% by April 2026 per Sundar Pichai. Almost nobody's review gates, provenance records, or audit evidence moved in that same window. So the accountability gap is the distance between how much of your codebase a model wrote and how much your governance assumes a human wrote.

It stays invisible until the worst possible moment — an incident postmortem, a security review, a customer questionnaire, an examiner asking about your SDLC.

Three failure modes

• The review bottleneck. Agents produce diffs faster than humans read them. Review becomes either the constraint on delivery or a rubber stamp. Watch for the tell: approval latency stays flat while actual scrutiny drops.
• Provenance blindness. Someone asks "was this AI-generated, and what checked it?" and nothing in the commit history can answer. This is cheap to record now and impossible to reconstruct later.
• Shadow tooling. Policy says no, engineers use personal accounts and local models anyway. The company keeps the risk and loses the visibility. We ran this exact movie with unsanctioned SaaS a decade ago.

On the review bottleneck, there's a recurring r/ExperiencedDevs thread shape worth reading: a senior engineer describes review queues doubling after agent adoption, and the replies split between "review harder" and "trust the tests." Both miss the same move. The review standard has to change shape, not intensity. A heroic reviewer and a green CI run are equally poor substitutes for deciding which changes deserve which gate.

Why banning makes it worse

Three postures, and only one of them produces a defensible answer to "who signs this?"

• Ban — you get a clean-sounding policy. You pay in shadow usage with zero visibility, a senior hiring penalty, and the loss of the audit trail you were trying to protect.
• Laissez-faire — you get speed and goodwill. You pay in no provenance, rubber-stamped review, and unanswerable audit questions.
• Governed adoption — you get speed plus evidence that survives an audit. You pay in real setup work, roughly four to eight weeks of process and tooling change.

The ban threads on r/cscareerquestions read identically every time: the policy says no, the replies describe exactly how people route around it, and nobody believes the codebase is cleaner for it. When your engineers can narrate the workaround in public, the ban isn't a control. It's a blindfold.

The five moves

1. Name the owner, per merge. One sentence of policy: the engineer who merges a change owns it, regardless of what produced the draft. The model proposes, the engineer signs. No autonomous merges.
2. Tag provenance at commit time. Commit trailers, PR labels, or tool-native attribution. Record which changes are substantially AI-generated and by which tool.
3. Harden the gate where it counts. Risk-tier your repos. AI-drafted changes to payment logic, authz, and data migrations get a second reviewer and a required test diff. AI-drafted changes to internal tooling get the standard gate. Uniform strictness is how review becomes theater.
4. Give non-deterministic code a CI gate. An eval harness is a CI suite for code whose output isn't reproducible. If your agents write code that calls models, evals gate the merge the way unit tests gate deterministic changes.
5. Write the evidence file as you go. Tool inventory, policy, provenance stats, gate configs, exception log — one folder. When the auditor asks, you hand over a folder instead of a promise.

The objection we hear on move 2: provenance tagging slows engineers down and they'll skip it. In practice the tag is a commit trailer the tooling adds, not a form someone fills in. That objection describes the policy-PDF version of governance, not the tooling version.

What it looks like six weeks in

Composite from rollouts inside client deliveries — fintech scaleup, 30 to 80 engineers, high agent adoption, no provenance, a customer security questionnaire sitting unanswered because nobody could describe the AI share of the SDLC.

Six weeks later: a bot tags model-drafted changes at commit time, so the AI-drafted share of merges is a dashboard number instead of a guess. Repos are risk-tiered. Anything calling a model at runtime runs an eval job in CI. The evidence file exists.

The outcome worth copying is counterintuitive. Review time per diff spikes in week one, then settles at or below baseline — because reviewers stop treating every change as equally suspect. The stalled security questionnaire gets answered from the evidence file in a day. And the tooling debate changes tone, because arguments about impressions become arguments about a dashboard.

None of it required slowing the agents down.

What this is not

It is not a case for treating model-drafted code as suspect by default. Model-drafted code that passed a real review and a real test suite is production code. The vibe-coding failure mode — shipping unread model output — is a review failure, not a tooling failure.

The tools are already in your building and the volume is already in your main branch. The only open question is whether the signature on the merge still means anything. Governance that lives in a document drifts. Governance that lives in the pipeline holds.

Full breakdown — the three postures compared, the rollout timeline, and the legal accountability question: teamvoy.com/blog/ai-generated-code-accountability-2026

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at teamvoy.com/blog.