Guardrails that outlast the engineer

A team using coding agents produces far more code than it used to, and far more than anyone can review line by line. Most of it works. The problem is where it goes: a database call in a page, business logic in a component, a second piece of code writing to a table that should only have one owner. None of it breaks anything on the day. Six months later, the product is hard to change and nobody can say why.

On a reinsurance underwriting platform, OES turned the architecture into checks that fail the build when code lands in the wrong place. The client has since taken over the repository. The checks went with it, they still gate every production deploy, and the client’s team has extended them rather than switching them off.

Why a document isn’t enough

Most teams write their architecture down. An architecture document gets read once, by the people who were there when it was written. It doesn’t stop an agent putting a convenient shortcut in the wrong place, and it doesn’t stop a reviewer skimming a large generated change from missing it.

A check that fails the build keeps working whether or not anyone remembers the document.

What OES built

The rules of the architecture became part of the build:

• Boundaries between parts of the product. Pages can’t reach into the database. Business rules stay in the rules package. One application can’t import another.
• Ownership of data. Each protected table has a single declared writer.
• Exceptions as debt. Where a rule has to bend, the exception is written down and tracked, not silenced.
• Failures that explain themselves. When a check fails, it says which boundary was crossed and where the code belongs. An agent reading that message usually fixes its own change. A person does too.

How the checker works is written up separately. For a buyer, the point is simpler: the architecture is enforced by the build, not by one person’s memory.

What happened when other people took over

The real test of a guardrail is what happens when the person who built it isn’t there.

From late June a client team joined the project. Since then, the checks have stopped code that broke the rules from deploying, and each time the fix was to change the code, not switch the check off. Some of that code came from OES’s own agents, which is exactly what the checks are for.

At handover in September, the checks, lint rules and check scripts went into the client’s repository. Since then:

• The team has added rules of its own and tightened the existing ones.
• The list of exceptions keeps getting shorter.
• A major commercial change stayed in its lane. It landed in the rules, database and domain parts of the product, exactly where the checks say it belongs. More on that change.

The same checker now also runs on a second product, a sign-up platform for a telecoms reseller, where another developer put it on every pull request.

Is your architecture drifting?

Signs it already is:

• reviews of generated code are getting faster, and nobody is sure that’s a good thing
• the same fix comes up in review again and again: logic in a page, data fetched in the wrong place
• “where should this go?” gets a different answer depending on who you ask
• the architecture document hasn’t been opened since it was written

Questions to ask whoever builds your product:

1. Which architecture rules fail the build, rather than relying on review?
2. Where are the exceptions written down?
3. If you left tomorrow, what would stop the structure drifting?

What the client got

• Faster AI-assisted delivery, because agents are told no by a check instead of by a reviewer days later.
• A codebase that resists drift as the volume of generated code goes up.
• Standards that don’t depend on one person. If the only thing holding your architecture together is one engineer, it leaves when they do.

If you’re rolling out coding agents across a team and want the architecture to hold, let’s talk.