As AI continues to reshape software development, the conversation is rapidly shifting from code generation to a deeper, more critical capability, which is understanding the codebases themselves. While AI-powered tools have significantly accelerated coding tasks, the real challenge now lies in navigating complex architectures, dependencies, and legacy systems that define modern enterprise environments. In this context, Amar Goel, CEO and Co-Founder, Bito, shares why codebase comprehension is emerging as the next frontier in AI-led development, and how architectural intelligence will be key to building scalable, resilient, and high-quality software systems.
TAM: AI tools today focus heavily on code generation. Why do you believe codebase comprehension, rather than writing new code, will define the next phase of AI-led software development?
Amar Goel: Code generation got useful faster than anyone expected, and that’s exactly what exposed the real bottleneck. The engineering leaders I talk to tell a consistent story: their teams adopted AI coding tools, saw genuine productivity gains on isolated tasks, and then hit a wall. The wall isn’t writing code. It’s understanding the system you’re writing code into.
IDC research puts the scale of this clearly: senior engineers and architects spend 60 to 70% of their time on work that happens before coding starts, feasibility analysis, technical design, cross-repo impact mapping. Every new feature creates that same queue at the same desks. Coding agents accelerated implementation. They did not touch that queue.
Codebase comprehension is what closes that gap. When AI can reason about how your system is actually built, what services exist, how they interact, what constraints your architecture carries, it can run feasibility analysis before anyone writes code, surface cross-repo impact before it reaches production, and produce technical designs grounded in the actual system.
For one of our customers, AI Architect produced 60 to 70% of what would take an architect a full week, in a single session. That is the shift that moves AI from accelerating implementation to improving the quality of what gets built.
TAM: What are the biggest risks engineering teams face when developers and AI agents operate without a full architectural understanding of the system?
Amar Goel: The most immediate risk is decisions that look correct locally but break globally. An agent fixing a bug without understanding how session state, encryption keys, and downstream service calls interact across four or five services produces code that passes local tests, clears review, and breaks in production. The debugging cycle that follows consumes far more senior engineering time than the original task saved. That pattern compounds quickly across a large engineering organization.
The deeper risk is architectural erosion. When AI agents make implementation decisions without understanding established patterns, API contracts, or cross-repo dependencies, they introduce inconsistencies that accumulate silently. Each one is small. Together they degrade the coherence of the system in ways that slow future development and create conditions for larger failures.
What makes this particularly consequential now is the pace of agentic development. Agents can generate and merge code faster than engineering teams can review it with the scrutiny complex systems require. Without architectural understanding grounding every agent decision, the speed that makes agentic development valuable becomes the mechanism through which technical debt accumulates fastest.
TAM: What role will AI play in helping developers navigate legacy systems that were built years ago with little or no documentation?
Amar Goel: Legacy systems carry institutional knowledge that documentation never captured. Teams discover this when senior engineers leave, when a new developer makes a change that looked safe in isolation and breaks three downstream services, or when an AI agent generates code that contradicts a pattern the team established years ago for good reasons. The code exists. The reasoning behind it does not.
AI Architect addresses this by building a knowledge graph that spans the codebase, business and technical intent, and operational history from issue trackers, whether that covers 50 repositories or 5,000. The distinction from traditional retrieval matters here. Embeddings find code that resembles what you searched for. A knowledge graph captures how your system actually functions, typed relationships across classes, functions, APIs, and services, full call chains, dataflow paths, and dependency structures. Intent matters – do we care about handling multiple currencies, is low latency important for this piece of functionality. And then with operational history from Jira and Linear, it surfaces signals that code alone cannot reveal. Which services have accumulated repeated hotfixes and carry instability risk. Where logging is consistently missing. What platform constraints have surfaced in past incidents.
The practical impact shows up in onboarding. Engineers who previously spent weeks building enough context to contribute meaningfully to complex legacy systems now access that context through AI Architect from day one. We see organizations reduce onboarding time by 50%. For legacy systems specifically, where undocumented complexity is highest, that reduction is most pronounced. AI simply makes institutional understanding accessible to every developer who needs it, not just the few who accumulated it over years.
TAM: Do you see AI architects augmenting human architects or eventually replacing parts of that role?
Amar Goel: The framing of augmentation versus replacement misses what is actually shifting. The constraint today is that architectural expertise does not scale. Every new feature, every cross-service change, every epic that requires a feasibility analysis creates the same queue at the same desks. Senior engineers and architects spend 60 to 70% of their time on this work before coding starts. That bottleneck does not resolve by hiring more architects. It resolves by making architectural understanding accessible to every developer and every agent working in the system.
AI Architect runs the work that today sits entirely on those desks. When a PM files an epic, AI Architect produces a feasibility analysis grounded in the actual system architecture, an epic breakdown mapped to specific services and APIs, and a spike analysis that surfaces unknowns before the team invests sprint cycles. That work gets done faster, at a scale no individual architect can match across a large engineering organization.
What this unlocks for human architects is the ability to direct their judgment toward decisions that actually require it, making tradeoffs under ambiguity, reasoning about long-term system health, weighing competing constraints that no tool can resolve on its own. AI Architect handles the knowledge retrieval and structured analysis. The architect applies judgment to what that analysis surfaces. That combination produces better architectural decisions faster than either can achieve alone.
TAM: As software systems become more complex and AI agents start contributing code autonomously, how important will architectural intelligence be in preventing technical debt and system failures at scale?
Amar Goel: Architectural intelligence will become the primary determinant of whether agentic development scales safely in enterprise environments. The risk is not that agents write bad code in isolation. The risk is that agents make locally correct decisions that accumulate into globally incoherent systems. Every inconsistent pattern, every API contract violated, every cross-repo dependency missed compounds silently until it surfaces as a production failure or a refactoring project that consumes months of engineering time.
The pace of agentic development makes this more urgent. Agents can generate and merge code faster than engineering teams can review it with the scrutiny complex systems require. Without architectural intelligence grounding every agent decision, the speed that makes agentic development valuable becomes the mechanism through which technical debt accumulates fastest.
The answer is grounding every agent decision in a planning layer before code gets written. Feasibility analyses, epic breakdowns, spike analyses, all drawn from a knowledge graph that captures your architecture, dependencies, and operational history. When an agent has an architectural plan before it writes code, the risk profile changes fundamentally. Engineering leaders gain the confidence to move from AI-assisted development to AI-driven development. That is the shift architectural intelligence makes possible, and the enterprises that build that foundation earliest will compound the advantage as their systems grow more complex.
