AI Coding Agents
Engineering Management
Coding agent task specifications that work
September 24, 2026 - 2 minute read
A coding agent task specification should define a result that another engineer could verify without reconstructing the requester's intent. Short prompts can work for local edits, but delegated work needs more structure. The useful unit is a bounded outcome with enough repository context, constraints, and evidence to support an independent review.
Factory's Linear delegation guide recommends including the repository, desired outcome, acceptance criteria, verification steps, error messages, reproduction steps, and relevant links before assigning an issue. That same structure works for terminal sessions, pull request comments, and longer autonomous runs.
Define the coding agent task outcome
Describe what changes for a user, operator, or downstream system. "Fix checkout" leaves the agent to infer the failing behavior and the desired state. "Return a clear validation error when a saved card has expired, preserve the cart, and add a regression test" gives it behavior that can be observed.
Name the repository and the area likely involved, but avoid prescribing an implementation unless the implementation is itself a requirement. Include a reproduction path for bugs and a concrete input and output for data changes. State what remains out of scope. A useful boundary such as "do not change the payment provider integration" prevents a local problem from turning into an unnecessary rewrite.
Make coding agent task criteria checkable
Acceptance criteria should be independently testable. Each criterion needs a trigger, an expected result, and enough detail to distinguish success from a plausible-looking approximation. Prefer "an unauthenticated request to /account redirects to /login and preserves the return URL" over "authentication works."
Include negative behavior where failure would matter. Permission changes should prove that an allowed actor succeeds and a disallowed actor is rejected. Migration work should preserve existing reads as well as add the new write path. UI work should name the viewport or interaction that reviewers must exercise.
Factory Missions planning formalizes this idea through a validation contract. The contract is written before implementation and checked by validators that are separate from the workers. A normal coding task does not need that machinery, but it benefits from the same order: define evidence first, then let implementation follow.
Supply context without flooding the task
Give the agent durable project rules through an AGENTS.md file rather than repeating conventions in every ticket. Factory's AGENTS.md documentation covers build commands, directory-specific guidance, security boundaries, and validation expectations. Keep transient details in the task itself.
Link the failing test, design decision, incident, or product requirement that explains the work. Do not paste an entire repository map or long chat history when a few stable references are enough. Extra context consumes attention and can pull execution toward unrelated concerns.
Before delegation, read the specification as a reviewer. Confirm that it names the outcome, boundaries, acceptance criteria, and exact checks to run. Also confirm who may approve remote actions and who will review the resulting pull request. A task is ready when execution can proceed without guessing and completion can be judged from evidence.
