Working With an Agent as a Pair, Not a Vending Machine

Two ways to work with a coding agent produce noticeably different results. The vending-machine mode — describe the task, receive the output, review it — is how most people start, and it's the mode that hits a ceiling fastest.

The difference isn't tool configuration. It's what you do in the first two minutes and what you do with the output.

What vending-machine mode looks like

Write a description of what you want. Wait. Receive a change. Review it. Accept, reject, or re-describe and try again.

It works for well-specified, well-patterned tasks — which is a real and useful category. It fails, in a specific way, on anything else: you get a confident complete answer to a question you specified imperfectly, and the failure is only visible in review, after all the work.

The re-describe loop is the tell. Three rounds of rephrasing usually means the problem was never the description.

What pairing looks like

Establish the constraints first, not in the task description. The two or three things that aren't in any artifact: this module is being replaced so keep it minimal; the finance team needs the old field name; we tried the obvious approach and it broke. → One sentence of that is worth more than any amount of prompt refinement, and it's the highest-leverage thing you do.

Ask for the approach before the implementation. "How would you do this, and what are the alternatives?" A thirty-second exchange that catches a wrong direction before it becomes a change you have to read.

Ask what it's unsure about. ✅ The single most useful question available. It surfaces the assumptions that would otherwise be invisible, and it points your review directly at the risky part.

Work in smaller units. One behavior, then the next. Smaller diffs are easier to review, and errors get caught before they're built on.

Respond to what comes back rather than accepting or rejecting it. "This assumes the caller has already validated — check whether that's true" is a shorter path to a right answer than re-describing the task.

Why it produces better results

Ambiguity gets resolved before work, not after. The constraint you supply up front is the constraint that would otherwise be guessed.

Wrong directions get caught cheap. Correcting an approach costs a sentence; correcting a completed change costs a review cycle.

Your model of the system stays current. Vending-machine mode produces code you didn't think about, which accumulates into a codebase you don't understand. Pairing keeps you in the reasoning.

Uncertainty becomes visible. Which is where the defects are.

⚠️ When vending-machine mode is correct

Not always wrong. It's right when:

• The task is genuinely well-specified and pattern-following.
• There's a strong oracle — tests will catch a mistake.
• The blast radius is small.
• You don't need to understand the result deeply afterwards.

Mechanical migrations, boilerplate, test generation from a clear contract. Pairing on those is overhead.

The judgment is which mode a task calls for, and the default should probably be pairing for anything you'll maintain.

💡 The habit that matters most

Before describing a task, ask yourself: what do I know that isn't written down anywhere?

The answer is usually two or three things, and supplying them is the difference between a good result and a plausible one. It takes fifteen seconds and it's the entire gap between the two modes.

The takeaway

Vending-machine mode works on well-specified pattern-following tasks with a strong oracle. For everything else, pair: supply the unwritten constraints first, ask for the approach before the implementation, ask what it's unsure about, work in small units, and respond rather than re-describe. And before every task, spend fifteen seconds on what you know that isn't in any artifact — that's the input nothing else supplies.