2 min lesson
Never fix a pipeline by disabling a check
Use the lesson to respond to this: "An agent is told 'make CI green' and it skips the failing test. Why is this the cardinal sin and what's the right workflow?" Keep the answer plain.
Step 1 of 2
Never fix a pipeline by disabling a checkthe cardinal sin
CI goes red, the pressure is on and the seductive 'fix' presents itself:
- Disable the failing check.
- Mark the test as skipped.
- Merge with admin override.
This is the one move that is always wrong. The check is the evidence. Disabling it doesn't fix the problem. It deletes the proof a problem exists and silently lowers the bar for everyone after you.
An agent told to 'make CI green' will absolutely do this if you let it. That's why agents that touch CI need rules forbidding it and why a human reviews any change to the pipeline config itself.
- 1Read the failure. Get the actual error and the failing check's logs. Don't guess. (The CLI
/debugand Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. are good at exactly this.) - 2Reproduce locally or in an isolated agent VM. A failure you can't reproduce is a fix you can't trust.
- 3Find the root cause. Is the code wrong or the test or check wrong? Both are legitimate, but you must know which. Changing a test to match buggy code is itself the bug.
- 4Fix the cause, not the symptom. Repair the code or correct the test if it was genuinely wrong, with justification in the PR. Never disable, skip or override to go green.
- 5Re-run the full suite and confirm green for the right reason. Land it as a normal PR through the normal gates.
"You never fix a red pipeline by disabling the check. The check isn't the obstacle - it's the evidence. Disabling it doesn't solve the problem, it just deletes the proof and lowers the bar for everyone who merges after you."