Rules that hold themselves

Most engineering teams keep a document of lessons. Each line is there because something went wrong once: a bad release, a lost weekend, an unhappy customer. The document grows faster than anyone can follow it.

For years, review covered that gap. A senior engineer would read a change, remember the incident, and say "we don't do that here." It worked because code arrived at the speed people could read it.

AI agents, the tools that write code on their own from a written request, now produce a large share of the changes, and they arrive faster than any reviewer can read them. That matters beyond catching typos. A convention only counts as a standard when every team and every agent follows it on every project. Anything less, and each skipped rule is a place where a defect can get in.

Written rules get skipped quietly

Here's a small story from a codebase I know well. One rule said: never type out a list by hand when the system can produce it, because the copy goes stale the first time the real list changes. Simple rule, good reason, written in the guide everyone was supposed to have read.

A sweep found five places carrying a hand-typed copy of that list. All five had drifted.

Nobody disagreed with the rule. Nobody was cutting corners. The rule was one line among a thousand, and it lost at the moment someone needed a list and had one in front of them. It lost quietly, too. Nothing anywhere recorded that it had been skipped.

What fixed it was a check: about twenty lines of code that look at every proposed change and block it whenever a hand-typed copy shows up. The rule stopped depending on anyone remembering it.

An agent cannot merge past a failing check

An AI agent reads your guidance the way a busy person does: most of it, most of the time, and not always the part you needed today. Give it two hundred rules and it will follow most of them, and you won't know which ones it skipped.

Agents also have a problem people don't. Each session, meaning one run of an agent on one task, starts with no memory of the last one, reads the guidance fresh, and interprets it a little differently. Across hundreds of sessions on several projects, those small differences add up, and the codebase drifts away from the standard you wrote down, one reasonable-looking change at a time.

A failing check closes both gaps. To merge, the step where a change is accepted into the shared code, the check has to pass. The agent cannot merge past it. Whether it read the rule, remembered it, or agreed with it makes no difference. Of all the ways you can tell an agent what you want, this is the one that reaches every session, on every project, the same way.

Three habits turn checks into a ratchet

Most teams already run some automatic checks, and many have learned to ignore them. A pile of warnings nobody reads teaches everyone that red means nothing. Three habits separate a pile from a ratchet, the tool that only turns one way, so progress doesn't slip back.

Turn each lesson into one check. One small, fast test that fails when the exact mistake reappears, added the week the lesson is learned. All of them together should run in seconds, or people will stop running them.

Watch it fail once. Before you trust a new check, show it the mistake it exists to catch and confirm it goes red. A check that has only ever passed proves nothing. It may be blind, and you would have no way to tell.

Give every exception an expiry. Real code needs exceptions. The trap is an exception with a reason nobody rereads. Write the reason as something the machine can verify, such as "this exception ends when that old component is deleted," and let the check fail the day it comes true. On one codebase, rewriting fifteen exception reasons this way found three that were already false.

None of this is new. Careful teams have known for decades that a rule enforced by a program holds better than a rule in a document. Few did it for every lesson, because writing each check was tedious work that never reached the top of the list under a delivery deadline. That cost has dropped. An agent will write the check, prove it goes red, and wire in the exception rule in one sitting, then do the same for the next lesson without losing patience. The rigor was always available, and now it is cheap enough to apply to everything.

That is also what decides how much room you can give the agents. The work you can hand to an AI worker without watching each change is set by how much of the result the machine can verify on its own. Every check you add moves that line. Your reviewers keep the questions a check can't answer, whether the design is right and whether the change is worth making at all, and the agents can safely take on more of the rest. This is your architecture as an AI-ready asset in daily practice.

Where this goes next

Checks answer one narrow question: can this change go in? The harder questions come once agents have enough room to work in the same codebase at the same time and need a way to tell each other what they're doing. On one fleet, two agents that had quietly overwritten each other's work noticed, talked it through between themselves, and repaired it while the person in charge sent three short messages. That story, and the security hole the same channel turned out to have, are the next two posts in this series.

For now, the test is short. Pick the last lesson your team paid for and ask whether a check holds it today. If not, what would it take to add one this week? And of the checks you already have, which have you ever seen fail?