writings · 08 May 2026
the breadcrumb trail
// ai · planning · workflow
AI coding assistants struggle to keep the full codebase in mind while working on it. This is probably the main factor preventing AI agents from delivering great code, but flat, insipid architecture.
As a developer, you need to carefully curate the context window for every session — think of the agent as a genius-level toddler that easily gets distracted. If you can channel its attention to the right problem, you can do amazing things, but the risk of information overload is real.
How I approach this is through rigorous planning. It's funny, but since AI-assisted coding has become the norm, planning now takes up more than 50% of my time, whereas in the old days it was probably the thing I neglected most.
plan more — what does that mean
That is constantly evolving in my workflow, especially since the tools keep getting better. Because the agents can look into the code so easily now, every planning conversation probably follows this shape:
- This is what we built so far... do you agree?
- We are now going to add this feature, and here is the bigger picture of what it might become...
- Ok, ok, yes, this is all great, but we are thinking too far ahead — I only want to build this part.
- Great, and how does that fit into our overall development roadmap (reference document)
- Sure, that could work, but if we do it this way... we could also do this later...
- Ok, ok, but remember we just want to build it as a standalone feature first...
- Yes, break it down into steps now. You can add documents to the "Projects folder."
- (actually read the docs)
- The docs look good, but you misunderstood what I meant by...
- Oh, and also make it clear we need to add tests. Please reference the testing guidelines (reference document)
- And so forth...
The main problem is that discussions like this drag on, and you quickly run out of context. Especially, you are going down rabbit holes all the time. The key is to defer discussions for later — but document those decisions.
document your decisions
That is the key point I'd like to share. Document decisions even if they turn out to be wrong later. That is also useful context for future discussions. Make sure there is a date next to that decision.
That is why, in every codebase, I have a docs/projects folder, and every change I make to the codebase becomes a mini-project. As we execute, I let the agent go back to update the document, close loops, and make corrections. This project folder then becomes a self-documenting trail of breadcrumbs you can use in your future discussions with the agent.
Trust me, it will save you a lot of frustration and pain later.