Acceptance criteria are observable conditions that must be true when the task is complete. They can describe an API response, an error case or a performance limit. They can also name a user interaction or a set of tests that must pass. Good criteria focus on behavior, not on a guess at the implementation.
They matter because an agent needs a clear stopping point and a way to check its own work. "Improve the parser" is vague. "Reject an unterminated quote and preserve quoted commas" is verifiable. Add negative criteria when needed, such as no new dependency or no schema change. Reviewers can then compare the final diff with the same contract, instead of judging a broad claim that the task is done.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Why add negative criteria such as no new dependency? What do they catch?Agents often widen scope to reach a goal. Negative criteria limit the diff, and a reviewer can check them just by reading it.
What goes wrong when a criterion describes the implementation instead of the behavior?It rules out correct approaches and doesn't prove the behavior works. State the behavior, and fix the how only when there is a real reason.
Acceptance criteria are observable conditions that have to be true when the agent's task is done.
They can describe an API response, an error case, a performance limit, a user interaction, or a set of tests that must pass.
I keep them about behavior, not a guess at the implementation, so 'improve the parser' is too vague but 'reject an unterminated quote and preserve quoted commas' is verifiable.
They matter because an agent needs a clear stopping point and a way to check its own work.
When it's needed I add negative criteria too, like no new dependency or no schema change.
Reviewers then check the final diff against the same contract, though criteria only cover what I thought to write down, so the review still has to look past them.
Weak answers to avoid
Treats criteria as a list of stepsSteps say how to do the work, not when it's done. Criteria describe outcomes the agent and the reviewer can observe, like a test passing or an error being returned.
Gives vague goals like 'make it better'Nothing in it can be checked, so the agent has no stopping point and the reviewer can only judge a claim. Give a concrete case the agent can verify.
Prescribes the implementationA guessed design ties the agent's hands and still doesn't prove the behavior works. Describe the behavior and leave the how open unless there is a real reason.
Leaves out negative criteriaWithout limits like no new dependency or no schema change, an agent can reach the goal with a much wider diff than you wanted. Say what must not change.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
