When a guardrail screams: triage before you fix

Guardrails are only useful if you respond to them well, and the failure mode is predictable: the build goes red, you panic a little, and you paste the error to the AI with "fix it." Sometimes that works. Often it produces a fix that makes the red text go away without addressing what was actually wrong — the AI weakens the test, widens a type, or wraps the failing call in a try/catch that swallows the problem.

Before you let it "fix" anything, spend ten seconds on triage. There are really only three kinds of guardrail failure:

• A real bug you just introduced. The check is doing its job. Fix the code, not the check.
• A test that's now out of date. You changed the behavior on purpose, and the old assertion no longer matches. Update the test to assert the new correct behavior — deliberately, not reflexively.
• A flaky or wrong check. Genuinely rare. Be suspicious of yourself here; this is the bucket people dump real bugs into because it's the one that lets them move on.

The instruction that keeps the AI honest is to make it diagnose before it changes anything:

The test "never discounts below zero" is failing.
First, tell me WHY it fails — what does the code do now vs. what
the test expects. Then tell me which is correct: the code or the
test. Do NOT change anything until I confirm.

That one pause is the difference between a guardrail that protects you and a guardrail you've quietly trained the AI to defeat. A red check is information; the worst thing you can do is pay to make it green without reading what it was telling you.