Stop Making the Agent Guess: Define Done Before the Work Begins

Many AI projects do not get stuck because the work cannot start. They get stuck because the work cannot stop.

You tell an Agent, “Improve the login experience.”

It moves quickly. It changes the button, adds error handling, adjusts session logic, and cleans up a few related modules. The diff grows. Tests pass. But when you open the product, the problem that mattered most to the user may still be there.

Now neither side knows what should happen next.

The Agent keeps finding things that could be improved. You keep adding, “Check this too,” or, “While you are there, fix that.” The task expands while completion moves farther away.

The problem is not necessarily execution quality. More often, nobody defined what “done” meant before the work began.

A task without an endpoint can stop only by feeling

“Improve it,” “make it better,” “finish the feature,” and “check for problems” all suggest a direction. None of them defines a result.

Direction tells an Agent which way to move. Completion criteria tell it where to stop.

Without completion criteria, the Agent has to fill in the missing definition with its own judgment. It may interpret a better login experience as a cleaner interface, stronger error handling, tidier code, or safer sessions. Each could be useful. None is guaranteed to be the result you need now.

The same ambiguity returns during review.

Are passing tests enough? Is a merged commit enough? Is a cleaner-looking page enough? Or is the task complete only when a user can sign in without getting lost?

If the answer is invented at the end, rework was already built into the task.

Completion criteria are not an implementation checklist

Once people notice the ambiguity, they often replace it with a long technical checklist:

  • change a component;
  • add a state;
  • adjust an endpoint;
  • add three tests;
  • refactor duplicated logic.

That is more specific than “improve it,” but it can still confuse implementation with outcome.

A user does not care how many internal states were added to the login page. The user cares that correct credentials open the workspace, incorrect credentials produce a useful explanation, and refreshing the page does not unexpectedly sign them out.

Strong completion criteria describe observable results. They do not prematurely write the implementation plan for the Agent.

At the end of the task, each criterion should support a direct yes-or-no answer.

Write three observable conditions

Before starting a task, answer three questions.

1. What action can the user complete?

Do not write, “The login module is improved.” Write:

A user with valid credentials can enter the workspace.

This brings attention back to the real action. Which function changes or which state mechanism is used belongs inside the implementation.

2. Which critical boundary must hold?

A happy path is not enough. Name the boundary most likely to be overlooked and most likely to change the result.

For example:

Invalid credentials produce a clear message without erasing the account the user already entered.

A boundary is not an attempt to list every possible edge case. It protects the user experience and responsibility that matter in this stage.

3. What evidence proves the result?

Do not write only, “Tests pass.” Name the object being verified:

In a real browser, complete one valid sign-in, one invalid sign-in, and one refresh recovery; all three outcomes match the criteria.

Evidence should point at the final result. If users run generated code, validate the generated code. If users click a real button, validate the real click pa…[truncated 23 chars]