Series: Building the AI Foundation — Part 3a of 3a/3b. Part 1: Stop Picking AI Tools laid out the seven-layer architecture. Part 2: The Context Layer covered how AI reaches your systems. This piece covers layer six for developers specifically. Part 3b covers the same layer for business users. Part 4 will cover the control plane.
I started writing this as one article, covering code and business systems together under the heading “the system of record.” A few pages in, it was clearly fighting itself. Developers have twenty years of tooling behind this question. Everyone else has almost none. Mixing them made both halves weaker, so I split it. This piece is the developer half. Part 3b covers the harder, less comfortable half: CRM, contracts, HR policy, and the analytics tools that are quietly rewriting business records with no review at all.
Stop Picking AI Tools, Part 1 of this series, argued that AI works better as an architecture than as a purchase: seven layers, most of them meant to be swapped out as models and vendors change. The Context Layer Is Where Multi-System Enterprises Get Stuck, Part 2, went deep on layer five and covered how AI reaches ERP, CRM, custom apps, a data platform if you have one, and the sensitive systems that need a separate tier of their own.
This piece picks up layer six, the system of record, from the side where the discipline already exists.
One gate, whichever tool wrote the change
Here’s the part developers already know in their bones. An agent opens a pull request. It gets reviewed and tested. It merges. Whichever tool wrote the code, Copilot, Cursor, Codex, or an agent from Part 1’s delegated-development layer, the same gate applies. Nobody argues with that principle out loud. What’s worth digging into is what actually has to be true for it to hold up once the tools get good enough to tempt you into cutting corners.
What actually needs to be true
Branch protection comes first. Required reviews, with no bypass for “the AI already checked it.”
The tests don’t care who’s asking. CI and CD gates run the same suite no matter who or what opened the PR.
Security scanning stays uniform. Static analysis, secrets, and dependency checks apply without exception, regardless of how fast the change came in.
Review assignment doesn’t shift. CODEOWNERS or something like it routes review the same way whether a human or an agent authored the change.
The merge line holds. This is the rule from Part 1, and it’s worth repeating here specifically: an agent from the delegated-development layer opens a pull request. It never merges one.
That last one gets harder to enforce as agents get better, not easier. The better an agent’s track record, the more tempting it is to let it skip the queue “just this once.” Resist that. The gate isn’t there because you distrust the agent. It’s there because building a safe exception path is its own project, and most teams that try to shortcut it end up building exactly that project anyway, just after something’s already gone wrong.
Why this still depends on governed data
Every check in that gate assumes something underneath it. A test suite assumes the code it’s testing reflects reality. A security scan assumes its dependency database is current. None of that is really a code problem, and it’s worth saying plainly: a pull request can pass every check in this article and still be wrong, if the data or systems it touches were already unreliable before the AI got involved.
I’m not going to dig into this deeply here, because Part 3b does, and it’s the more important half of that conversation. But I don’t want developers reading this to think governed data is someone else’s problem. It isn’t. It’s just better handled, so far, on this side of the fence.
Traceability
This is the part developers already have mostly right, and it's worth seeing why, because Part 3b will show you what it looks like when this is missing entirely. Commit and PR metadata identify which tool or agent produced a change. Good practice links that change back to the task or spec behind it, often traced to a context-layer read from Part 2's registry. If something breaks in production six months from now, you can usually reconstruct what an agent was told to do, what it touched, and who approved it.
Review at scale
Part 1 flagged that AI-assisted pull request volume can outpace human review capacity, and that’s the real bottleneck here, not whether the gate exists. The gate is fine. The humans reading what comes through it are the constraint.
The fixes are becoming standard: AI-assisted first-pass review, and smaller pull requests as policy, especially for anything a delegated agent wrote. What changes is the reviewer’s actual job. It shifts from reading every line to judging whether the first pass caught what mattered. That’s a different skill, and I’d train for it directly rather than assume it develops on its own.
Failure patterns worth naming
A team fast-tracks AI pull requests because each one looks small, until a small change breaks something nobody reviewed closely.
A team blocks AI PRs from auto-merging but lets a human rubber-stamp them without real review, which defeats the purpose from the other direction.
Nobody owns updating branch protection as new agent tools arrive, so the gate loosens quietly over a year, and no one ever decided that on purpose.
What building this taught me
The developer side of this layer was the easy part to specify when I put together the IT org’s AI adoption plan. GitHub rulesets, required reviews, CODEOWNERS on critical paths, Copilot running first-pass review, agents that open PRs but never merge. All of it maps onto tooling that’s existed for years, and most of the work was configuration, not invention.
The harder conversation came later, once I started asking the same question about systems that aren’t code. That’s where Part 3b picks up, and it’s the half of this topic I think more people need to read.
Where this leaves you
Developers have this path built and mostly working, which makes it tempting to assume the system-of-record problem is solved across the company. It’s solved in one domain. I’d be curious whether your organization has even asked the question in the others yet, which is exactly what Part 3b is about.
Next: Part 3b covers the same layer from the business-user side, where the gate mostly doesn’t exist yet.