Research Before You Task: Why 30-40% of Your AI Task Plans Are Wrong
Here is a mistake I keep making.
I plan work from memory. I sit down — or more accurately, I tell my AI assistant to sit down — and we write a task list for the next chunk of work. The tasks are specific. They have clear descriptions, dependencies, expected outcomes. They look good. They feel right.
Then someone actually reads the codebase, and a third of those tasks turn out to be wrong.
Not slightly off. Not missing a detail. Wrong. Built on assumptions that haven't been true for three months. Referencing functions that were renamed. Describing architecture that was refactored last sprint.
The Planclave Incident
Planclave is the planning system inside my AI tooling. It takes a goal, runs a multi-agent review cycle, and produces a structured execution plan with steps, dependencies, and success criteria. It is good at this. The plans are thorough.
Recently, Planclave generated a plan with eight tasks for a feature addition. The tasks referenced specific modules, function signatures, and data flow patterns. Each task had clear acceptance criteria. On paper, it was a solid plan.
Then the coder agent — the one that actually has to implement the plan — did a codebase read before starting work.
Two tasks were removed entirely. The functions they described had been merged into a different module during a previous refactor. The work they specified didn't need to exist.
Two more tasks were rescoped. The task description said "add a field to the Plan struct," but the Plan struct already had that field — it just wasn't being used in the right place. The actual work was wiring, not schema changes.
That is four out of eight tasks. Fifty percent of the plan was wrong. Not because the planning was lazy, but because the planning was working from a mental model of the codebase that was stale.
The Same Pattern in Narrator
Narrator — the Rust TTS pipeline — hit the same wall.
I drafted a task list for adding a new audio filter chain. Five tasks: create the filter module, add the CLI flag, wire it into the worker process, update the config struct, write tests.
The filter module already existed. It had been added two months earlier for the system voice filter that handles blockquoted text. The CLI flag was there too, under a different name. The worker process already had a hook for custom filters.
Three of five tasks were unnecessary. The actual work was one task: register the new filter in the existing chain and add a config option to select it.
When you plan from memory, you are not planning the current codebase. You are planning a snapshot from the last time you paid close attention. That snapshot is always older than you think.
Why This Happens
The root cause is straightforward. Codebases drift from mental models. Every commit changes something. Refactors move functions. Feature branches add fields. Bug fixes alter control flow. Unless you are actively reading the relevant code on the day you plan, your mental model is out of date.
This is not a new insight. Software engineers have known this forever. The discipline of reading code before estimating work is called "spiking" or "research" or just "doing your homework."
What is new is that AI task planning makes this problem worse, not better. Here's why:
AI planning is fast and fluent. An LLM can generate a detailed, well-structured task list in seconds. The tasks read well. The descriptions are clear. The confidence is high. This fluency masks the fact that the plan is built on stale information.
AI planning feels thorough. A plan with eight detailed tasks, each with dependencies and acceptance criteria, feels like it has been researched. It has not. It has been reasoned about. Reasoning from a stale model produces confident, detailed, wrong plans.
The waste is silent. A wrong task doesn't crash anything. It gets dispatched, a worker starts it, the worker reads the code, discovers the task is unnecessary, and marks it done with a note. The system moves on. Nobody notices that 30% of the sprint was spent discovering that work didn't need to exist.
The Fix: Read First, Plan Second
The fix is unglamorous.
Before generating a task plan, read the relevant code. Not the whole codebase. The modules, files, and functions that the plan will touch. Read them. Note what exists, what has changed, and what is missing.
In my system, this now means the coder agent runs a codebase scan before the planner writes the task list. The scan output feeds into the planning prompt. The planner sees the current state of the code — function signatures, module structure, recent changes — and plans against reality instead of memory.
The cheapest way to reduce waste in an AI task pipeline is to make reading the codebase the first step, not the last resort.
This is not sophisticated. It is the AI equivalent of opening the file before you estimate the story points.
The Numbers
After adding a mandatory codebase read before planning:
- Planclave plans went from ~50% task accuracy to ~90%. The remaining 10% are usually scope ambiguities, not factual errors.
- Narrator tasks went from ~40% unnecessary work to near zero. Most Narrator tasks are now "wire existing thing X to existing thing Y" because the codebase read reveals the existing things.
- Time cost of the codebase read: 30-60 seconds per planning session. Time saved: hours of wasted work on tasks that didn't need to exist.
The ROI is absurd. Thirty seconds of reading saves hours of building the wrong thing.
What Changed in the Process
The process change is one step, inserted at the beginning:
- Read the code. Before planning, identify the files and modules the work touches. Read them. Feed the current state into the planning context.
- Then generate the task list.
- Then review and dispatch.
That is it. No new architecture. No new tooling. Just the discipline of reading before writing.
The temptation is to skip step 1 because step 2 is fast and produces something that looks complete. Resist that temptation. A fast plan built on stale information is more expensive than a slow plan built on current information, because the fast plan generates real work that has to be undone or redone.
The General Principle
This applies beyond AI task planning. It applies to any system where a plan is generated and then executed against a changing codebase:
- Code review assignments. Before assigning reviewers, check who actually touched the relevant files recently. Not who you think touched them.
- Migration plans. Before writing a database migration, read the current schema. Not the schema from the last time you looked.
- Refactoring proposals. Before proposing a refactor, check whether someone already did half of it in a feature branch.
The codebase is the source of truth. Your memory is a cache. Caches go stale. Always check the source.
Thirty to forty percent of your plans are wrong. The codebase knows which ones. Read it first.
