Governance moved inside the build.Copy link

Security leaders and private equity operating partners rarely seem to read each other's posts. Lately, they're making the same argument in my feed. Private equity (PE) firms buy companies, improve them and sell them on. The operating partner is sent into a company they own to do the improving. Security leaders worry about reporting breaches. Operating partners worry about the price a company will fetch relative to its earnings when sold. Their language rarely overlaps. On software built with AI, though, they're agreeing that governance has to live inside the build. The rules and evidence need to be in files that machines check on every change. I don't see how an office overseeing the work from outside can keep up.

I build software with AI coding agents full time and ship it into production. For the last year, I've dealt with the problem both groups describe. When agents write most of the code, the volume grows faster than people can oversee it. That's why I agree with them. I've had to build the checks into the work.

Security made this move firstCopy link

Endpoint security set the precedent. Security faced the same pressure governance faces now. The old model put controls around the boundary of the company's systems. It assumed the work stayed inside that boundary, where those controls could see it.

Then laptops went home and workloads moved to the cloud. The boundary no longer covered where the work happened. A taller wall or a bigger security office would not solve that. Controls moved onto the endpoint, the machine doing the work. They checked policy and collected evidence there. Endpoint security became a standard part of how machines were set up. It recorded what happened without relying on an oversight team's opinion.

Software delivery is at a similar point. Coding agents write code faster than people outside the build can review it. The security leaders in my feed argue that controls need to follow the work, just as they followed the laptops out of the building.

The office reads slower than the build writesCopy link

I don't think the office model can handle the volume. I wrote last Monday about a promise I keep seeing in enterprise AI governance write-ups. A senior engineer reviews all AI-generated code before it is merged into the shared codebase. I made myself do that review on my own code, which had passed its tests. Twelve real defects in four small files, half of them introduced by the fixes for the other half. From what I see, the promised review is already falling short, and volumes keep rising.

The capacity gap predates coding agents. A YouGov survey of around 500 UK IT leaders, commissioned by Transparity and published in April 2026, found 76% of organisations still relying heavily on manual testing. Asked about defects slipping through, 46% worried about reputational damage and 44% feared increased security risks from uncaught bugs. The research shows an industry-wide shortage of testing capacity putting reputation and security at risk, the things governance is meant to protect. Adding code at agent speed gives the same people more to check.

Governance as an artefact a machine can checkCopy link

A governing artefact is a written record of what the software should do, in a form a machine can check. Requirements become user stories, descriptions of what someone needs the software to do. Each story has acceptance criteria, one-line statements of what done means. They must be precise enough for a test to pass or fail against them. Tests come from those criteria, rather than from the code, so the agent writing the code does not decide what counts as correct. Each part has an identifier and explicit links to the others. Tools can follow a business requirement down to the evidence that it is met, or a failing test back to the requirement it failed. A criterion without a test is reported as a failure, just like a broken build.

I use the RCF methodology, the Requirements Confidence Framework, to do this. It has let me put high-stakes, auditable software into production with agents doing the building. The particular framework matters less than how it works. A policy binder describes what should happen and relies on people to enforce it. These files and checks block a merge when the requirements are not met. That makes governance operate as part of the build. It can keep pace with agents because it uses the same files, checks and evidence they work with.

What a diligence team can inspectCopy link

The private equity interest comes down to one distinction. You can interview an office. You can only inspect an artefact. When a PE firm buys or sells a software company, the diligence team checking the business needs to know whether the software does what the company claims, and how to verify that. The office answers with a policy document, an org chart and a round of interviews, all of which describe the controls. A governing artefact lets the team watch those controls run. The linked requirement, criterion and evidence let you walk the chain yourself. I know which evidence I'd rather have when buying or selling. The operating partners writing in my feed about AI adoption across the companies they own seem to agree.

My advice to the chief technology officer (CTO) and the operating partner is the same. Put the money into governance where the code is, with a written record connected to the work. I don't think funding an office to watch a build it cannot see will keep up. Security moved its controls when work left the perimeter. Years later, I see no appetite to go back.