The Work Cycle: Plan, Execute, Validate 🔄

The most effective way to use a coding agent is not an IDE feature: it is a work cycle in three phases. Those who skip it invariably end up in one of two traps: the agent generating a mountain of wrong code (and you dismantling it), or the agent promising it fixed everything without ever running a test.

The right cycle is always the same: first the plan, then the code, then the proof. The order is non-negotiable.

Phase 1 — Read-only planning 📝

Before any file modification, the agent works in read-only mode:

it analyzes the repository structure and the context you pointed to;
it asks questions about the ambiguities it encounters;
it produces an action plan: modules involved, files to create or modify, tests to run.

The plan must be explicitly approved before moving on. This step has two effects: it prevents hasty writes on the wrong files and, since output tokens cost more than input ones, it also keeps costs down. A rejected plan costs little; an implementation session that ends in the wrong place costs a lot.

Do not confuse planning with prose: the plan must be verifiable, not elegant. If you cannot understand what it will do, neither will the agent during execution.

Phase 2 — Micro-increment execution ⚙️

Only after approval do you implement. The rule is micro-increments: the agent modifies a module, stops, verifies, then moves to the next. The alternative — letting it run on autopilot for the whole task — is acceptable only for well-delimited work covered by exhaustive tests.

In practice:

a complex task is broken into steps you can review one at a time;
after each step, intermediate verification with build, test and lint;
if a step drifts, you stop it right away, not at the end.

Some tools also support asynchronous execution: the task is handed to an agent that works in a separate context and delivers a pull request. It works well for well-specified work; it does not replace the control over what lands in the repository.

Phase 3 — Deterministic validation 🧪

The last phase is the one almost everyone skips, and it is the most important. Verification of the work is not entrusted to the agent: it is entrusted to tools.

the agent runs build, test and lint and interprets their reports — it does not certify in words that “it works”;
the completion criteria defined in phase 1 are the yardstick for the outcome;
a code review (human or assisted) closes the cycle before the merge.

The difference between “the agent says it verified” and “the agent ran the suite and the tests are green” is the difference between trust and proof.

The complete flow 🔁

    flowchart TD
  Task[Defined task] --> Plan[Planning: read-only, questions, plan]
  Plan --> Approve{Plan approved?}
  Approve -->|No| Revise[Clarify and reformulate]
  Revise --> Plan
  Approve -->|Yes| Impl[Micro-increment execution]
  Impl --> Val[Validation: build, test, lint]
  Val --> OK{Completion criteria met?}
  OK -->|No| Fix[Targeted fix]
  Fix --> Val
  OK -->|Yes| PR[Pull request and review]

Note how planning and validation are the two pillars of the cycle. Remove one, and you are back to autopilot with rework instead of quality.

When planning is unnecessary 🪶

Explicit planning is not always needed. The practical rule: it is mandatory when the task touches more than 2-3 files, introduces a new feature or crosses module boundaries. It is unnecessary for point changes to a single function, where you already know what has to change and the risk is low.

The goal is not bureaucracy: it is control at the point where the cost of being wrong exceeds the cost of planning.

When NOT to use this cycle ⛔

Trivial, repetitive tasks where the plan would be longer than the code.
Codebases without tests: if phase 3 has no tools to lean on, you are validating by eye — the cycle holds up poorly.
Pure exploration: if you are just understanding a project, there is no plan to approve, there is a reading path to follow.

Final checklist ✅

Did I define the goal with clear completion criteria?
For multi-file tasks, did I have it plan in read-only mode and did I approve the plan?
Does execution proceed in micro-increments with intermediate verification?
Does validation use real build, test and lint, not the agent’s claim?
Before the merge, is there a review (human or assisted)?