One of the easiest ways to waste time with AI is to do everything in a single long thread.
It starts well, then the context grows, quality drifts, and you end up with a messy mix of strategy, partial implementations, and conflicting decisions.
You get “context rot”, but you also get something worse: you lose your own clarity.
The approach that’s worked best for me is a simple two-thread workflow:
- one “planner” thread that holds the strategy and the big picture
- smaller “worker” threads for discrete tasks
Think of it like engineering management for the model.
The planner thread
The planner thread is where you keep the stable context:
The planner thread
The planner thread is where you keep the stable context:
- what problem we’re solving and why
- constraints (time, scope, business rules, architecture)
- what “done” looks like
- key decisions and trade-offs
- risks and guardrails
- the current plan and next steps
This thread moves slowly. It’s the source of truth.
I treat it like a living spec. If the plan changes, I update the planner thread summary rather than letting changes drift across a dozen messages.
The worker threads
Worker threads are where you do focused execution.
One thread per task, for example:
Worker threads are where you do focused execution.
One thread per task, for example:
- draft a spec
- write a service class
- design a migration
- fix a failing test
- write a checklist
- generate copy for a UI state
- propose a rollout plan
Worker threads should be short. They should have a clear input and a clear expected output.
The key: the worker thread doesn’t get to redefine the strategy.
It executes within constraints.
How the handoff works
The handoff is the important part.
The handoff is the important part.
Before I start a worker thread, I feed it a tight brief from the planner:
- goal
- constraints
- relevant context
- what I want back (format)
- what to avoid
Then when the worker finishes, I bring the result back to the planner thread and ask the planner to do three things:
- Validate
- Does this meet the goal and constraints? Any gaps or contradictions?
- De-risk
- What could go wrong? What tests/verification do we need? Any rollout concerns?
- Merge
- Summarise the final decision or output in a clean, reusable form (so it’s easy to copy into code/docs).
That last step matters more than it sounds. It stops you shipping “thread junk” into the real system.
Why this works
This workflow solves a few problems at once:
- reduces context rot by keeping worker threads short
- prevents strategy thrash (the planner holds the “why”)
- makes outputs reusable (planner produces a clean merge summary)
- makes validation explicit (planner checks work against constraints)
- encourages smaller tasks, which AI handles better
It also mirrors how good teams work:
- product/tech leads hold the direction and constraints
- engineers execute tasks within that frame
- reviews validate and integrate
If you want AI to stay useful over time, stop treating it like a single conversation.
Run a planner thread as the source of truth, and use worker threads for execution.
Then validate and merge back into the plan.
Run a planner thread as the source of truth, and use worker threads for execution.
Then validate and merge back into the plan.
It’s a small workflow change, but it’s one of the biggest levers I’ve found for keeping AI reliable.