Stop Reading Every Line: How to Actually Work With a Coding Agent

Let's name the failure precisely, because getting this wrong wastes hours. When an agent hands you a large change, line-by-line review does three bad things at once.

First, it's slow, so you do less of it, so you review the first ten files carefully and skim the rest. Second, it trains you to look for the wrong errors. Reading code left to right is good at catching syntax and style, and terrible at catching the thing that actually breaks software: a change that's locally correct but violates an assumption somewhere else in the system. Third, and this is the sneaky one, it makes you feel productive while producing almost no assurance. You've spent an hour. You feel diligent. You know very little more than when you started.

Willison's framing is that verification is a goal, not a method. The goal is: confident that the change was applied correctly. Reviewing every line is one method, and often not the best one. A test that exercises the changed behaviour, a manual walk through the actual feature, a check that the right files were touched and no others, a diff of the observable output before and after: these are all validation, and several of them are stronger than reading.

Here's the altitude idea made concrete. Line-by-line is ground level. You're inspecting individual bricks. What you usually want is the view from the second floor: does the shape of the change match what I asked for, and does the thing still work the way it should? You drop to ground level only for the few spots where a mistake would be expensive and hard to detect any other way.

The skill, then, is knowing which altitude a given change requires, and having a repertoire of checks at each one. That's what the rest of this walkthrough builds.

Willison's phrase has two halves, and people fixate on the verify half while ignoring the instruct half. That's backwards. The quality of your instruction determines how hard the verification has to be.

Think of it the way you'd think about handing work to a capable person who doesn't share your context. Vague input produces plausible output that quietly assumes the wrong thing, and now your verification job is to reverse-engineer what the agent decided on your behalf. Specific input produces output you can check against the spec you already stated.

So before you send an agent off, the habit to build is to say, in order:

• What the change is. Not "fix the login bug" but "users with expired sessions should be redirected to the login page instead of seeing a blank screen."
• Where it lives, if you know. Pointing the agent at the right area saves it from touching files it shouldn't.
• How you'll know it worked. State the acceptance check up front: "I should be able to load the page with an expired session and land on login." This single sentence does double duty. It steers the agent, and it becomes your verification plan.
• What to leave alone. Explicit constraints ("don't change the database schema," "don't reformat unrelated files") prevent the sprawling diffs that make review miserable.

Notice what just happened. By writing the acceptance check as an instruction, you've already decided how you'll validate. The instruct half and the verify half are the same sentence, written at the start. That's the whole trick, and it's the thing that separates people who get value from agents from people who fight them.

The gotcha to watch: agents are eager to please and will report success confidently even when they've done something adjacent to what you meant. Confident instruction narrows the gap between what you meant and what they can plausibly claim to have done.

There's a second reason instruction matters, and it comes from an unexpected source. Linus Torvalds, of all people, recently described a hard debugging session where an AI did much of the grunt work, and the detail worth sitting with is how the AI behaved under pressure.

In his account, Torvalds says the AI "several times stated flat out that this was impossible and unsolvable and that we should just write a report about it." He didn't accept that. "While the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed." His dry diagnosis: "I suspect those things have been trained by people who may not be quite as stubborn as I am."

This is a validation lesson disguised as an anecdote. An agent's confidence, in either direction, is not evidence. It will declare success it hasn't earned, and it will declare defeat it hasn't earned. Both are the same failure: the agent's self-report is decoupled from ground truth.

The operating rule that falls out of this is simple and you should tattoo it somewhere. Treat every agent claim, positive or negative, as a hypothesis to be checked, not a result to be accepted. When the agent says "done," that's a prompt to run your acceptance check, not a signal to close the task. When the agent says "this can't be done," that's a prompt to push once more with more context, not a signal to give up.

Torvalds pushing a giving-up AI into a working fix is the verify-and-steer loop in its rawest form. He kept the goal fixed and kept feeding the agent back into the problem. The AI supplied tireless grunt work: adding debug code, analyzing output, iterating. Torvalds supplied the stubbornness and the judgment about whether the problem was actually solved. That division of labour is the model to copy.

If line-by-line reading is one tool, here's the fuller toolbox, roughly ordered from lowest effort to highest. You want to reach for the cheapest one that gives you real assurance for the change in front of you.

