Vibe Coding Needs a Better Definition of Done

By Matthew Andrews · October 6, 2026

Vibe Coding Management · Part 3

A coding agent says the feature is complete. The build passes. The screen looks right.

Can the user actually finish what they came to do?

That is the question I think managers need to bring into every review of AI-assisted development.

In my experience leading technical teams and improving workflows, completing individual tasks does not always mean the larger process works. A person can finish their assigned piece while the next person still cannot move forward.

AI-assisted development makes it possible to produce those individual pieces quickly. That makes the definition of done even more important.

Start With the Promise

Yesterday, I wrote about turning user needs into useful requirements. The next step is deciding what would prove that those requirements have been met.

Consider a hypothetical requirement:

A manager can assign an owner to a blocked outcome so the right person knows who is responsible for the next step.

A developer might demonstrate a dropdown, select a name, and show a success message.

That proves the interface responded. It leaves several questions unanswered.

Was the assignment saved? Does it remain after refreshing the page? Can another authorized team member see it? If saving fails, does the manager know the assignment did not happen?

The promise was that responsibility would be clear. Our review needs to follow that promise through the system.

Follow the User Beyond the First Click

I would break acceptance into four questions:

1. Can the user complete the action?
   The manager selects an eligible owner and saves the assignment.
2. Does the result persist?
   The assignment remains after the manager leaves, returns, or refreshes.
3. Does the result reach the people who depend on it?
   Another authorized team member sees the same owner.
4. Does the system explain when it cannot fulfill the promise?
   A failed save produces a clear message and a usable recovery path.

These questions describe an experience that a manager, developer, and user can discuss together.

Technical checks support that review. A successful database write or a passing test can provide valuable evidence. But each check should connect to the outcome we promised.

Define the Evidence Before Building

If we wait until the demonstration to decide what counts as success, we make it easy to accept whatever happens to be shown.

I prefer to define the evidence alongside the requirement.

For the ownership example, that could be:

Using permitted test data, assign an owner to a blocked outcome. Leave the page and reopen it. Confirm that the assignment remains and is visible to another authorized team member. Demonstrate a failed save and show how the manager can recover without losing their work.

Now the developer or coding agent knows what must be demonstrated. The reviewer knows what to examine. The manager knows what a completed status means.

This also gives the team an opportunity to discover disagreements early. If one person expects the assigned owner to receive a notification and another expects only a saved name, that difference belongs in the requirement before implementation begins.

Keep Evidence Attached to the Version Reviewed

A demonstration can be accurate and still become outdated.

Someone changes how assignments are saved. Another change affects permissions. The team deploys a different version from the one the reviewer saw.

For that reason, I think completion evidence should identify the version and environment reviewed, the user role involved, and the behavior observed.

The record can be short:

Reviewed in the preview environment as a team manager. Assignment saved, survived reopening, and appeared for an authorized teammate. Failed-save recovery demonstrated. Production verification remains outstanding.

That tells us more than “tested.”

It also gives the next person a clear starting point if the behavior changes.

Make Uncertainty Visible

A team should be able to say:

The feature is implemented, but we have not verified that the assignment survives reopening.

That is useful information. It tells management exactly what remains.

If we label that feature complete, we hide the uncertainty inside a reassuring status.

I would rather track a few clear states—implemented, demonstrated, and verified in the intended environment—than have “done” mean something different to every person on the team.

The amount of evidence should match the consequence of failure. A wording change needs a lighter review than a permission change or a workflow that moves money. The purpose is to make the completion claim proportionate and trustworthy.

Management Owns the Meaning of Done

Developers and coding agents can help design the checks. Automated tests can make those checks repeatable. Users can tell us whether the result meets their need.

Management still has to ensure that the status being reported matches the evidence available.

My rule is simple: before closing the work, ask someone to demonstrate the user’s promise from beginning to end.

Then ask what happens when the user comes back tomorrow.

Follow the Vibe Coding Management series through the blog’s RSS feed.

Back to Blog