Why Your AI Assistant Stops at the Repo Boundary

The questions that decide whether a change is safe are rarely contained in the repository you're standing in. The client renders a field the API stopped sending. The API enforces a rule the marketing site describes differently. The CLI ships a flag the docs never heard of. Each repo is internally consistent; the bug lives in the seams.

And the seams are exactly where AI assistants go blind, because nearly all of them share one silent assumption: the codebase is the folder you opened.

A concrete one, from this week

While working on our own docs site, we needed to verify a single sentence — a claim about who can read a repository's index. Checking it honestly required three repositories: the website that made the claim, the API service whose authorization code either backed it or didn't, and the CLI whose installer behavior determined what a customer actually experiences.

The sentence turned out to be stronger than one of the code paths behind it. We narrowed the claim. But notice the shape of the work: one question, three repos. An assistant that could only see the website would have confidently confirmed a sentence the API did not enforce — and it would have been the website's fault, discovered much later, in the worst possible way.

That shape isn't exotic. It's every "is this actually true?" question in a system that grew past one repository.

Why the boundary is where the risk concentrates

Inside one repo, contracts are checked by compilers, tests, and types. Across repos, contracts are checked by memory and hope. The API's response shape, the event's schema, the flag's behavior — these live in two places at once, and nothing fails at edit time when they drift apart.

So the risk concentrates precisely where your assistant's context ends. Within the folder it can at least open files and sample. The sibling repo often isn't on the machine at all — there is nothing to sample. The assistant doesn't degrade at the boundary; it stops, and fills the gap the only way a language model can: by inferring what the other side probably looks like. Probably is how the field gets renamed on one side only.

What crossing the boundary actually takes

Not a monorepo migration, and not pasting one repo into another's context window. Three capabilities, each with an exact answer:

Knowing what exists. Which repositories are indexed, and how current each one is — so "check the API side" is a lookup, not a guess about what the API side is even called.

Asking by name, anywhere. "Where is applySubscription defined, and who calls it?" should be answerable in a repo you have never opened locally, from the session you're already in. Once every repo is indexed the same way, the boundary stops being a context switch — the same question works on either side of it.

Following a call across the seam. A frontend symbol or a URL path on one side, the handler serving it on the other. This is the query that turns "the dashboard is broken" into "this panel calls an endpoint whose handler changed last Tuesday."

This is how cix approaches it: each repository gets its own index, your assistant queries any of them by name from one session, and it composes the answer. We're deliberate about what that is not — there is no pretend unified call graph spanning repositories. The assistant reasons across per-repo answers, each carrying its own commit and freshness. A stitched-together graph that hid the seams would fail exactly the way the seams do: silently.

The honest limits

Two things people assume about cross-repo tooling that aren't true here, stated plainly. Indexing several repos means each is connected and enabled individually — repo number four isn't visible because repos one through three are. And access follows the repository: on a team, you read the owner's index of a repo only as a verified collaborator on that repo, not because you're colleagues. Convenience that widened access would be a bug wearing a feature's name.

The docs-site sentence above took three repositories to check, and we only knew that after we'd checked. That's the part worth planning for: you find out how many repositories a question spans by answering it, not before.

More on the mechanics: working across repositories, how cix gets your code, and working with collaborators.