A task is not a project.

It sounds obvious.

Still, it is one of the most common mistakes when working with agents.

Someone starts by asking for an analysis.

Then asks for a plan.

Then for an implementation.

Then changes direction.

Then asks for a review.

All in the same place.

By the end, the task has become a repository of decisions, exceptions, and old requests.

The agent loses its bearings.

So does the person.

The problem is not continuing

Continuing a task is not always wrong.

The problem starts when it no longer has a clear objective.

A good task answers three questions:

  • what needs to be solved now;
  • what can be changed;
  • how we will know it is done.

Without that, every new request can change the meaning of everything that came before.

“Add authentication too.”

“First, change the architecture.”

“Forget the plan and just do it.”

“Go back to the previous idea.”

Each sentence can be legitimate.

But together, without a new boundary, they create noise.

Many iterations also increase the risk of hallucination

A long chat does not hold only decisions.

It accumulates drafts, hypotheses, corrected mistakes, superseded instructions, and incomplete information.

After many iterations, the agent can treat an old assumption as a fact.

It can cite a decision that was never approved.

It can claim it validated something that was only discussed.

It can fill a gap with an answer that sounds plausible but is wrong.

That is a hallucination.

It does not happen only because of a lack of capability.

It also happens when the context becomes confused.

The more a task mixes goals and versions of the same decision, the harder it becomes to tell what is current, what was discarded, and what still needs confirmation.

Do not use a long chat as the only source of truth.

Important decisions need to leave the conversation and enter files, tests, plans, or documentation.

A task needs to fit in one sentence

If you cannot summarize a task in one sentence, it is probably too large.

Bad example:

Understand the project, define the architecture, build the site,
write the content, review the design, and publish it.

Better examples:

Analyze the current project structure.
Do not change files.
List risks, gaps, and pending decisions.
Create an incremental plan for internationalization.
Do not implement it.
Indicate likely files, dependencies, and validations.
Implement only the language selector defined in step 1 of the approved plan.

The difference is not bureaucracy.

It is direction.

Mixing phases creates false certainty

When discovery, planning, and implementation happen in the same task, it is easy to confuse a hypothesis with a decision.

The agent can start editing before it understands the problem.

It can create a solution for a requirement that will still change.

It can follow an old decision that was abandoned in the middle of the conversation.

The result looks like progress.

But it accumulates rework.

Separating phases does not make the process slow.

It prevents speed in the wrong direction.

Divide by outcome, not by request size

It is not enough to break a large request into random parts.

The division needs to make sense.

A diagnostic task delivers understanding.

A planning task delivers an approved sequence.

An implementation task delivers a verifiable change.

A review task delivers issues, risks, or adjustments.

Each has a different output.

Diagnosis → understanding of the current state
Planning → a small, verifiable plan
Implementation → a validated change
Review → an objective assessment of the result

When the output is clear, it is easier to know when to finish.

Context needs to outlive the task

A task ends.

Useful knowledge cannot end with it.

Important decisions should go into project files:

  • AGENTS.md for lasting rules;
  • README.md for general context;
  • PLANS.md for approved steps;
  • docs/ for decisions, architecture, and risks;
  • tests and code for verifiable behavior.

This reduces dependence on the memory of a long conversation.

The next task does not need to guess what happened.

It starts from the right records.

A simple flow

Use one task for each moment.

  1. Understand the problem.
  2. Record what was decided.
  3. Plan a small step.
  4. Implement only that step.
  5. Validate.
  6. Open the next task with the previous result as context.

You do not need a task for every sentence.

You need a new task when the objective changes.

That is the boundary.

Ending is work too

Many tasks stay open because no one declared the end.

When you finish, record:

  • what was done;
  • the files changed;
  • the validations performed;
  • the remaining risks;
  • the recommended next step.

Then close it.

A task closed with clarity is more useful than an endless task with a long history.

The basic rule

Do not try to run an entire project in one task.

Give each task an objective, a limit, and an output.

Record the decisions that need to survive.

Vibe coding is not an endless conversation.

It is a sequence of decisions that can be understood, reviewed, and continued.