TL;DR: Architecture governance breaks down the moment a diagram stops matching the system running in production. Engineering leaders can review every pull request and still miss layer violations, broken boundaries, and drifting API contracts, especially as AI-generated code adds volume faster than any review process can absorb. Pandorian enforces both structural and behavioral architecture standards automatically, on every pull request and across every repository.

What’s in this post

• The Diagram in Confluence Isn’t the System in Production
• Structure Is Only Half the Standard
• Review Boards Catch Drift. They Don’t Stop It.
• AI Is Writing Architecture Faster Than Anyone Can Check It
• From Markdown to Merge-Blocking Guardrail
• One Place to Define, Enforce, and Govern Architecture
• Common Questions

An architecture review board approved the service boundaries eighteen months ago. Nobody rejected the diagram. Nobody objected to the layering, the approved frameworks, or the rule that says the payments service never talks to the reporting database directly.

None of that stopped a developer, under deadline pressure last sprint, from adding exactly that call. The pull request looked clean. Two reviewers approved it. The rule that governs how systems are structured existed only on a wiki page nobody had opened in months.

This isn’t a story about one bad pull request. It’s the default outcome of how most engineering organizations handle architecture governance: write the standard down, review some code against it by hand, and hope the two stay in sync as the team, the codebase, and now the AI writing a growing share of the code, keep moving faster than anyone can check.

They don’t stay in sync. They can’t. The question was never whether the standard exists. It’s whether the codebase enforces it the moment someone tries to break it.

The Diagram in Confluence Isn’t the System in Production

Architecture governance starts to fail the moment the diagram and the deployed system stop describing the same thing.

Every architecture decision starts well documented. An ADR captures the reasoning for choosing an event queue over a direct call. A diagram shows which service owns which data. A wiki page lists the frameworks new services are supposed to use.

Then time passes. New engineers join who never read the ADR. A deadline forces a shortcut that gets labeled temporary and never revisited. A service that was supposed to own its data starts reading a neighbor’s table directly, because that was faster than requesting an API.

None of this looks like a single dramatic failure. It looks like a slow accumulation of small, individually reasonable deviations, until the system running in production bears only a loose resemblance to the one that was approved.

Structure Is Only Half the Standard

Architecture governance covers two distinct problems: how a system is structured, and how it behaves once it’s under real load.

Structure is the part most teams document first: approved frameworks, shared libraries, service dependencies, and the module or domain boundaries that keep one team’s code from quietly depending on another’s internals. These are the rules that keep a system from turning into a tangle where everything depends on everything.

Behavior is the part that gets skipped just as often, and matters just as much: API contracts and versioning, who owns which data and how it’s read and written, and resilience patterns like retries, timeouts, and circuit breakers that decide what happens when a downstream service has a bad day.

A governance approach that only covers one of these leaves the other to chance. Clean boundaries don’t help if every service handles errors differently. Consistent error handling doesn’t help if a checkout service can freely start calling into inventory’s internal tables.

Review Boards Catch Drift. They Don’t Stop It.

Architecture governance has traditionally relied on architecture review boards and periodic audits, which by design happen after the code has already been written.

A review board is a useful forum for debating a genuinely hard tradeoff. It is a poor mechanism for catching the hundredth small violation of a decision that was already made. By the time a quarterly audit surfaces that a boundary has been crossed, three other services may already depend on the workaround, and unwinding it costs far more than preventing it would have.

Research on architectural drift describes this as a well-documented pattern: the intended architecture and the implemented one diverge gradually, and each individual deviation looks small enough to ignore in the moment it happens. InfoQ’s analysis of architectural governance in the AI era reaches the same conclusion: keeping a system architecturally coherent, once anyone, including an AI agent, can ship code, requires pairing centralized decisions with enforcement that runs automatically on every change rather than through a standing committee. Review boards set the decision. They were never built to enforce it on every change.

AI Is Writing Architecture Faster Than Anyone Can Check It

Architecture governance gets harder every time AI-generated code adds volume without adding architectural judgment.

Gartner projects that 75% of enterprise software engineers will use AI code assistants by 2028, and that volume doesn’t come with an instinct for which boundary is load-bearing and which is incidental. An AI coding tool is excellent at matching the pattern of the file it’s looking at. It has no way of knowing that the pattern it just copied was the one exception the team agreed to tolerate, not the standard to replicate.

Platform teams have been answering a version of this problem for years through golden paths: opinionated, self-service templates that encode the right defaults so developers don’t have to remember them. DORA’s research on platform engineering frames these paths as what lets teams ship securely and reliably without reinventing the defaults on every service, and they work well for the decisions a template can bake in ahead of time. Architecture governance needs the same instinct applied continuously, catching the boundary violations and contract breaks that a starter template can’t anticipate, on every change, regardless of whether a human or an agent wrote it.

From Markdown to Merge-Blocking Guardrail

Architecture governance becomes real the moment an existing standard moves from a document into an enforced check.

Most engineering organizations already have the raw material. ADRs, Confluence pages, and Markdown docs describe layer boundaries, approved frameworks, API conventions, and resilience requirements in enough detail to act on. The gap has never been a lack of documentation. It’s been the absence of a mechanism connecting that documentation to the pull requests being merged every day.

Pandorian closes that gap directly. Pandorian extracts the source material, compiles it into enforceable guidelines, scores each guideline for focus, clarity, and enforceability, and then makes it ready to enforce across the codebase. A standard that used to live in a wiki page becomes a check that runs the next time someone opens a pull request against it.

One Place to Define, Enforce, and Govern Architecture

Every failure mode above, drifting diagrams, review boards that arrive too late, AI code that copies whatever pattern is nearby, is a symptom of the same root cause: architecture standards that exist as text instead of as enforced logic.

• Single source of truth: Import architectural standards from existing docs or write them in plain language, once, into one governed catalog.
• Context-aware enforcement: Run checks against every pull request and scan entire repositories to surface drift that’s already in the codebase.
• Scoped by system: Apply different standards by repository, service, directory, language, team, or tag, so a payments service and an internal tooling repo don’t have to share one generic rule set.
• Ownership and versioning: Every guideline has an owner and a change history, so architectural decisions stay traceable as they evolve.
• Leadership visibility: See compliance posture across every repository and team, not just the ones a review board happened to look at this quarter.

Structure Without Enforcement Is Just a Diagram

The service boundaries were approved eighteen months ago. So was the framework, the layering, and the rule about which services can talk to which databases. None of that was the problem.

The problem was that approval and enforcement were treated as the same event, when they’ve never been the same thing. A diagram describes an intention. A pull request either honors it or it doesn’t, and nothing about a wiki page decides which.

Architecture governance stops being a quarterly audit and starts being a property of the codebase itself once every standard, structural and behavioral, is checked on every change. The diagram stays accurate because the code is no longer free to disagree with it.

Common Questions

Written by Daniel Amsellem, CTO at Pandorian

Related Reading

• Pandorian for Architecture Leaders
• What Are Engineering Standards and How to Enforce Them
• How to Enforce Your Engineering Standards Across Your Codebase
• Four Proven Reasons Your Engineering Standards Never Stick
• Explore the Pandorian Platform