AI coding · Software delivery · Quality assurance
What should count as done when an AI agent writes code?
Define completion through working behavior and evidence from checks. Require the agent to inspect, test and explain the change, including what remains unverified.
Describe the behavior the change must produce
Give an AI coding task a concrete definition of completion. State the intended behavior, the conditions it must handle and the existing behavior it should preserve. A request to generate a component or modify a function leaves important verification choices open.
Identify the relevant environment and the project’s normal checks. Include the way a user or another system will reach the changed code. A function can behave correctly in isolation while the application fails to call it or handle its result.
Set the authority boundary as part of the task. Editing, pushing, merging and deploying are distinct actions. The agent should know which actions are permitted and where a person must make the next decision.
Require evidence from the actual change
Have the agent inspect the final diff and run the checks that apply. Tests should exercise the behavior being changed, including meaningful errors and edge cases. Preserve existing regression coverage unless there is a clear reason to change its expectation.
For an interface change, examine the rendered result at the sizes and interaction modes that matter. Test navigation, repeated actions and recovery from interruption. For a connected workflow, check the path across the relevant boundaries.
Keep the evidence specific. Record which version was checked, what ran and what passed or failed. If a check could not run, explain the blocker and the remaining uncertainty. A statement that the code should work is not a completed test.
Follow the change through its authorized endpoint
If publication is part of the task, verify the committed version and the checks required before release. After deployment, confirm that the intended behavior is available in the target environment. Local success and a live release answer different questions.
When a check fails, diagnose the failure and make the supported correction within the task’s scope. Rerun the affected checks after the final edit. Avoid carrying an earlier pass forward when the code or conditions have changed.
Close the task with the result, the evidence and any remaining work. The useful output is a change someone can rely on within its tested scope, together with a clear account of what is still open.