Blog· August 24, 2026
An AI agent ran for two and a half hours without stopping. It fixed six bugs, rewrote a broken test, and never asked me a single question.
I sat there transfixed, watching the whole thing, one long stream of Claude Code updates pouring from the screen.
As I watched, only one question filled my mind: why did this work, when so many agent sessions like it did not?
The session
I asked an AI coding agent (Claude Code) to build judgment gates for an automated publishing pipeline including citation checking, voice analysis, and a revision loop that catches its own mistakes and keeps trying.
The first attempt didn’t get far. It hit a .gitignore gap almost immediately. A file it needed to touch wasn’t on its approved list so it halted, filed a report, and waited, exactly as instructed.
I closed the gap and dispatched it again.
This second run is the one that matters. The task wasn’t simple. It touched prompt tuning, test fixtures, file path handling, error recovery, and a 37-rule style checklist that gets applied by a separate AI call.
It ran for about two and a half hours. During that time it found and fixed a working-directory contamination bug, a JSON parsing failure, and a directory-creation path error. It retuned a prompt that was over-flagging clean writing.
It corrected test fixtures using the wrong case convention and rewrote a test assertion that was checking the wrong thing entirely.
It never stopped to ask me what to do. Not once.
Everything else? It just dealt with it and kept on going.
Most people think the model is the variable. It isn’t.
The four things that made this work have almost nothing to do with the model’s raw capability itself. They’re all about the brief.
1. The brief eliminates every “should I ask?” question
This is the biggest one. Most agent runs stall because the agent gets stuck and does one of two things: it either stops and asks (killing the flow) or guesses and gets it wrong (even worse).
This brief left nothing ambiguous. It defined every file the agent was allowed to touch. It defined what “done” looked like at every step.
It defined when the agent needed an immediate halt or could use it’s own judgment to resolve.
I watched it fix six different bugs across prompt files, test harnesses, and fixture data without coming back to me once.
Not because the model had some magical, frontier-level super-intelligence. Quite simply, the brief had already answered the questions it would have asked.
2. The brief forces the agent NOT TO TRUST its own first pass
Here’s the key, the brief includes a 12-item adversarial checklist with a standing rule: a verdict isn’t evidence until something independently confirms it.
That one rule changes the entire shape of the output.
When the voice checker was producing inconsistent results, the obvious-but-lazy fix would have been “add a retry.” Instead, the agent investigated until it found the real cause. 37 independent style rules, each evaluated by a separate AI call.
Some noise it knew to ignore. It diagnosed the system, not the symptom.
When the revise-loop test kept failing, it could have just bumped the retry count from 3 to 5. Instead, it stopped and questioned whether the test itself was measuring the right thing.
That instinct isn’t the model being smart. It was the brief saying: “Your job is to find and resolve the real root cause. A patch that hides the problem is not a fix.”
3. The agent fixed the spec, not the code
Above all else, take note of this…
The original test asserted: “the AI must fully converge within 3 attempts, every single time.” Sounds reasonable. But it isn’t.
A 37-rule style check run by an AI will sometimes flag a clean sentence. It’s just what often happens when you make 37 independent judgment calls.
Some variance is structural.
The agent recognised that. It rewrote the test to check what actually matters: does the system reach a safe state?
Either the draft is genuinely fixed, or it’s cleanly halted and flagged for a human. Never silently wrong.
That’s the difference between testing for LLM luck and testing for system correctness. The agent chose the second one, unprompted, which is rare.
4. The agent wasn’t blocked between commands
This one’s practical rather than philosophical.
Claude Code can run processes in the background and check back in. It isn’t waiting for a human to type “okay, continue” between every shell command.
It’s what lets one continuous debugging loop run for two and a half hours instead of stalling every five minutes.
If your agent workflow requires you to babysit every command then quite simply you’re the bottleneck, not the agent.
The honest part
None of this happens with a vague task description.
This brief was the product of four QA rounds. The governing spec behind it was revised ten times.
The standard that governs every brief is called the brief-standard-sop, which is a markdown file with 32 numbered rules. Most exist because an agent got something wrong in a previous session, and the rule was written to stop it happening again.
I’ll say the thing nobody wants to hear about AI agents. The discipline lives in the brief, not in the model.
Give a capable agent a genuinely precise spec and enough autonomy to debug within its boundaries, and you get a two-and-a-half-hour session where it finds and fixes six bugs without stopping.
Give the same agent a paragraph of loosely described requirements and you get what everyone else gets: an agent that stalls, guesses, patches symptoms, and ships something that looks right until it doesn’t.
The brief is the product. The model is a tool.
Most people I see on Reddit spend all their energy evaluating which model to use - but almost none defining what the model should do. That ratio is backwards.
Flip it. Write the brief that removes every ambiguous decision from the agent’s path. Embed the checklist that forces it to verify its own work.
Define what “done” looks like so precisely that the agent can reach it without asking.
Or keep prompting vaguely and wondering why your agents keep asking for permission.