I use coding agents because they can implement changes quickly. That speed is useful only when the task begins from valid assumptions. If the repository is missing an interface, a product decision, a working build, or a way to test the result, continuing the feature usually produces code that will have to be changed or discarded.
First define what is missing
Suppose an agent is adding a feature and discovers that the codebase has no interface for the storage operation it needs. The feature is now blocked by the missing interface. Writing directly against one storage implementation does not remove the blocker. It hides the decision inside the feature.
The same problem occurs when requirements are unclear, the build is broken, or there is no test harness for the behavior being changed. Before writing more code, state exactly what is missing. A vague blocker cannot be solved. A missing interface, decision, build, or test can.
Make the prerequisite its own change
I use the following sequence:
- 01Return to a clean starting point.
Remove unrelated partial work. Keep one goal in the working tree.
- 02Name what is missing.
Write down the interface, decision, build capability, or test that the feature requires.
- 03Build only that prerequisite.
Do not include part of the original feature in the same change.
- 04Verify it.
Run the test, build, or observable behavior that shows the prerequisite works.
- 05Return to the feature.
Continue from a repository where the new capability exists and has been checked.
Why separate changes help
Less context
The agent has one goal and does not have to preserve several partially correct assumptions.
Clear failures
If verification fails, the cause is inside one small change instead of several overlapping changes.
Useful history
The commits show which capability had to exist before the feature could be built.
Reuse
The prerequisite may support other features after the original task is finished.
Verification is part of the prerequisite
A prerequisite is not complete because the code exists. It is complete when there is evidence that the code provides the capability the feature needs. Depending on the change, that evidence may be a focused test, a successful build, or a behavior observed in a realistic environment.
This is especially important with coding agents. An agent can produce plausible code faster than a person can review it. A fast test or build gives better feedback than another round of explanation. The feedback also becomes part of the repository, so the next change can use it.
Before continuing, answer three questions:
- What exactly is missing?
- How will I know that it works?
- Can I build and verify it without also building the feature?
Not every unknown requires a separate change
Use this approach when continuing would make downstream work invalid: a required interface does not exist, a product decision changes the data model, the build is broken, or there is no way to test the behavior. A small and reversible unknown is different. State the assumption, test it cheaply, and continue.
The practical question is simple: will continuing teach me something useful, or will it only create more code based on an assumption I have not checked? If the assumption can invalidate the feature, resolve it first.
The result
This may look slower at the beginning because the original feature stops moving. But the missing capability has to be built either way. Building it separately makes the decision visible, makes failure easier to diagnose, and gives the feature a verified starting point.