How I Decide When an AI-Built Feature Is Actually Done

01

Why an AI-built feature can look done when it is not

An AI coding agent normally checks the path it just built. If you asked for a booking form, it may show you a completed form and a successful save. That is the easiest path.

A real person may leave a field blank, enter the wrong email address, choose a past date, press the button twice or lose their connection during the save. The feature is not finished if those normal mistakes leave the app in a broken or confusing state.

02

My first check: compare the result with the original plan

I start with the feature notes and acceptance criteria. I check whether the person can complete the job we planned and whether the AI added anything we did not ask for.

This catches two common problems. The feature may miss a required step, or it may grow into a larger feature that now needs more code, more states and more testing.

• Can the person complete the main job?
• Does the result on screen match the acceptance criteria?
• Are the important blank, invalid and failed states covered?
• Did the AI add new behaviour that was outside the plan?

03

My second check: run the automated tests

Automated tests are useful because they can repeat the same check every time the code changes. For a booking form, a test might prove that a blank email is rejected, a valid request is saved once and a past date cannot be chosen.

I ask the coding agent to run the existing test suite as well as the new tests. A new feature can work on its own and still break something that worked yesterday.

A passing test proves the behaviour that test covers. It does not prove that the whole feature is correct, easy to understand or safe to release.

04

My third check: use the feature like a real person

I open the app and complete the journey myself. I use the normal path first, then I try the mistakes most likely to happen.

• Submit the form with a required field missing.
• Enter an invalid value and check whether the message explains the problem.
• Trigger a failed save if the test environment allows it.
• Check what happens after a successful save and where the person goes next.
• Use the feature on the screen sizes and input methods that matter for the app.

05

Acceptance criteria and a definition of done are different

Acceptance criteria belong to one feature. They describe what that booking form, feedback tool or account screen must do.

A definition of done is the wider review rule I apply to each piece of work. Mine asks whether the plan was followed, the feature checks pass, the tests pass, the main journey works and the remaining limits are written down.

The exact checklist changes with the risk. Payments, private data and production deployment need more checks than a small local form. No short checklist makes high-risk work safe by itself.

06

The checklist I use before moving the task to done

I keep this list short enough to use on every task. If one answer is no, the task stays open or the remaining work is recorded clearly.

• The feature does the job in the original user story or PRD.
• Every required acceptance criterion has been checked.
• New automated tests pass and the existing test suite still passes.
• I completed the main user journey in the app.
• I checked the important empty, invalid and failed states.
• Any work still outside the feature is written down instead of hidden.

07

How I keep the review connected to the build

I keep the plan, PRD, acceptance criteria and task together in CodeSpring. When the AI says the work is done, I can compare the result with the decision we made before the code was written.

The Kanban board keeps the task open while checks are still failing. The PRD holds the feature behaviour and boundaries. This is much easier than trying to reconstruct the original plan from an old chat.

For the tutorial on writing the feature checks themselves, read the acceptance criteria examples for AI coding.