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

Direct answer

Key takeaways

• The most dangerous part of a vague task is not weak execution. It is everyone moving toward a f...
• Stop Making the Agent Guess: Define Done Before the Work Begins Many AI projects do not get stu...
• You tell an Agent, “Improve the login experience.”
• It moves quickly. It changes the button, adds error handling, adjusts session logic, and cleans...
• 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 wor...

Search questions

• What is Define done before an AI coding agent starts
• Why Define done before an AI coding agent starts matters now
• What are the key shifts in Define done before an AI coding agent starts

Full article

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 path.

The same task, before and after

The vague version:

Improve the login experience.

The executable version:

Goal: help an existing user enter the workspace.

Condition one: valid credentials open the workspace.

Condition two: invalid credentials show a clear message and preserve the entered account.

Condition three: refreshing after sign-in keeps the session active.

Evidence: verify valid sign-in, invalid sign-in, and refresh recovery in a real browser.

Boundary: keep the existing account system and login entry.

The second version does not dictate which file to edit or which architecture to choose. It makes the goal, endpoint, evidence, and boundary visible at the same time.

That changes the execution.

The Agent knows which real path to inspect first, which changes are outside the task, and when it should stop. You do not have to invent acceptance criteria after the implementation, and you do not have to judge effort by the number of changed files.

Completion criteria protect the task from “while we are here”

Agents are good at noticing adjacent problems: duplicate code, old dependencies, inconsistent names, and nearby interaction flaws.

Noticing them is useful. Deciding whether to solve them belongs to the current goal.

Completion criteria create a clear circle of attention. Problems inside it must be closed. Problems outside it can be recorded, but they should not quietly take control of the task.

This does not reduce the Agent’s capability. It concentrates that capability on one real outcome.

When the three conditions are true, the task can end. If a new issue appears, decide whether it blocks the current result or belongs to another stage. Progress no longer depends on whether more code could be changed. It depends on whether the promised result is true.

SoloMap places “done” before execution

In SoloMap, a roadmap stage can carry more than a task title. It can bring its goal, completion criteria, boundaries, and previous handoff into the Agent conversation, so the work begins with a shared endpoint.

The Agent still investigates, implements, and verifies. You still decide which result is worth completing.

Instead of spending a long conversation repeatedly recalibrating the task, both sides begin with observable conditions and let execution move toward them.

Rewrite one task in the next fifteen minutes

Find the vaguest item in your task list. It may be called “improve the homepage,” “finish payments,” “fix performance,” or simply “complete this feature.”

Before starting an Agent, write:

1. one action the user will be able to complete;
2. one critical boundary that must remain true;
3. three observable conditions that prove the result;
4. the evidence you will personally inspect.

Then remove items that are only implementation guesses and do not change the user result.

If another person can read those lines and determine when the task is complete and what must not be changed, the Agent now has an endpoint.

Defining done does not slow the start. It prevents the whole project from accelerating toward the wrong finish line.

Frequently asked questions

What is the core conclusion of Stop Making the Agent Guess: Define Done Before the Work Begins?

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 t...

Why should you pay attention to Stop Making the Agent Guess: Define Done Before the Work Begins now?

The most dangerous part of a vague task is not weak execution. It is everyone moving toward a finish line nobody defined.