I've been using a workflow lately that's working well enough that I know it's going to stick.
It started as one of those practical adjustments you make because something in the sessions keeps bothering you. In my case, it was the growing sense that just because I was already in a productive coding thread didn't mean every new thought belonged there.
That's an easy trap with AI.
You're building something. The thread is going well. The repo is in there. The AI understands the current task. Then another idea comes up. Not a random idea. A real one. Something the project is genuinely going to need. Maybe image handling. Maybe how internal markdown primers should work. Maybe some other feature that clearly belongs in the system, just not necessarily in the exact moment you're coding right now.
For a while, the temptation is to just keep talking in the same thread.
After all, you're already there.
The AI already knows the project.
Why not just branch off for a bit and think through that other thing too?
Because that has a cost.
What I've found is that the build thread stays much healthier when I protect it. If it's in the middle of writing code, I try to let it keep being the place where code gets written. When a side issue comes up that deserves real thought, I open a new thread inside the same project and make that thread about one thing only.
That has been paying off.
The side thread gets to stay focused. The build thread stays cleaner. And because the new thread still lives inside the same project, the AI has enough surrounding context to know what system we're talking about without having to carry every other conversation at the same time.
But the part that really made the pattern useful was what happened next.
Once the side thread reached a point where I liked the answer, I stopped leaving it as just a conversation. I had the AI turn it into a markdown document. That document captured the decision in a way I could reuse later.
Then I started doing something else with it.
Instead of treating it like a temporary note, I started adding accepted documents into the repo's docs area and wiring them into the list of files the AI is supposed to inspect before future work.
That was the moment the whole thing started to feel like a real system.
Because now the repo isn't just the source of truth for code. It's also the source of truth for decisions.
And those decisions don't all live in one giant markdown file either. That's another part I've come to appreciate. If every lesson and every feature rule gets dumped into one massive project note, then sooner or later that note becomes another kind of clutter. It starts acting like a junk drawer.
Focused documents work better.
A file for image handling.
A file for primers.
A file for whatever else needs to be remembered clearly.
Then, when it's time to work in one of those areas, the AI can pull in the right document instead of rummaging through a giant slab of mixed project history.
What I've noticed working this way is that it lets me do two things at once without making a mess of either one.
I can keep the main build thread focused on the code that's being written now.
And I can work ahead in side threads, getting future features thought through, documented, and parked until the moment they're ready to come into the live build.
That's the part I didn't fully appreciate at first.
A finished side-thread document is not just a summary. It's a parked project decision.
It's waiting for its turn.
And because I'm the one managing the overall development flow, I know when that turn comes. I know when the build thread is ready for that feature, and I can bring in the right document at the right time.
That's been working exceptionally well.
The AI does better when each thread has a clearer job.
The project does better when accepted decisions stop living only in chat history.
And I do better when I don't have to keep all of that in my head at once.
This isn't some grand theory. It's just one of those workflow changes that starts out feeling like common sense and then proves itself by making the work calmer and more recoverable.
The side threads aren't distractions anymore.
They're part of the build process.
That is the lived-workflow story behind the companion guide, Keep the Build Thread Clean.
-- Charles