Treat the Agent as a Controllable Executor

Before configuring tools, it's worth agreeing what a coding agent even is - because the rest of the book manages exactly an executor, not a "smart chat." Autocomplete offers a fragment, and the developer picks the file, the insertion point, and the moment to check. An agent runs a cycle: it reads several files, runs tools, makes a patch, and reacts to test results. Automation runs without dialogue at all - on a predefined input, rights, verification command, and stop condition. You manage that whole cycle.

The easiest way to see the cycle is as a short chain any task reduces to.

The key is the unit of result. A good agent result consists not of a confident message but of a change and evidence: which files were touched, which cause was fixed, which commands actually ran, what the exit codes were, and what risks remain. If the product's behavior can't be observed, the task isn't finished.

From here comes the split of roles we'll return to in every chapter.

Layer · Developer responsibility · Agent responsibility

• Goal - Name the required behavior and boundaries; Clarify ambiguity
• Context - Point to canonical sources and constraints; Find the concrete files and symbols
• Change - Allow the write area; Make the smallest coherent patch
• Verification - Define the acceptance signals; Run the checks and read the results
• Decision - Accept the risk and ship; Report facts without replacing the owner

Read the table along the responsibility boundary: the developer names the behavior, allows the write area, and defines the acceptance signals; the agent clarifies ambiguity, makes the minimal patch, and brings the check results. The prompt sets the work contract, the environment limits actions, tests give feedback, and review checks that the executor didn't solve a different task.

That's where engineering begins. And the first step is not to write a prompt but to state the task contract.