Guardrails that outlast the engineer
After handover, the architecture checks I built still gate a client’s production deploys. They have blocked 8 bad deploys, and the team extended them instead of switching them off. Here is what that takes.
, filed under ai, architecture, guardrails, sveltekit, coding-agents
The client has taken over the repository for a reinsurance underwriting platform I built. The architecture checks went with it, and they still gate every production deploy.
Since the team joined, those checks have blocked 8 deploys that broke the rules. Each time, the fix was to change the code, not switch the check off. Some of those were my own agent’s code, to be fair.
The team has added rules of their own and kept paying down the list of exceptions I left behind. Then they made a major capacity change, and it landed entirely inside the rules, database and domain packages. Nothing was rebuilt.
That’s the outcome I care about. Not that the checks exist, but that they’re still being right after I stopped paying attention.
Why the checks exist
Coding agents write plausible code in the wrong place. A database call in a route. Domain logic in a component. A second writer for a table that should only have one. None of it is invalid, it compiles, and a reviewer skimming a large generated diff will miss some of it.
I built these guardrails to stop coding agents writing bad code. An architecture document gets read once. A check that fails the build keeps working.
What was built
On the underwriting platform I made the architecture executable:
- a boundary checker that parses the code rather than grepping it, and enforces 36 blocking rules
- data-ownership checks, so protected tables have a single declared writer
- route-data checks and custom lint rules
- exceptions tracked as debt, each one written down, rather than silenced
The checks gate deploys, and the error messages say which boundary was crossed and where that code belongs. I’ve written up how the checker works separately.
What happened after handover
The checks, lint rules and check scripts were carried into the client’s repository at handover, and the client’s own team now runs them.
- 8 deploys blocked that broke the rules. The team fixed the code each time, following the error message.
- Rules extended, not disabled. The team registered new protected operations and tightened the checks.
- Exceptions paid down. The list of known exceptions keeps getting shorter.
- A major capacity change stayed in its lane. It landed entirely in the rules, database and domain packages, with the web app only displaying the result.
It travelled
I ported the same checker to a second product, a sign-up platform for a telecoms reseller, with 16 hard rules suited to that codebase. Another developer on the team then added it to CI, where it runs on every pull request and gates production deploys. About sixteen weeks later it still passes, and the new modules written since follow the rules.
What a team gets from this
- Faster AI-assisted delivery, because agents get told no by a check instead of by a reviewer three days later.
- A codebase that resists drift, even 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 you, it leaves when you do.
If you’re rolling out coding agents across a team and want guardrails that stick, get in touch.