Direction is the discipline of turning an intention into an instruction an agent can actually execute: framing the task, setting scope, decomposing big work, choosing plan-vs-run, and writing acceptance criteria so “done” is checkable instead of vibes.
A working instruction names the goal, the boundaries, and the finish line. “Add rate limiting: 100 requests/min per key, return 429 with Retry-After, prove it with a test” gives the agent a target it can verify itself against. “Make the API safer” makes the agent guess — and you inherit the guess.
Plan-first pays when the change is wide (many files), risky (migrations, auth, money paths), or ambiguous (more than one sensible architecture). Run-first pays when the task is small, reversible, and cheaper to attempt than to discuss. The skill PACE measures is knowing which one you are in.
Slice by verifiable milestone, not by file. Each slice should end in a state you can check — tests green, endpoint responding, page rendering — so a failure is localized to the slice that caused it, and progress is real instead of claimed.
Acceptance criteria are the contract that lets the agent verify its own work. Agents are relentless optimizers of whatever finish line you give them — give them none, and they optimize for “looks plausible.” The METR study’s slower-when-they-felt-faster result is what unchecked plausibility costs.
You need an agent to add rate-limiting to an API. Which instruction gets the best result?
B. B names the goal, the exact policy, the observable behavior, and a self-verifiable acceptance test. A and C delegate the decision and the finish line; D explodes scope — the classic direction failure.