A lean reference architecture for AI-assisted delivery teams

This is the real architecture pattern behind how EBM's own delivery teams work — not a theoretical enterprise diagram, a description of what a lean team actually needs when AI is writing a meaningful share of the code.

The five guardrails

Version control with mandatory review gates. AI-assisted code still goes through the same pull-request review as anything else. No exceptions, no "the AI already checked it." A model can be extremely good at writing plausible-looking code and still be wrong about the one thing that matters in your specific system — the review gate is what catches that, and it has to apply uniformly or it doesn't apply at all.

A staging environment that mirrors production closely enough to trust. AI-generated changes get tested somewhere real before they touch customers — the gap between staging and prod is where AI-assisted mistakes actually cause damage. A staging setup that diverges meaningfully from production (different data volume, different config, a service mocked out that's real in prod) gives you false confidence, which is worse than no staging at all, because it tells you a change is safe right before it isn't.

Task-scoped AI access, not project-wide access. An assistant working on a billing fix shouldn't have standing access to the auth system. Scope access to the task, not the whole codebase, by default. This isn't about distrust of the tool specifically — it's the same least-privilege principle you'd apply to a new contractor, applied consistently to an assistant that can move just as fast and doesn't ask before it acts.

A rollback path that doesn't depend on remembering what changed. Feature flags or clean revert points, so an AI-assisted change that turns out wrong can be undone in minutes, not hours. The failure mode this guards against isn't the AI making a mistake — mistakes happen regardless of who or what wrote the code. It's discovering the mistake at 6 p.m. and not having a fast, mechanical way to undo it that doesn't depend on someone's memory of what else changed in the meantime.

One human owner per change, always. Every AI-assisted change has a named person accountable for it shipping — the assistant helps, it doesn't own the outcome. This is the guardrail that's easiest to erode quietly, because "the AI wrote it" starts to feel like an answer to "who's responsible for this." It isn't, and treating it as one is how accountability disappears from a team without anyone deciding that should happen.

Why this is the whole architecture, not a starting point

None of this requires enterprise tooling budgets. It requires discipline about the five guardrails above, applied consistently, not occasionally when someone remembers. A team that follows all five with a plain GitHub repo and a basic staging server is better protected than a team with an elaborate CI/CD platform that skips code review "just this once" for AI-generated changes.

That's the same architecture we bring to IT Services engagements — not a bigger toolchain, the same five rules, applied without exception.