Codebase Context Isn't Just for Developers

The CEO of one of our customers created a pull request last month. He hadn’t touched code in four or five years. The company has over 200 microservices, 15 million lines of code across 573 repos. He picked up a ticket, worked through it with an AI coding agent connected to Driver, and submitted a PR.

His VP of Engineering’s reaction: “That’s why I’m spending money on this. It’s stupid not to.”

This isn’t a story about CEOs learning to code. It’s a story about what happens when codebase context becomes accessible to people who don’t live in the code every day. The same context that makes AI coding agents effective for developers also makes engineering managers, support engineers, product managers, and yes, occasionally executives, able to engage with the codebase in ways that were previously impossible.

The Relay Problem

At most companies, anyone who needs to understand something about the code but can’t read it themselves has to file a ticket and wait.

At a market data provider we work with, the support lead described his entire workflow: customer question arrives via Zendesk, he creates a Jira ticket, a rotational engineer picks it up, the engineer investigates the code, the answer comes back, and then the support lead reformats it for the customer. “The engineer will end up either looking through the code base themselves or asking the person that did write it, and it kind of will go around until someone can answer.”

He’s a full-time relay between customers and engineers. He can’t look at the code himself. He has no visibility into the logic layer. Every question that touches business logic requires an engineer to context-switch, investigate, and respond. Each hop adds hours or days.

At a health tech company, the product team files support tickets with minimal engineering context. As their engineering lead described it: “Not a lot of context for engineers because product doesn’t know the components we’ve been working on.” The product team categorizes severity and throws it over the wall. Engineers get tickets they don’t understand from people who don’t know the code. Then engineering has a clarifying question, but product is in meetings all day. The answer comes the next morning. A fix that should take an hour takes two days.

This relay problem is everywhere. Non-developers need codebase knowledge to do their jobs. They can’t get it without interrupting an engineer. The engineer loses focus. The non-developer waits. Multiply this by every support ticket, every product question, every release decision, and you start to see the real cost.

What Changes When Context Is Accessible

When pre-computed codebase context is available through an MCP integration, the relay chain collapses.

An engineering lead at one of our customers with 40 million+ lines of code used Driver to evaluate pull requests during a code freeze. He described himself as someone who “really knows the code very little and has no experience with this huge code base.” But during the code freeze, he needed to assess whether large PRs were safe to merge. “This helped me a lot to evaluate, what is this doing? What is this for?”

Without Driver, that decision would require pulling in the original author or making a judgment call without understanding the code. With it, an engineering manager who hasn’t written code in years can make informed release decisions.

The interface matters here. These aren’t people opening a terminal. They’re using Claude Desktop or Claude Chat with Driver’s MCP integration connected. It’s a chat window. They type a question in plain English and get an answer grounded in the actual codebase. The setup is the same MCP configuration developers use, but the experience is entirely different: no IDE, no command line, no code on screen.

A support lead at the same market data provider is now able to query codebase context directly instead of waiting for an engineer to investigate. Questions like “why does this data look this way?” have answers that live in the code. When the support team can get to those answers without filing a ticket, the engineers don’t get interrupted and the customer gets a faster response.

One partner we work with, a private equity firm running a program across their portfolio companies, described the furthest vision: “I want non-technical product managers to be able to self-serve behind a feature toggle, at least into a staging environment. At which point, once they’ve played with it, demoed it with customers, validated it, then we spend the engineering effort to get to production quality.”

That’s not where most organizations are today. But it illustrates where codebase context leads once it’s treated as infrastructure rather than a developer-only tool.

The Real Value: Stop Interrupting Engineers

The strategic framing here matters. This isn’t about replacing developers or making non-technical people into coders. It’s about a different problem entirely: every time a non-developer needs codebase knowledge, an engineer gets interrupted.

Support tickets pull engineers off feature work. Product questions break flow. Release decisions require someone who knows the code to weigh in. QA needs to understand what changed and why. Engineering managers need to assess risk without reading every diff.

All of these interruptions share the same root cause: codebase knowledge is locked in the heads of the people who write the code, and there’s no other way to access it.

Pre-computed codebase context changes this equation. Not by making everyone a developer, but by making codebase knowledge available as infrastructure. The same context that helps an AI coding agent navigate a 40 million line codebase also helps a support lead answer a customer question, helps a PM understand what a feature touches, and helps an engineering manager evaluate a PR during a code freeze.

The developers we work with have told us they can’t imagine working without it. The interesting discovery is that they might not be the only ones.