Milestones for AI-assisted projects

Milestones for AI-assisted projects should be defined by outcomes a person has accepted and checks that currently pass, not by the number of tasks closed. Agents close tasks quickly, so a milestone written as finish the twelve checkout tasks can be met on paper while the checkout still fails for real users. A milestone written as a customer can pay by card in the staging build, the end-to-end payment test passes, and the owner has accepted it is much harder to fake and much more useful to plan around. This article explains the three kinds of closure that people tend to merge, how to write exit criteria that hold up with agent work, and how to run a milestone review. For measuring the path to a milestone week by week, see tracking built versus accepted.

A milestone is an accepted outcome

A milestone marks a point where something is true about the product, not a point where a list of tasks is ticked. Task lists are useful for doing the work, but they are a guess about what it takes to reach the outcome. Agents make that guess more fragile: they may complete each task as written while missing the integration between them, or solve a task in a way that quietly breaks an earlier one.

Write each milestone as a short statement a user or stakeholder would recognize. Examples: an invited user can sign in with a magic link and reach their dashboard; the CSV export matches the reference file for all three sample accounts; the nightly import runs for a week without manual repair. Each statement is testable, and none of them mentions how many cards it took.

Tasks still roll up to the milestone, but as supporting work. When every task is closed and the outcome is not true, the milestone is not met. That is the point of defining it this way.

Implementation, acceptance and release are different events

Three kinds of closure get confused on agent projects. Implementation closure means the work is built and the task is closed as far as the builder is concerned. Acceptance means a named person checked the outcome against the milestone statement and agreed it holds. Release means a decision to put it in front of users, which also depends on things outside the milestone, such as documentation, support, legal review or simply timing.

These happen in that order, but not always close together. It is normal for implementation to close weeks before acceptance, especially when one person reviews everything. It is also normal for an accepted milestone to wait for release. Problems start when a report uses one word for all three. A status line reading checkout milestone done might mean any of them.

Use distinct words and keep them on the milestone itself: implemented on a date, accepted by a person on a date, released in a version. If only the first is filled in, everyone reading the plan knows exactly where things stand.

Writing exit criteria that agents cannot game

Each milestone needs exit criteria in three parts. The outcome statement, in plain language. The checks that must pass, named specifically, for example the checkout end-to-end test and the rounding unit tests in the money module. And the acceptance step: who looks, what they look at, and on which build.

Name checks that exist outside the agent's own report. An agent saying all tests pass is a claim; a check you or your CI ran on the current code is evidence. See self-reported versus independent checks for why that distinction matters.

Require the checks to be current at the time of acceptance. If a shared file changed after the checks last passed, rerun them. A milestone accepted against stale results can unravel when someone touches common code a week later.

Avoid criteria such as code reviewed or tests written with no further detail. They describe activity, not outcome. A criterion is useful when someone else could check it and reach the same answer.

Running a milestone review

Step 1: Freeze the build you will review. Note the commit so the result is tied to specific code.

Step 2: Run the named checks on that build. Record pass, fail or unknown for each. Unknown is not pass.

Step 3: Walk the outcome statement yourself, in the way a user would. For a sign-in milestone, actually sign in with a fresh account.

Step 4: Decide. Accept, accept with listed exceptions, or reject with a short list of what must change. Write the decision, the date and the reviewer on the milestone.

Step 5: Reopen supporting tasks that the review showed to be incomplete, even if they were closed. Closing them again later is cheap; leaving them closed hides the gap.

Step 6: Re-plan the next milestone with what you learned. If acceptance took much longer than expected, budget more review time next time. Milestones with fixed dates can also sit on a timeline; see Gantt planning for agent work for when that helps.

QUESTIONS

How do I define a milestone for an AI coding project?

Write a short outcome statement a user would recognize, name the specific checks that must pass on the current code, and say who accepts it. Avoid defining it as a set of tasks closed, because agents can close every task while the combined outcome still does not work.

What is the difference between acceptance and release?

Acceptance means a named person checked the outcome and agreed it meets the milestone. Release means deciding to put it in front of users, which can also depend on documentation, support, timing or other milestones. An accepted milestone can wait for release; a released one should already be accepted.

Should a milestone be reopened if a later change breaks it?

Yes. Record that the outcome no longer holds, reopen the affected supporting tasks, and accept it again once the checks pass on current code. Leaving it marked accepted makes later progress reports wrong and hides the regression from anyone who plans around it.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• Gantt planning in BRAIN FLUID: the integrated view and its prototype

RELATED HARNESS PAGES

• Tracking AI agent progress: built vs accepted Tracking AI agent progress: built vs accepted. Keep implementation, current evidence and acceptance as separate numbers and read them weekly.
• Self-reported vs independently run checks for AI agent work Self-reported vs independently run checks for AI agent work: why an agent's own "tests pass" is weaker than a check the system runs itself.
• Deciding which AI agent tasks need human sign-off Deciding which AI agent tasks need human sign-off: a risk-based policy, who signs off what, and why DONE is not the same as released.
• Gantt planning for AI-assisted development Gantt planning for AI-assisted development: when a timeline helps with dependencies and deadlines, when it misleads, and how to treat undated work.
• Stale test results Stale test results describe code that has since changed. Bind each result to a revision and rerun checks on every completion attempt.
• Keeping long-running AI coding projects on track Keeping long-running AI coding projects on track: written goals, scheduled re-planning, drift checks between plan and code, and tested backups.