The template wrote the ticket
Async Digital Ltd Cardiff, UK
One of my agents filed a nine paragraph issue to change two words in a code comment. The agent was right about the two words, and it had followed its instructions exactly. The filing spec fixes every ticket body as what, where, why it matters, and suggested fix, and that shape is blind to stakes: a finding with no consequence still has to fill the field marked why it matters, and with no honest answer available what fills it is an argument. The spec’s three pre-filing guards all ask whether a finding is true. None asks whether it is worth an issue, so the ticket cleared every check the system had. On this evidence, correctness is no longer what binds an AI coworker’s output. Worth is, and it wasn’t being tested.
Truth is the cheap part now. An agent with a compiler, a git history and no need for sleep will hand you more true observations in an afternoon than you can triage in a week, and every check I’d built asked whether a finding was true. Not one asked whether it was worth writing down. I found that out when an agent filed nine paragraphs to change two words in a comment.
The section the agent was told to write
The comment described a failure as “thirty lines” of compiler errors. There were six. Nothing executes the comment and no gate reads it.
I assumed the agent had lost all sense of proportion and went to fix its judgment. It had followed its instructions exactly.
Every ticket that agent files goes through a shared filing spec, and the spec fixes the body shape. Four fields, in order: what, where, why it matters, suggested fix. That shape is mandatory. It’s also blind to stakes, so it asks why a finding matters even when the finding does not.
Watch what that does. The agent holds a true observation that nothing rides on. It reaches the field marked why it matters, and the field has to be filled. No honest answer exists, so it writes the only other thing available, which is an argument. “Why it is worth correcting rather than shrugging at” isn’t an agent overreaching. It’s that field, filled in by something with no option to leave it blank.
The ceremony was the form’s doing, not the agent’s.
Three guards, all of them about truth
The same spec carries pre-filing guards, marked non-negotiable, and they’re good guards. Resolve the finding to the repo that owns it, never guess. Search open and closed issues both, because a closed one might already cover it. Check the premise against the live remote rather than a local copy, because a parallel session might have fixed it already.
Read them together and you can see what is missing. Every one asks whether the finding is true. None asks whether it’s worth an issue.
So a finding that is accurate, correctly homed, not a duplicate, and still true on the remote clears every check the system has. That’s what happened. The gate never tested the thing that was wrong with the ticket.
There’s a joke buried in here. The one claim nobody checked was the ticket’s own evidence. It says the codebase “independently learned this lesson twice”, and the codebase didn’t: the second site names the first in a comment as the precedent it is copying. The guards verified the finding and ignored the argument, because verifying arguments wasn’t on the list.
Truth is the cheap part
This is the part I think travels beyond my own tooling.
When we check an AI coworker’s output, we check whether it is correct. That reflex comes from a decade of worrying about hallucination and it isn’t wrong. Correctness is just no longer the thing that binds. An agent with a compiler, a git history and no need for sleep produces more true observations in an afternoon than you can triage in a week. Truth stopped being scarce. Worth did not.
File everything true and you get a backlog nobody can skim, where a wrong number in a dead comment arrives dressed identically to a broken build. Same headings, same evidence, same careful tone. I opened that ticket expecting something on fire.
You can’t fix this by asking for better judgment. No judgment was being exercised. A field was being filled.
The fourth guard
The fix is a fourth guard, sitting next to the three about truth. Name, in one sentence, what breaks or misleads someone if this is never fixed. Named and checkable, not argued: a gate that can’t fail, a reader who’ll act on a wrong number. If nothing can be named, it isn’t a ticket.
The rejects need somewhere to land, because a rule that quietly bins true findings is worse than the noise it removes. Under the change they become one line on a rolling housekeeping issue, or they get fixed by whoever next opens the file. One line means one line.
Three checks ask whether it is true. None asks whether it is worth writing down.
nashysolutions/foundation-dependencies#45 · guard 4 is proposed, not yet in place
The tell I’d keep even if the rest turns out wrong is this. If a ticket body needs a section arguing that the finding deserves fixing, that’s the signal to downgrade it, not the place to make the case. An argument in a ticket is a template field with no honest answer.
The comment itself gets no correction. The number doesn’t become “six” either, because a figure describing compiler output that shifts with every toolchain, sitting in prose where nothing fails when it goes stale, was never going to survive. Deleting it fixes the class. Correcting it would only reset the clock.