Reading the output before you build on it: the step most people skip
I skipped this for the first few weeks. It cost me more rework than any other mistake.
The pattern: agent runs a task, reports complete, I move to the next task and ask it to build on the output. Eventually something breaks and I trace it back four tasks to a wrong assumption that was obvious in the output if I'd read it.
The fix is simple and kind of embarrassing: read the output before moving on.
What "reading the output" actually means
Not skimming. Not looking at whether tests pass. Actually reading the changed files and understanding what changed.
For code changes: open the diff. Read every line. Understand what each change does. If you can't explain a line, it's either not needed or you don't understand the code well enough to approve it.
For architectural decisions: did the agent pick the right approach? Not "did it work" but "did it pick the approach you would have picked if you'd thought about it for 5 minutes?"
For test coverage: open the test file. Read the tests. Do they actually test the behavior described in the task? Or do they test an easier adjacent behavior that happens to pass?
Why it matters more for autonomous sessions
In a manual back-and-forth session, you're reading the output as it comes. You catch wrong assumptions early because you're in the loop.
In an autonomous session, you're not in the loop. The agent runs, finishes, and the output is a fait accompli. If the first task's output has a wrong assumption, the agent will build on that assumption through tasks 2, 3, and 4. Unwinding that is expensive.
Reading output between tasks adds maybe 5 minutes per task. Not reading it adds hours of debugging when things compound.
The review heuristics I use
"Does this do exactly what I asked, nothing more?" Scope creep shows up in the diff. Extra files changed, extra functions added, extra error handling for cases that weren't in scope.
"If I deleted this change and rewrote it from scratch, would I write the same thing?" If the answer is no, figure out why. Sometimes the agent found a better approach. Sometimes it found a wrong one.
"Are the tests testing the right thing?" The most common test failure mode: the test passes but it's testing something slightly different than the behavior described. Easy to see if you read it; invisible if you just check the green checkmark.
The short version
Look at the diff. Read the tests. Understand what changed before you ask for more. It's slower in the short run and faster in every other way.
From running Claude Code on builtbyzac.com.
Top comments (0)