AI coding tools are getting better, but project context still feels broken
I've been thinking about something that keeps happening when using AI for software development.
The AI can write code surprisingly well.
But before it can do something useful, you often have to explain the project again.
Things like:
What the project is actually trying to solve
Why a particular architecture was chosen
What decisions were made previously
Which parts of the code are intentional and shouldn't be changed
How different parts of the system depend on each other
What was already tried and didn't work
What the current priorities or constraints are
A single chat can understand some of this, but then you start another session, switch tools, or come back a few days later — and a lot of that understanding is gone.
So the workflow becomes something like:
Explain → work → correct the AI's assumptions → explain more → work again.
And the more complex the project becomes, the worse this seems to get.
I'm curious how other founders and developers deal with this.
Do you keep a bunch of documentation specifically for AI?
Do you maintain AGENTS.md, CLAUDE.md, project instructions, architecture docs, etc.?
Do you rely mostly on the AI's repository access and hope it figures things out?
Or have you built your own system for keeping project context consistent across different AI sessions/tools?
I'm especially interested in what happens after a project has been under development for several months, when there are hundreds of decisions and assumptions that aren't obvious from the code itself.
Is persistent project context actually a problem you're dealing with, or does the current combination of repo access + documentation + AI memory already solve it well enough?
Project context breaks when the tool cannot distinguish durable decisions from temporary conversation. I would separate architecture rules, current task state, open questions, and evidence, then let the user approve what becomes persistent instead of dumping every chat into one memory layer.
Exactly. I think the separation is important because not everything an agent encounters has the same durability.
A conversation might contain a temporary workaround, while an architecture decision may need to survive for months. And an open question shouldn't quietly become a “fact” just because it appeared in a previous session.
The part I'm still exploring is the evidence layer: if something becomes persistent, I'd want to know not just what was remembered, but why we believe it, what it depends on, and what could make us reconsider it.
Otherwise, persistent context can eventually become persistent confusion.
The 'explain → work → correct assumptions → explain more' loop is the real hidden cost of AI coding tools. Most people measure time saved on writing code, not time lost re-establishing context. Those two numbers probably cancel each other out on complex projects.
Exactly. I think that hidden cost becomes much more noticeable as projects grow. I’m curious whether anyone actually tracks how much time they spend rebuilding context — it would be interesting to compare that against the time saved by AI.
Nobody tracks it because it feels like thinking, not work. But the context rebuild is real work — it just doesn't show up in any productivity metric.
Exactly. That’s probably why the cost stays invisible — context rebuilding feels like “thinking time” rather than a separate task. But across a long project, those small resets can add up to a surprisingly large amount of lost engineering time.