A prompt is a suggestion. A CI gate is a guardrail. Ship the gate.
Is AGENTS.md a guardrail? Not really. Some teams swear by it. Some add Slack pins. Some pray. Here is what we landed on after 25 projects, and why the only guardrail that actually holds is a wall the agent physically cannot pass.
Is AGENTS.md a guardrail? Honestly, not really. The only guardrail that actually holds is a wall the agent physically cannot pass.
There is a whole category of thing the industry keeps calling a "guardrail" that is not one. A markdown file at the repo root with rules in it. A team retro where everyone agrees on a style. A pinned Slack message. These are norms. Useful, sometimes followed, never enforced. A guardrail is different. When the agent hits one, the PR fails. The commit is rejected. The score drops below threshold. The response does not leave. The distinction matters because the norm gets ignored when the agent has a deadline. The wall does not.
Does your coding agent have a coding standard? AGENTS.md is not enough. You have to hold your agent accountable. Your coding agent should have guardrails.
What's not a guardrail
All of these are fine. None of them are guardrails.
| Pattern | Why it is not a guardrail |
|---|---|
| AGENTS.md / CLAUDE.md / .cursorrules | The agent may or may not open the file. If it does, it may or may not follow it. There is no consequence for ignoring it. |
| System prompts with rules | "Do not use any. Do not leave dead code." These are preferences. The agent honors them maybe 80% of the time, which is worse than 0% because you stop checking. |
| LLM-as-reviewer | A second agent reads the first agent's PR. Both agree it looks good. Both miss the unused import because neither is grepping. They are vibing. |
| The Slack pin | "Hey please stop writing narrative JSDoc" gets pinned, gets ignored, gets unpinned by the next admin cleanup. |
What is
A guardrail executes. It has a binary output. It runs without anyone remembering to run it.
- + A CI check with a threshold.
npx aislop@latest ci .in GitHub Actions, withci.failBelow: 70in.aislop/config.yml. Score drops under 70, the PR is red. No merge button. - + A pre-commit hook.
aislop fix --stagedruns before every commit. Slop does not enter the repo. - + A pre-push hook. Block the push if there are unresolved errors. You cannot remote away your mess.
- + An MCP server. The agent has to call
aislop scanbefore it can return its response. Score below threshold, the response does not leave the agent's tool loop.
The cheapest guardrail you can ship today
Three lines of YAML. One CI step. The smallest real wall you can put up between your repo and an agent that has stopped being careful.
That is the file. Commit it. Open a PR. The check runs. The score comes from .aislop/config.yml. If it drops below threshold, the PR cannot merge until somebody fixes it. Deterministic. No human has to remember to look at the score. Start the threshold at whatever your repo scores today minus five. Ratchet it up over time. The point is not to instantly hit 90. The point is the number never goes backwards. Every PR holds the line or moves it forward. Nothing slides.
Where rules live
aislop ships 40+ rules across six engines: format, lint, code-quality, ai-slop, security, architecture. The rules cover the things AGENTS.md asks for and cannot enforce. ai-slop/narrative-comment. ai-slop/swallowed-exception. ai-slop/unsafe-type-assertion. ai-slop/console-leftover. complexity/function-too-long. complexity/file-too-large. security/vulnerable-dependency. security/sql-injection.
Each is a deterministic check with a rule ID, a file location, and a fix path. The CI gate aggregates the violations into a score. The score is what the threshold compares against. The threshold is what fails the PR. The rule is not just told. It is enforced.
The MCP future (0.6)
On the 0.6 roadmap, aislop becomes an MCP server. One sentence pitch: the agent has to pass aislop scan before its response reaches the user. No "I'll review it in the PR." The PR never starts if the score fails. The agent's response loop does not terminate until the tool approves.
Think of it as the agent earning its output. Write code. Call aislop scan. Look at issues. Address them. Call aislop scan again. Only when the score crosses the threshold does the agent's response leave the tool loop and reach the human. The wall exists. The agent walks into it. The agent adjusts and tries again. The human sees only the version that passed.
This is the guardrail by definition. The agent physically cannot return a response until the tool approves it. CI gates protect the repo at merge time. The MCP gate protects the human at every turn.
Why norms decay
A team running on norms alone gets to a predictable place. First month, great. New rules, everyone excited, code looks cleaner. Month three, someone ships a PR violating one rule and nobody blocks it because "it is a small thing." Month six, the rule is effectively gone. Month nine, a retro proposes adding the rule back. The cycle continues until somebody realizes the rule was never really there. Only the agreement that it should be was.
Guardrails do not negotiate. They do not have an off day. They do not make exceptions for the new hire's first PR. They do the one thing they exist to do, every time, until the team turns them off deliberately. That is the property worth building for. Humans are good at judgment calls. Machines are good at refusing to make judgment calls. Use each for what it is good at.
Put the wall up
Written guardrails are nice. Executable ones are what ship. If the agent can ignore the rule without consequence, it is not a rule. It is a wish. Three lines of YAML and a threshold in config. Commit it. The next PR finds out.
Ship the gate
Drop it in your workflow. The next PR has a wall. Star the AI Slop CLI on GitHub if you want the next release in your feed.