Prompting for agentic coding tasks

Why agentic prompting is a different discipline from single-turn prompting

A single-turn prompt just needs to describe the task clearly enough to get one good answer. An agentic coding task involves many steps — reading files, forming a plan, making edits, checking the result, adjusting — and a prompt that's clear for a single answer can still leave an agentic session under-specified in ways that only surface several steps in, once an ambiguity that seemed harmless at the start compounds across a dozen decisions the model made without your input.

State constraints explicitly, not as background assumptions

A constraint you'd consider "obvious" — don't touch this directory, preserve this existing behaviour, this dependency can't be upgraded — needs to be stated in the task itself, not assumed to be inferable from context. An agentic session working across many files doesn't have the same implicit situational awareness a human developer familiar with the codebase's history would bring to the same task, and an unstated constraint that a person would have respected by instinct is exactly the kind of thing an agentic session can violate several steps into a task, without any signal that something's gone wrong until you review the result.

Give it a way to verify its own work

The single highest-leverage addition to an agentic coding prompt is usually a concrete, checkable success condition — a test suite to run, a specific behaviour to confirm, an output to compare against an expected value — rather than leaving "did this work" as something only you can judge after the fact. A session that can check its own progress against a real signal course-corrects during the task; a session with no verification mechanism only finds out it went wrong when you tell it, by which point it may have built several more steps on top of the mistake.

Scope matters more here than in single-turn work

An overly broad task description — "improve the error handling in this module" with no further specificity — gives an agentic session enormous latitude in how to interpret "improve," and that latitude compounds badly across a multi-step task, where each interpretive choice constrains what comes next. A narrower, more specific task description produces more predictable multi-step behaviour, even though it costs you more upfront thought to write. The cost of vagueness scales with the number of steps a task takes, which is exactly why it matters more here than for a single answer.

Reviewing intermediate steps versus reviewing only the final diff

For anything with real complexity or real stakes, reviewing a plan before execution — rather than only reviewing the final set of changes — catches a wrong approach while it costs nothing to redirect, instead of after it's already produced a set of edits that need to be partly undone. See Claude Code plan mode, explained for the mechanism built specifically for this.

Telling it what "done" looks like, not just what to start on

Agentic tasks without a clear stopping condition tend to either stop too early, missing a piece of the task the description implied but didn't state, or keep going past the point where the useful work was actually finished, making speculative additional changes nobody asked for. Stating explicitly what a complete result looks like — which files should change, what should still pass, what's explicitly out of scope for this task — gives the session an actual target to check its own progress against, rather than leaving "finished" as a judgment call it has to infer.

Iterating on the prompt itself when results are consistently off

If an agentic task produces a consistently wrong kind of result across several attempts, the fix is usually the task description, not another attempt with the same instructions and a hope for a better outcome. Treat a repeated pattern of unwanted results as a signal to revise what you asked for, the same way you'd revise a spec that kept producing the wrong software — the model is executing against what it was told with reasonable fidelity most of the time, and a repeated mismatch usually traces back to what was actually said rather than to inconsistent execution of clear instructions.

See choosing an effort level in Claude Code for how effort level interacts with agentic task difficulty specifically, and Claude Code subagents, explained for delegating a bounded piece of an agentic task without carrying its full exploration in your main context.