The AI Teardown· 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 watched the whole thing, and I keep coming back to one question: why did this work, when many agent sessions like it don’t?

The session

I dispatched an AI coding agent (Claude Code) to build judgment gates for an automated publishing pipeline: citation checking, voice analysis, and a revise loop that catches its own mistakes and tries again.

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, and 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 roughly 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? Handled.

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. They’re all upstream of the model. They’re all in the brief.

1. The brief eliminates every “should I ask?” moment

This is the biggest one. Most agent runs I’ve dispatched stall because the agent hits ambiguity and does one of two things: it either stops and asks (which kills the flow) or guesses and gets it wrong (which is worse).

This brief left nothing ambiguous. It defined every file the agent was allowed to touch. It defined what “done” looked like for every step.

It defined what required an immediate halt versus what was inside the agent’s judgment to fix.

I watched it fix six different bugs across prompt files, test harnesses, and fixture data without coming back to me once, and it wasn’t because it was unusually confident. The brief had already answered the questions it would have asked.

2. The brief forces the agent to distrust its own first pass

The brief embeds a 12-item adversarial checklist. It includes a standing rule: a verdict isn’t evidence until something independently re-derives it.

That single constraint changes the entire shape of the output.

When the voice checker was producing inconsistent results, the lazy fix would have been “add a retry.” Instead, the agent dug until it found the real cause. 37 independent style rules, each evaluated by a separate AI call.

Some noise is structural, not a bug. It diagnosed the system, not the symptom.

When the revise-loop test kept failing, the easy move would have been to bump the retry count from 3 to 5. Instead, it stopped and questioned whether the test itself was measuring the right thing.

That instinct doesn’t come from the model being smart. It comes from the brief saying: “Your job is to find root causes. A patch that hides the problem is not a fix.”

3. The agent fixed the spec, not the code

This is the moment I’d point anyone to.

The original test asserted: “the AI must fully converge within 3 attempts, every single time.” Sounds reasonable. It isn’t.

A 37-rule style check run by an AI will sometimes flag a clean sentence. I don’t count that as a bug. It’s what 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.

I’d call that the difference between testing for LLM luck and testing for system correctness. The agent chose the second one, unprompted. I don’t see that very often.

4. The agent wasn’t blocked between commands

This one’s practical, not 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, you’re unlikely to see a session like this, and it’s not because the agent can’t do it. You’re the bottleneck.

The honest part

None of this happens with a vague task description.

This exact brief is the product of four QA rounds. The governing spec behind it has been revised ten times.

The house standard that governs every brief I write has 32 numbered rules. Most of them exist because an agent got something wrong in a previous session, and we wrote the rule 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 the runtime.

In my experience, most people spend all their energy evaluating which model to use and 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.