There’s a pattern I keep seeing: a developer opens one AI chat, pastes in half the codebase, and keeps that conversation running for weeks. It works well for the first few days. Then the answers get vaguer, the suggestions start contradicting earlier decisions, and eventually the model confidently generates code against an API that changed two sprints ago.
The instinct — “the more the AI can see, the better it will help” — is understandable. It’s also wrong. Here’s why, and what to do instead depending on how big your platform actually is.
Why one long chat goes bad
Three things degrade a long-running coding conversation, and none of them is the model “forgetting.”
The signal drowns. Requirements, logs, failed attempts, and abandoned approaches pile up. The model may still technically have access to a constraint you stated three weeks ago, but it now competes with everything since — and the model can’t always tell whether that constraint is still current or was superseded by something you decided on day twelve. Researchers have taken to calling this context rot: useful information buried under exploration noise, weighted less reliably the longer the context grows.
More context means more to reconcile — and more to pay for. Say your platform has ten repositories. A change to how you reverse a card transaction might touch four controllers, two domain classes (the ledger entry and the fee calculation), one mobile screen, and their tests. The other nine repos don’t help — they actively hurt, offering similarly named classes, deprecated implementations, and business rules that don’t apply. And since every token is reprocessed on every turn, an oversized context makes each response slower and more expensive even before it makes it worse.
Pasted code is a snapshot, and snapshots rot instantly. The moment a teammate merges a schema change, the version in your chat is fiction. The AI will happily produce code that’s internally consistent and incompatible with the current branch. This is the most dangerous kind of AI error: an answer that looks right because it matches yesterday’s system.
Doesn’t local indexing solve this?
Partly — but it matters which kind of retrieval your tool does, because there are two families with different failure modes.
Pre-built embedding indexes (the Cursor-style approach) search a semantic index of your workspace. Fast, and far better than pasting — but the index can lag your working tree, and semantic similarity retrieves what looks related rather than what’s authoritative. Deprecated code, generated files, and lookalike identifiers across repos all pollute results.
Live agentic search (the Claude Code-style approach) skips the index: the agent greps and reads the actual files at question time. Slower per query, but never stale — it directly solves the snapshot problem.
Here’s the catch: neither kind knows which service owns a business rule, which source is authoritative, or what depends on what. Retrieval answers “which files look related?” It cannot answer “is this change correct?” That’s why retrieval — of either kind — is a mechanism inside your context system, not the system itself.
The real fix is matching your setup to the size of the problem — and this is where most advice goes wrong, prescribing the enterprise version to everyone. (One aside before the tiers: everything below is framed around multiple repositories, but if you run a monorepo, the same failure modes and the same fixes apply at the package and module level.)
If you have 2–3 repositories: keep it light
For a small platform — say, a payments API, a customer web app, and a shared ledger library — you do not need a context platform. You need four habits:
- Put an instruction file in each repo. An
AGENTS.md(the open convention adopted by Codex and a growing list of tools) orCLAUDE.md, depending on what you use: key directories, build and test commands, conventions, things not to touch, and where generated code comes from. Keep it short and commit it with the code so it evolves with the repo. - One chat per task. New feature, new session. Bug investigation, new session. The durable knowledge lives in the repos, not the conversation. When a single task genuinely outgrows its session, don’t heroically continue — have the agent summarize its state into a short notes file in the repo and start fresh from that. The notes file survives the session and doubles as a review artifact.
- Let the agent read the live workspace and run things. An agent that can search current files, follow references, and execute tests will always beat a chatbot working from a paste. If your tool can do this, use it; if it can’t, that’s the upgrade worth making before any process change.
- Never accept a change without a build and test run. Even at small scale, “it should work” isn’t a verification strategy.
If your two or three repos share an API boundary, add one thing: a generated OpenAPI spec (or equivalent) that updates in the same PR as the code. That’s a CI step, not an infrastructure project.
That’s the whole system. Building a versioned context repository and contract-compatibility pipeline for three repos is solving a problem you don’t have yet — and the maintenance cost of that machinery is itself a form of context rot.
If you have 10, 20, or more repositories: build the full system
At this scale, ad-hoc habits stop working, because no single instruction file can explain how the pieces fit together. You need layers:
A system map. One small, version-controlled document: every repo and its responsibility, who owns each business capability, sync API relationships, async events and queues, data ownership boundaries, auth flows, and which repos normally change together. This isn’t documentation — it’s a routing map that tells the agent where to investigate. A 500-line map that’s kept current beats a 100-page architecture document nobody maintains.
Per-repo instruction files, same as the small setup, with more specific guidance placed closer to the directories it governs.
Generated contracts, not documented ones. OpenAPI specs, protobuf definitions, event schemas, shared contract packages — generated or validated in CI, so that when the backend response changes, the published contract changes in the same pull request. Add consumer-driven contract tests (Pact-style) between producers and consumers so incompatibilities fail a build instead of surfacing in production. A manually maintained Swagger file will drift; a generated one can’t.
A context packet per task. Don’t start with “understand all twenty repositories.” Start with a bounded task — “Add partial refunds to card payments. The payments API and customer app may change. Preserve the existing fee-calculation and settlement rules. Trace the request from the mobile screen through to the ledger and identify affected repos before editing” — and let the agent assemble what it needs: relevant repos, applicable contracts, existing tests, and open assumptions.
Parallel exploration for big investigations. Separate agents can explore the API, the mobile app, and the database independently, then return concise findings to the main thread. This keeps raw logs and dead ends out of the decision-making conversation. (Parallel reads are safe; parallel edits need coordination.)
Verification as a hard gate. Unit, integration, and contract tests; type checks; migration tests; diff review. The agent shouldn’t say “this should work” — it should report what it ran, what passed, what it couldn’t run, and what remains uncertain. Human approval stays mandatory for anything touching security, payments, identity, destructive migrations, or production infrastructure.
It’s worth being precise about why this last layer outranks the others: everything above it reduces the probability of an error, but only verification bounds the cost of one. A well-scoped context with no tests is still gambling. A mediocre context with strong contract tests fails loudly and safely. If you can only invest in one layer this quarter, invest here.
How to know when to climb the ladder
Repo count is a proxy. The real triggers are pain signals: the agent keeps editing the wrong repository; bugs trace back to stale interface assumptions; your task prompts keep growing because you’re re-explaining architecture every session. Each of those points at a specific upgrade — a system map, generated contracts, per-repo instructions — so add the layer the pain demands, not the whole stack at once.
A note on AI project spaces and CLI bundlers like code2prompt: they still have a place. Project spaces work for stable material — requirements, terminology, decision records — but should never become warehouses of copied source code. Bundlers are great for one-off external reviews or sharing a curated slice of code; as a daily workflow, every bundle is another snapshot that starts rotting the moment it’s created.
The principle underneath all of it
The goal was never to maximize how much code the AI can see. It’s to minimize how much it has to actively reason about, while making sure it can retrieve anything else it genuinely needs. A good setup — at any scale — is selective (only relevant context enters the reasoning), current (code and contracts come from the live branch, not an old upload), and verifiable (builds and tests decide whether the result is valid, not vibes).
Don’t give the AI your entire software company in one chat. Give it a map, a specific destination, access to the current roads, and a way to confirm it arrived safely.