AI coding tools that look clean on small repos break on enterprise codebases. The codebase no longer fits inside the agent’s working context, so the agent guesses which slice to load. On a real production system, those guesses get architecturally expensive at scale.
In a recent interview with Business Insider, Boris Cherny, one of the engineers behind Claude Code, was direct about it. He said these tools are still “not great at coding” once you move into real production systems, and that for high-stakes work he still prefers to write code by hand. As he put it, “You can absolutely vibe code with AI models, but it’s not the thing you want to do all the time.”
Many engineering teams see the same pattern. AI coding tools speed up boilerplate, simple refactors, and greenfield work. They break the moment they meet a production system with multiple repositories, years of history, evolving conventions, and implicit contracts that are rarely written down.
The issue is not that AI cannot write code. The issue is that it does not understand how a system works as a whole. It lacks codebase intelligence and the architectural context that comes with it.
How scale shifts the failure from local correctness to architectural correctness
Large codebases behave differently from small projects. They have shared libraries, versioned APIs, hidden dependencies, and logic that spans services. Changes rarely stay local. A small code change in one place can affect behaviour several layers away.
The pattern holds whether the system is structured as a monorepo or split across multiple repos. Without proper monorepo and polyrepo indexing, AI coding tools cannot reason about how a change in one repo affects code in another. The agent sees one slice clearly and the rest only through retrieval fragments.
Once a task crosses file or service boundaries, failure modes show up quickly. The AI suggests internal APIs that look right but no longer exist. It follows patterns that used to be correct but have since changed. It generates logic that works in isolation but breaks upstream or downstream behaviour after deployment.
The overall output often looks fine locally. It is wrong at the system level.
A recent JetBrains study by Olga Bedrina backs this. Over 600 developers cited things like “lack of context” and “limited understanding of complex code” as the top failure point in AI tooling, even more than hallucinations.
Here’s where things go wrong without codebase context or architectural impact analysis:
- Misuses internal APIs
- Suggests outdated or incorrect patterns
- Misses upstream changes or data shape mismatches
- Fails to reason across service boundaries
For teams working across repos, this becomes a daily drag. We wrote about that in more depth here: Engineering teams with cross-service repos need Bito.
This is not a model problem. It is a scale problem. And scale changes the failure pattern from local correctness to architectural correctness. The unit the AI has to get right is no longer the file it edits. It is the system the file lives inside.
Why more prompts and context do not solve system understanding
When AI coding tools struggle in large codebases, the usual response is to add more context. Longer prompts, bigger context windows, more files, or better instructions. These changes help a bit, but they do not fix the underlying problem.
Large codebases do not fail because the AI lacks enough text. They fail because understanding a system is not a text problem but a structural one.
Context windows and code search flatten systems
A context window, no matter how large, is still a flat slice of code. It does not capture relationships between services, APIs, and dependencies. It cannot explain which components depend on each other, which contracts are stable, or how changes propagate across the system. You can fit more files into the prompt, but you still lose the shape of the system.
Code search has similar limits. It is useful for locating files and symbols, but it cannot explain behaviour. It shows where something lives, not how it flows through the system or what breaks when it changes. In large codebases, understanding behaviour matters more than finding files.
Retrieval improves recall, not reasoning
Embeddings and retrieval help pull in related code, but relevance in large systems is rarely about textual similarity. The most important context is often structural. Authentication layers, shared middleware, data contracts, and side effects usually sit far from the code being edited.
Without understanding these relationships, AI tools retrieve fragments and guess how they fit together. As systems grow, interactions multiply faster than line count. Small changes start to have global impact.
Tools that rely on prompts, context windows, or search operate on pieces of code, not on the system itself.
To work reliably in large codebases, AI needs more than better retrieval. It needs codebase intelligence.
Architectural drift, the failure that compounds over time
The failure modes above are the visible kind. The AI suggests an API that does not exist. The developer catches it. The PR gets fixed. Painful, but contained.
The more dangerous failure pattern is architectural drift. The system gradually moves away from its intended design as the AI makes hundreds of edits that each look reasonable in isolation. No single change trips a review alarm. The drift compounds across services, conventions, and contracts. By the time it surfaces at the system level, the architect no longer recognises the topology, and the cost of untangling it is measured in quarters, not sprints.
This is the long-tail cost of AI coding tools that operate without architectural context. Without architectural impact analysis on every change, the agent has no way to know whether a suggestion is consistent with the patterns the team has actually adopted, or whether it introduces a small but cumulative deviation.
Drift is rarely detected in the moment. It surfaces in retrospect, often when a new engineer asks why the codebase contains three different patterns for the same concern, and nobody remembers approving the change that introduced the second one.
The same gap that produces the visible failures produces the invisible ones. A code-layer tool cannot detect architectural drift because it has no view of the architecture it is drifting from.
The missing layer is codebase intelligence
The consistent failure across AI coding tools points to the same gap. They do not understand systems.
Codebase intelligence means knowing how a codebase behaves as a whole. It is not about reading more files or retrieving more snippets. It is about understanding relationships:
Which services call each other. Which APIs form stable contracts. Where data flows. What breaks when something changes.
In large software systems, this understanding does not live in any single file. It emerges from how components interact over time. Human engineers build this mental model slowly, through debugging, incidents, reviews, and repeated exposure to change.
AI coding tools like Cursor and Codex do not have access to that model.
Without codebase intelligence, AI can only operate locally. It can generate code that looks correct in isolation but fails once it interacts with the rest of the system. That gap becomes wider as the codebase grows, and more teams work in parallel.
If AI is going to work reliably in large codebases, it needs this missing layer.
Codebase intelligence is not documentation or tribal knowledge
Many teams assume this problem can be solved with better documentation or stricter conventions. In practice, that rarely works.
Documentation goes stale. Architecture diagrams lag reality. READMEs explain intent, not behaviour. Tribal knowledge lives in people’s heads and disappears when teams change. None of these keep up with fast-moving systems.
Codebase intelligence is different. It reflects the current state of the codebase. It captures how services, APIs, schemas, and dependencies actually connect today, not how they were designed months ago.
This is why the problem keeps resurfacing. Teams rely on static artifacts to explain dynamic systems. AI tools then consume those same incomplete signals and make confident but incorrect decisions.
To move forward, AI needs access to a living representation of the system. One that stays in sync with the code and encodes how the system really works.
What changes when AI dev tools understand the system
When AI tools operate with codebase intelligence, their behaviour changes in very concrete ways. They stop guessing. They stop treating code as isolated files. They start reasoning about impact.
Instead of suggesting code that only looks correct, the AI understands how changes propagate across services. It knows which APIs are stable contracts and which are internal details. It can see call flows, shared dependencies, and downstream effects before generating or modifying code.
This is what makes grounded code generation possible in large codebases. The output aligns with existing patterns, respects system boundaries, and avoids breaking behaviour elsewhere. Engineers spend less time validating suggestions and more time building.
The same shift applies beyond code generation.
Debugging becomes faster because the AI can trace how failures move through the system. Onboarding improves because new engineers can ask system-level questions instead of piecing things together manually. Reviews get easier because impact is visible, not inferred.
None of this comes from bigger models or longer prompts. It comes from giving AI access to how the system actually works.
Large codebases expose the architectural limits of today’s AI tools
AI coding tools do not fail because they are poorly built. They fail because large software systems are complex, interconnected, and constantly changing.
Tools that only see fragments of code cannot reason about systems at scale. As AI generates more code, the cost of not understanding system behaviour increases. Local correctness is no longer enough. What matters is architectural correctness.
The next generation of AI developer tools will not be defined by how much code they can produce, but by how well they understand the systems that code runs in.
In 2026, codebase intelligence is not a nice-to-have. It is the missing foundation. The full mechanism behind that foundation, the four signal classes that feed an architectural model, how they fuse into a code graph, and how the graph reaches the coding agent, lives in How AI coding agents understand software architecture.
AI Architect is the layer that brings that foundation to your team.
Want to see it live in action? Book a demo.
