I approved 26,043 lines of code in two minutes

We build a product that answers one question for boards and auditors: who approved the AI-written code you shipped? So we run it on ourselves. Our own repositories — the internal tools, the prototypes, the rebuild of one of our products — are the first estate Provenance watches every morning.

Recently I opened the control that checks for human review on AI-authored changes, and clicked through to see which repositories were behind it. Near the bottom of the list was a line I didn’t expect to be reading about myself:

#210 — approved 2 minutes after opening, no inline comments on 26,043 changed lines.

The approver was me.

It wasn’t the only one. In the same repository:

• #210 — approved in 2 minutes · 26,043 lines changed · 0 comments

• #199 — 2 minutes · 10,173 lines · 0 comments

• #218 — 3 minutes · 453 lines · 0 comments

• #216 — 1 minute · 359 lines · 0 comments

• #215 — under a minute · 359 lines · 0 comments

Twenty AI-authored merges in that one repository carry an approval with no visible review behind it. Every one of them passed branch protection. Every one shows a green check. Anyone asking “was this reviewed?” would get the answer yes, by the CEO.

That answer is true, and it is meaningless.

How it happened

I’d like to say there was a good reason. There wasn’t one reason; there were several ordinary ones, and they’re the same ones every engineering team has right now.

The agent wrote the change. The tests passed. The pull request description was clear — agents write very good pull request descriptions. I knew roughly what the change was meant to do because I’d asked for it. And I had nine other things open. So I scrolled, I saw nothing alarming, and I clicked approve.

None of that is negligence in the way we usually picture it. It’s what happens when code arrives faster than any review culture was built for. A team that once merged a few dozen human-written pull requests a week can now merge several times that — most of them written by an agent, some of them enormous. The approval button didn’t change. What it means changed underneath it.

Why the green check isn’t enough

Branch protection asks a simple question: did someone with permission approve this? It does not ask whether they read it. It can’t.

For years that gap didn’t matter much, because approving a pull request you hadn’t read was socially expensive — you’d be caught out in the next stand-up. With agents writing the code, nobody is waiting to be caught out. The author isn’t a colleague who’ll notice you skimmed. The approval has quietly become a formality, and the formality is what ends up in the audit trail.

Now play it forward. Something goes wrong in production. The board, the auditor or the regulator asks the question every one of them will ask: who approved this change? You’ll be able to name a person. You won’t be able to say whether that person looked.

That is the difference between defensible and documented. A record that says “approved by Krishna” documents a click. A record that says “approved by Krishna, two minutes after opening, no comments on twenty-six thousand lines” tells you what the click was worth — and lets you do something about it while it’s still cheap.

What a review record should carry

I don’t think the answer is to make approvals harder. Gates that slow every merge get routed around within a week, and the governance layer shouldn’t be the thing standing between a developer and production. Your branch protection is your gate. What’s missing is an honest record of what happened at it.

For AI-authored changes, that record needs three things the green check doesn’t give you:

• Which changes were AI-authored — not as a guess, but from what the repository itself records.

• Whether the approval had a review behind it — an approval minutes after opening, with no comments on thousands of lines, is a fact worth recording, not a judgment about the person.

• The decision, on the record — when a team accepts a fast approval as fine (some will be), that acceptance is recorded with a name, a reason and a date, rather than assumed.

None of this grades developers. I’m the example here on purpose. The point isn’t who clicked; it’s whether the organisation can tell a review from a click — across every repository, not just the ones someone remembers to check.

Three questions to ask your team this week

1. Of the pull requests merged last month, how many were written mostly by an agent? How confident are you in that number?

2. For those, how many approvals came within a few minutes of opening, with no comments?

3. If your auditor asked tomorrow which of them were actually reviewed, how long would the answer take — and would you believe it?

If the honest answer to any of these is “we’d have to look,” that is the finding. It’s also the cheapest moment you’ll ever have to fix it: today it’s a settings change and a team conversation. After an incident, it’s a disclosure.

What changed for me

Nothing dramatic, which is the point. Provenance didn’t block anything — it’s a coach, not a gate. It put a fact in front of me that I couldn’t see from the pull request page, and it will keep putting it there, every morning, until the number goes down or someone records a reason it shouldn’t.

I’d rather find my own two-minute approvals on a Monday morning than have someone else find them for me.

Diwo Provenance is the governance layer for AI-written code and the agents that write it. It reads what already happened in your repositories — read-only, no plugins — and keeps the record your board and auditor will ask for. Evidence readiness, not a legal determination. See your own estate: diwo.ai/provenance