The Governance Gap - by Alfino Hatta

SubscribeSign in

The Governance Gap<br>Why I Can’t Stop Thinking About One Number

Alfino Hatta<br>Jul 08, 2026

Share

I heard it almost by accident, tucked inside a vendor conference talk I was only half paying attention to. The speaker was building toward a pitch for multi-agent development tooling, and along the way he mentioned, almost as a throwaway line, that at some organizations roughly eighty percent of pull requests now get no human review at all.<br>He wrapped it in a joke I recognized immediately from my own experience. A tech lead wakes up with forty minutes before the workday starts. Five lines of code, and the reviewer leaves fifty comments. Fifty lines, and the reviewer leaves five. Five hundred lines, and the reviewer writes “looks good to me” without really reading it. The room laughed. I laughed. Then the talk moved on to the sales pitch, and I found I couldn’t move on with it.<br>I think that transition is the whole story. A number with real implications for governance, audit readiness, insurance, and legal liability got used as a punchline and a hook, not as a finding that deserved to stand on its own. So I went back. I found the full transcript, not just a summary, and I sat with it for a long time. I read it once quickly, then again slowly with a notepad, then a third time looking specifically for the places where the speaker hedged his own claims. What follows is everything I took from that process, and where I have landed after living with this number for a while.<br>I want to say upfront that I do not think this piece resolves the question. I think it mostly clarifies what the question actually is, which turns out to be harder and more interesting than the headline number suggests.<br>How I Read the Room Before the Numbers Arrived

The talk opened with a show of hands, not data. Who uses one AI development tool. Two. Three. Four. Widening the definition each time until nearly everyone’s hand stayed up. A design tool that generates code counted. A planning tool that assists with tickets counted. An operations agent that helps triage incidents counted. Then a forward looking version of the same question, whether people expected to be using more than three code generating tools within six months to a year.<br>In my experience, that is a familiar rhetorical move, and I do not say that cynically. It worked on me too. By the time the real numbers showed up, I was already primed to believe them, because the room had just spent five minutes agreeing that this was already the water we were all swimming in.<br>The speaker then set several recent high profile cloud outages next to a separate fact, that some of the companies involved had publicly said a meaningful share of their code, in some cases reportedly as much as half, is now AI generated. He was careful not to claim causation. He just let the two facts sit next to each other and let the room do the connecting. I noticed myself doing exactly that connecting in real time, and I think it is worth naming, because it is a persuasion technique as much as it is evidence. A speaker does not need to say two things caused each other if he can simply place them next to each other and wait.<br>One anecdote stuck with me more than the rest. A well known AI lab had published the system prompt behind one of its automated security reviewers, and buried inside it was an exclusion list, categories of issues the reviewer was told not to flag. Denial of service concerns were on that list. The speaker floated, carefully, that this might connect to the outages he had just mentioned. He said explicitly it was speculation, not a claim of causation. But I think the anecdote did real work regardless, because it planted something that stayed with me long after the talk ended, the idea that even the review layer meant to catch problems is itself being shaped by decisions nobody scrutinizes the way they would scrutinize a human reviewer’s judgment. A person writing a code review checklist gets asked why certain items are on it. A system prompt written by an engineer under deadline pressure often does not.<br>The last piece of scene setting concerned instruction following, and it is the one that hit closest to home for me personally. The speaker described a survey in which teams were asked whether coding tools reliably follow written rules and standards documents. The answers clustered heavily around the middle of the scale, somewhere between sometimes and inconsistently, rather than at either extreme. He offered a scenario I recognized instantly, the experience of running the same detailed prompt seven times and getting seven different implementations back, despite the rules being identical each time. I have lived that exact frustration, and hearing it named out loud in a room full of strangers made the rest of the talk land differently for me. It stopped feeling like a sales pitch about a hypothetical problem and started feeling like a description of...