• Scope check. Look at which files changed, not what's in them. Did the agent touch only the area you pointed it at? An unexpected file in the diff is the single highest-value signal you can get in five seconds. It catches sprawl, accidental refactors, and misunderstood instructions before you read a line.
• Run the acceptance check you wrote. Load the page, call the feature, trigger the flow. Does it now do the thing you asked for? This is the check that most directly answers "was the change applied correctly," and it's often faster than reading.
• Diff the observable behaviour. Compare output before and against after. For anything with a measurable result, this beats inspecting the mechanism, because you're validating the effect the user actually gets.
• Let tests carry the load. Where automated tests exist, a passing suite validates far more than your eyes can. Ask the agent to write the test alongside the change, then read the test carefully. Reviewing one well-chosen test is a higher-leverage read than skimming forty files.
• Spot-read the risky parts. Now you drop to ground level, deliberately, for the few spots where a subtle error would be expensive and invisible to the checks above. Security boundaries, money math, data deletion. This is where line-by-line still earns its keep.

The point isn't that reading is never worth it. It's that reading is the expensive tool you save for the small surface where it's the only tool that works.

This maps onto a Trust Boundary habit worth keeping. Identify the places where a mistake crosses from cheap-to-fix into expensive-or-dangerous, and concentrate your scarce close-reading attention there. Everywhere else, the cheaper checks are not just faster, they're genuinely more reliable at catching the errors that matter.

The habits above are much easier to run if your working setup supports them. A few structural choices turn confident instruction and verification from willpower into defaults.

Work in small, reversible increments. The larger the change an agent makes in one go, the harder every validation move becomes. Ask for one coherent change at a time. A small diff is a diff you can scope-check at a glance and roll back without ceremony. This alone eliminates most of the dread.

Keep changes isolated so you can throw them away cheaply. If reverting an agent's work is a one-step operation, you can afford to be experimental in your instructions and strict in your verification. When rollback is expensive, you get conservative and slow, which defeats the point of using an agent at all.

Make the acceptance check runnable, not mental. If your "how I'll know it worked" is a command you can run or a page you can load, verification takes seconds and you'll actually do it. If it lives only in your head, you'll skip it under time pressure.

Watch for the confidence trap in the report. Agents write persuasive summaries. The tooling ecosystem is moving fast, with frequent small releases across the stack, from the llm command-line tool's ongoing fixes to the AI SDK's steady stream of provider updates. Capable tools everywhere. None of that capability changes the core discipline: the summary the agent gives you is a claim, and your acceptance check is the verdict.

The Autonomy Spectrum is the useful lens here. You get to choose, per task, how much rope to give the agent, from tight copilot mode where you approve each step to near-full autonomy where you only check the end result. Most bad experiences come from picking the wrong point on that spectrum for the task: full autonomy on something you can't cheaply validate, or fussy step-by-step approval on something a single acceptance check would have settled. Match the leash to how expensive a mistake would be and how cheaply you can catch it.

Zoom out from your own keyboard and the same skill reshapes how a team should organise agent-assisted work. If the load-bearing skill is confident instruction plus confident verification, then teams are optimising the wrong thing when they build elaborate mandatory line-by-line review gates and call it safety.

That's not review. It's surveillance with extra steps, and it scales badly. It also selects for the weakest form of validation, the human eye passing over generated code, which we've already established is not where the real errors hide.

A team that takes Willison's framing seriously invests differently. It invests in making acceptance criteria explicit and testable, because that's the input that makes both steering and validation easier for everyone. It invests in fast, cheap rollback, because that's what lets people move quickly without betting the system on any single agent run. And it invests in teaching people the repertoire of validation moves, because the scarce skill is knowing which check to run for which change, not the willingness to read diffs.

The uncomfortable implication is that the skill gap here is a real gap, and the industry hasn't named it well. We talk endlessly about whether to trust agent output. We talk far less about whether people know how to instruct and validate well, which is the actual determinant of whether they get value. Torvalds got a genuinely hard bug fixed not because he trusted the AI, and not because he read every line it wrote, but because he instructed it stubbornly and kept validating until the problem was actually solved.

That's the whole skill. Not surveillance. Steering.

Start your next agent session by writing the acceptance check first. Everything else follows from that one habit.