Guardrails for AI coding agents that the build enforces

Guardrails for AI coding agents hold when the build enforces them. Turn a repeated review comment into a type, a lint rule or a check the agent cannot skip.

Expedition Labsupdated 4 min read

Guardrails for AI coding agents are rules the build enforces, so the agent cannot land code that breaks them. A sentence in a prompt or an agent guide is a suggestion. A failing build is not. If you want a rule the agent cannot ignore, move it out of the prose and into a type, a lint rule or a check in the gate.

The working rule is short. If you leave the same review comment twice, turn it into a check. The agent no longer has to remember the rule, because the rule will not let the change through.

Why written rules do not hold

A rule that lives only in a guide is enforced by memory and attention, and both degrade under deadline. An agent treats its instruction file the same way. The instructions are suggestions, and nothing objects when one is skipped.

There is a second problem. Agents copy what the surrounding code already does. One unguarded pattern that gets through becomes the template for the next change, and a weak guard spreads the same way.

Pick the strongest mechanism the rule allows

Mechanisms are not equal. Work down this table and stop at the first row that can express your rule.

The rule you keep repeatingMechanism, strongest firstWhat you would find in the repository
Client code must never import a module that reads a credential.A state that cannot compileA server-only marker as the first line of the module. A client import fails the build.
Do not import across layers. Do not call that risky API.A lint rule or banned API that fails the gateImport-restriction rules and a banned-API rule, run in check mode by the gate.
Do this the same way everywhere.A canonical helperOne helper that does it correctly, so the code an agent copies is already right.
Make sure the required configuration is present.A runtime checkOne assertion at startup that exits and names what is missing.

The top row often pays back more than any other single change in a codebase. It takes a rule upheld by discipline across hundreds of files and hands it to a tool that never gets tired.

A check only counts if the agent cannot skip it

A guardrail is real only if it runs in check mode, in a place the agent cannot skip. For an agent that commits from your machine, that place is the git hooks, with the bypass flag denied to the agent. For an agent that opens pull requests from the cloud, it is the required status checks on a hosted runner. A check that nothing enforces only annotates the change. Pre-commit hooks vs CI covers which gate fits and how to set it up.

Turn a repeated review comment into a check

Use this procedure the second time you write the same comment on an agent's work.

  1. Write the comment as one rule that can pass or fail. "Feature code must not import the database layer directly" works. "Keep the layers clean" does not.
  2. Pick the strongest mechanism from the table that can express the rule.
  3. Add the check to the one command that the hooks and any hosted run call, so the agent hits it before it commits.
  4. Break the rule on purpose and watch the check fail. A check you have never seen fail may be inspecting nothing.
  5. Confirm the gate runs it. That is the pre-commit hook if you work alone, and a required status check on the default branch if anyone else can push.
  6. Delete the sentence from the agent guide. Add a row to a table that maps each rule to what enforces it, so a rule with no enforcer is visible.

Keep the agent guide honest

Once a structural fix exists, use only the structural fix and delete the instruction. What stays in the guide should describe the code that exists. A guide that mandates a library the project never adopted does not read as out of date. It reads as a target, and an agent that treats the file as authoritative will build toward it.

Change agent instructions in a commit of their own, never in the middle of a task. An instruction edit tangled into feature work is invisible to review.

Guardrails decide how much the agent may do

Autonomy is unlocked by what the repository can check, not by confidence. On the trust ladder we use, an agent opens one pull request per issue only once guardrails run in CI. It merges its own pull request, once every required check passes, only after the instruction evals have stayed green several runs in a row. What is agentic engineering lays out the full ladder. Irreversible writes, such as a deploy or data deletion, pause for a person under any grant.

Guardrails stop banned patterns. They do not prove a feature works. That is a separate job, covered in how to verify AI generated code. For the full working rules, hand your agent the agentic engineering manual. The gate techniques are described one by one in engineering practices.

  • guardrails
  • how-to

keep reading

get in touch

Let's scope your project.

Tell us what you need and where things are stuck. You'll hear back within a day with a plain-language plan and a price. We skip the pitch deck and the discovery retainer.