A prompt is a suggestion. A CI gate is a guardrail.
AGENTS.md, Slack pins, and team norms can help, but they are not enforcement. Here is what we landed on after 25 projects: put repeatable checks in the workflow, then let humans handle judgment.
Is AGENTS.md a guardrail? It helps, but by itself it is guidance. A stronger guardrail is an enforced check the workflow cannot quietly skip.
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, not automatically enforced. A guardrail is different: the check runs, the result is visible, and a configured threshold can block the commit or PR. The distinction matters because norms depend on memory; checks depend on execution.
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.
scanaislop/aislop@v0.10.1in 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, so risky changes are surfaced before they leave the machine.
- + An MCP server. The agent can call
aislop scanbefore returning its response. Score below threshold, the agent gets concrete findings to address.
A small guardrail you can ship today
One small workflow. One Action step. A practical check between your repo and code that no one has reviewed closely yet.
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 can be blocked until somebody fixes it. Start the threshold near where your repo scores today and ratchet it up over time. The point is not to instantly hit 90. The point is to make quality visible and keep the bar from drifting down unnoticed.
Where rules live
aislop ships 50+ rules and checks 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 can run aislop scan before its response reaches the user, then use the findings to clean up repeatable issues before a PR exists.
Think of it as shortening the feedback loop. Write code. Call aislop scan. Look at issues. Address them. Call aislop scan again. When the score crosses the configured threshold, the human sees code that has already passed the mechanical checks.
CI gates protect the repo at merge time. An agent-time scan protects the reviewer earlier in the loop, while the code is still cheap to change.
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 useful context. Executable ones are how teams make the rule visible every time. One workflow and a threshold in config gives the next PR a clear standard to meet.
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.