One of the easiest ways to make AI less useful on a real project is to keep asking one thread to do every job.
You're in the middle of building something. The coding thread is moving along well. The AI understands the current task. The repo is loaded. The boundaries are clear. Then some related issue comes to mind. Maybe it's image handling. Maybe it's how a help primer should be stored. Maybe it's publishing, asset management, onboarding, or some other feature you'll need before long.
The natural instinct is to just bring that new topic into the current thread.
That feels efficient.
A lot of times, it isn't.
Because the moment you do that, the build thread is no longer just a build thread. It's now carrying the current implementation work and a second kind of thinking layered on top of it. Then maybe a third. Then another design question. Then a future-facing feature discussion. Before long, the thread isn't just helping you build. It's trying to juggle building, planning, exploring, remembering, and sequencing all at once.
That's where things start getting fuzzy.
The build thread needs protection
A thread that is actively writing code should usually stay centered on writing code.
That doesn't mean every side question is forbidden. It means you need to be deliberate about what kind of work belongs there.
If you're in the middle of implementing a feature and you suddenly decide to work through the full design of image storage, import rules, document primers, or some other substantial subsystem, you're not just adding helpful context. You're changing the job of the thread.
Now the AI has to keep one foot in the current implementation and one foot in a separate design problem.
Sometimes it can do that.
Sometimes it can even appear to do that well.
But over time, this is one of the ways a productive thread starts to lose sharpness. The AI isn't just dealing with the task in front of it anymore. It's also carrying the side roads you pulled it down along the way.
That's not always a model problem.
A lot of times, it's a workflow problem.
One project, many focused threads
What I've found works much better is to treat the project as the shared context and the thread as the focused workroom.
The project folder gives the AI enough overall identity to know what system we're talking about. It knows what repo we're working from. It knows what application we're building. It knows the surrounding architecture and conventions because those come from the actual project artifacts.
The thread, though, should stay narrow.
So if I have an active implementation session going and I realize I need to think through something substantial that doesn't belong in the current coding pass, I open a new conversation inside the same project and make that thread about one thing only.
If it's about images, it's about images.
If it's about primers, it's about primers.
If it's about a documentation model, it's about that.
If it's about a feature that won't be implemented until later, that thread still gets to exist now. It just gets to exist in its own room.
That matters more than it sounds like it should.
A focused thread gives the AI a cleaner lane to think in. It also keeps the main build thread from getting polluted by design work that doesn't need to live there yet.
Work ahead without dragging the build thread off course
This is one of the strongest benefits of the pattern.
A side thread doesn't just protect the current implementation. It also lets you work ahead.
If I know a feature is coming, or I have an idea that needs to be worked through before it can be built well, I don't have to interrupt the live coding thread to do it. I can open a separate thread, work through the feature, deal with the nuances, and get it into a shape that makes sense.
That means I can solve tomorrow's feature questions without polluting today's implementation work.
This turns out to be incredibly useful in practice.
The build thread stays focused on what's being built now.
The side threads let me prepare what comes next.
Those are different jobs, and they benefit from different kinds of context.
Turn the side thread into a handoff
The side thread becomes much more valuable when you don't leave it as just a chat transcript.
Once that focused discussion reaches a useful conclusion, I have the AI turn it into a markdown document while the context is still fresh. That document captures the feature, the decisions around it, the important constraints, and the shape of the solution as we currently understand it.
That changes the role of the conversation.
It's no longer just a helpful exchange I hope I'll remember later.
It becomes a handoff.
And once it becomes a handoff, it can become part of the project.
Promote accepted decisions into the repo
This is the part that made the workflow click for me.
In my session-based coding workflow, I begin by giving the AI a zip of the repo and treating that repo as the source of truth. The instructions make it clear that the AI should not rely on memory, should not guess, and should not invent structure when the repo can answer the question. Each time it returns a build, it returns a full copy of the repo again.
So once a side-thread document has been worked out and accepted, I don't want it living only in chat history.
I add it to the repo's documentation area.
Then I wire it into the list of documents that must be read or inspected before future work begins.
At that point, the repo is no longer just the source of truth for code.
It becomes the source of truth for decisions too.
That's a big shift.
Now the project doesn't just remember what the system is. It also remembers why certain parts were designed the way they were, what rules apply to them, and what decisions have already been made.
Don't build one giant context file
There is another reason this matters.
You do not want one giant markdown file trying to store every lesson, every rule, every design choice, and every feature decision for the whole project. Eventually that becomes another form of clutter. It becomes its own kind of pollution.
A better model is modular project memory.
One focused document for image storage.
One focused document for primers.
One focused document for publishing behavior.
One focused document for collaboration or reviews.
One focused document for whatever else actually needs to be remembered.
Then, when the AI is working in one of those areas, it can consult the relevant decision file instead of dragging an oversized encyclopedia into the current task.
That keeps the signal stronger.
It also keeps the project easier to reason about.
There is also a very practical AI reason not to turn everything into one giant prompt or one giant document. Models often act like they have fully processed a large input when what they've really done is skim enough of the beginning to feel oriented. They'll summarize early, assume they've got the important parts, and start working before they've really absorbed the whole thing. So even when you explicitly tell the AI to read everything, a massive prompt can still produce shallow retrieval. Breaking project memory into focused documents makes it much more likely that the right material is actually being consulted instead of vaguely approximated.
Park the decision until it's needed
This is where the side-thread method becomes more than a cleanup trick.
A good handoff document can be parked.
That means I can work through a feature now, lock it down into a document, place it into the repo's project memory, and then leave it there until the build thread reaches the point where that feature belongs.
So I don't have to choose between focus and momentum.
I can keep the current implementation thread clean.
And I can still make progress on future-facing ideas.
When the time comes, I bring the right document into the active thread and say, in effect: here's the work we've already done on this part. Review it against the actual code and tell me whether it fits as-is or whether something needs to be adjusted.
That is exactly the kind of question AI tends to handle well.
Let implementation reality have the last word
This part is important.
The side thread is where the feature gets explored.
The build thread is where the feature meets reality.
Those are not the same thing.
Most of the time, the handoff document comes in and the main thread is able to adopt most or all of it cleanly. Sometimes it needs revision. Something in the live architecture may suggest a better seam, a safer implementation order, or a narrower interpretation of the original plan.
That's fine.
The side thread did its job by doing the thinking clearly.
The build thread does its job by applying that thinking to the real system.
The handoff informs implementation. It doesn't overrule it.
What this changes
Once I started working this way, a few things got noticeably better.
The build thread stayed sharper.
Feature discussions stopped cluttering implementation work.
Important decisions stopped getting trapped in old chats.
The repo started becoming a real memory system instead of just a code container.
And I found that I could work ahead on future features without throwing the current session off balance.
That's a meaningful improvement.
Because one of the easiest mistakes with AI is to treat one successful thread like a place where every kind of thought should now go. In reality, good AI work often depends on better separation of concerns than that.
Not just in code.
In conversation too.
The rule
The rule I keep coming back to is simple:
Don't make one AI thread do every job.
Protect the build thread.
Spin off side topics into focused conversations.
Turn those conversations into markdown handoffs.
Promote accepted decisions into the repo.
Keep project memory modular.
Then bring the right document back into the build thread when the time is right.
In other words, help the AI help you.
Related field note: Help Me Help You, AI: The Day the Side Threads Started Pulling Their Weight.
-- Charles