Planning can be procrastination

I noticed this while preparing a set of tasks for agents. The first pass clarified the outcome. The second added boundaries and checks. By the third pass, the next action was obvious. I still reorganised the plan.

I changed headings, split tasks and adjusted their order. The document became neater while the work remained untouched. Because I was improving something related to the task, the delay felt responsible.

Planning is useful when it removes uncertainty that blocks action. Once I know what to do next, continuing to plan can become a way to stay near the work without facing it.

The fork is not between planning and no planning. Both paths begin with planning. The difference appears at the point where another planning pass no longer changes the next action.

That point is easy to miss because plans can always be improved. A cleaner plan is visible. The value of stopping is not.

Planning should answer a live question

Useful planning reduces a specific uncertainty. What outcome am I trying to produce? What must not change? What evidence will show that the work is complete? What is the first action?

These questions matter. Without their answers, I can start quickly and move in the wrong direction. Agents make this more obvious because unclear work can run for hours before the mistake returns to me.

The problem begins when I keep planning after the live questions have answers. I may add detail about steps that depend on discoveries I have not made. I may create estimates for work I do not yet understand. I may polish the language of the task instead of testing its assumptions.

At that stage, the plan no longer reduces uncertainty. It tries to remove the discomfort of acting while some uncertainty remains.

Real work will always contain some uncertainty. The only way to resolve it is to touch the thing.

Reorganisation offers safe progress

Planning gives me several rewards that execution withholds. I can see the structure improve. I can complete small edits. I can imagine a clean sequence in which nothing unexpected happens.

Execution is less polite. The build fails. The route behaves differently from the documentation. A design that made sense in my head looks weak on a phone. The work answers back.

That is why reorganising can become attractive at the exact moment action becomes possible. The plan lets me preserve the feeling that I understand the problem. Starting risks discovering that I do not.

I have done this with task systems too. I can move work between lists, change priorities and divide a project into increasingly precise pieces. Each action gives me a small sense of control. None proves that the underlying idea works.

The test is whether the change to the plan changes what I will do next. If it does not, I am probably decorating readiness.

Use action to improve the plan

Stopping planning does not mean abandoning the plan. It means letting evidence update it.

For a code change, the first action may be opening the relevant module and tracing the current behaviour. For an article, it may be writing the first 200 words before deciding every heading. For a product idea, it may be putting a rough path in front of one user.

Each action can reveal a constraint that deserves a planning change. That is different from inventing constraints while the work remains abstract.

I now want plans to work in short cycles:

1. name the outcome and boundaries
2. identify the next action
3. act until new evidence appears
4. update only the part of the plan that evidence changed

The plan stays useful because it remains connected to reality.

What about expensive mistakes

A reasonable objection is that more planning can prevent costly errors. A database migration, security change or major financial decision should not begin as a casual experiment.

That is true. The cost of being wrong should determine the evidence required before action. High-risk work needs stronger checks, recovery steps and explicit approval.

But 'plan more' is still too vague. The useful question is what risk remains unaddressed. If I cannot name it, another round of reformatting will not make the work safer.

Preparation should produce something testable: a backup, a rollback procedure, an acceptance check or a decision from the person carrying the risk. Once those exist, caution may require a controlled action rather than another document.

Stop when the next action is clear

I do not need a complete map before every journey through the work. I need enough direction to take the next step without violating an important boundary.

The implication is simple but demanding. Every planning session needs a stop condition. Mine is the moment when the next action, the reason for it and the check are clear.

After that point, the plan earns no more attention until action produces new information. If I continue reorganising it, I am not making the work clearer. I am delaying the moment when the work can correct me.