Cheaper, Faster, Better: The New Driver Transpiler

We’ve rebuilt the core of Driver’s transpiler, the context compiler underneath every Driver product. The new version onboards a codebase at about 90% lower cost and nearly 5x faster, and it keeps that context current as commits land at roughly half the previous cost. It also produces better context for the agents that build on top of software today.

Faster and cheaper usually means a tradeoff with quality, unless something fundamental changes. Here it did: we changed what our transpiler produces at each step of its architecture.

The problem your current context stack still has

Most engineering organizations already give their agents a lot: code search, embeddings, language servers, repository instructions like AGENTS.md, and often custom retrieval tools maintained by a platform team. Nonetheless, agents still produce changes that are locally correct but systemically incomplete.

The reason is structural. Every query-time approach, whether search, embeddings, reranking, or a language server lookup, is conditioned on what the agent already knows to ask for. An agent begins with a task and explores outward from the information it has. It can inspect whatever it finds, but it cannot reason about a file it never knew to retrieve.

Some of the most important relationships in a codebase are hard to discover through a query. We call these dark connections: a frontend type that mirrors a backend enum with no import between them and no shared identifier, a serialization boundary where the two sides use different names, or a registration chain that threads one change through several subtrees, where no single file shows the whole chain.

Consider adding a new provider to a system. Search and a language server find the backend enum, the dispatch map, and the route. They do not find the frontend type that mirrors the enum, because nothing imports it and no token is shared. They do not flag the marker subclass whose literal must equal the enum value, because a mismatch throws no error until deserialization.

Driver’s compiler identifies these components through different deterministic processing lanes and puts the picture together as one coupling, narrated with a modification guide. This context is compiled ahead of time and placed at the folder where all the pieces first become visible together: their lowest common ancestor.

What Driver compiles that search cannot retrieve

Search retrieves code that appears relevant to a query. Driver compiles the relationships an agent does not know to search for. It does this ahead of time, across the whole codebase, and keeps that context current on configured branches.

We project that understanding to different levels, from a single file up to the whole codebase, so an agent can orient first and then drill into specifics. The new transpiler builds that understanding from structured, deterministically derived claims about how code is connected, and carries them through every level of abstraction.

A deterministic foundation

The lowest level is a graph of relationship edges between files. Each edge names the symbols involved and how the relationship was found. Several distinct deterministic lanes produce edges:

• Language-specialized parsers.
• Exhaustive literal search.
• Value-set matching that pairs an enum in one language with its mirror in another.
• Git co-change history.

Together they illuminate connections invisible to any single lane. Every edge records its provenance, the limitations of its discovery method, and supporting metadata. This is where most of the value now comes from, and the vast majority of this processing touches no language model. Models are used sparingly for scoped enrichment of some claims.

A rollup that works at any scale

Climbing from files to folders and modules was costly and lossy in the old transpiler because prose cannot be aggregated cleanly at scale. The new typed relationships aggregate arithmetically from the union of child couplings.

A coupling that spans two subtrees becomes visible at the first folder that contains both. That placement is computed deterministically. Models then provide constrained semantic enrichment: a few hundred tokens of coupling metadata go in, with no source code, and one short explanation comes out describing why the coupling matters and what must change together. Every claim must cite the deterministic facts it was given.

Atlas: a map beyond the folder tree

At the top is Atlas, a thematic map of the codebase built by clustering the relationship graph rather than walking directories. Architecture that does not match the folder layout is expressed directly.

Atlas sizes itself to the codebase. A small codebase collapses to one page; a large one becomes a top-level index over detailed group pages, recursively. It is the first thing an agent reads, so it shapes everything after it. It also costs a small fraction of the codebase-wide documentation engine it replaces.

Why it got cheaper and better at once

The expensive part of the old system was turning local code into structured prose, then re-reading that prose to write codebase-wide guides. That was not where the most useful context came from.

Typed relationships are more useful to agents, can be produced almost entirely without a model, and roll up without asking another model to summarize everything beneath them. We still use LLMs to narrate key semantics throughout the system, but their use is constrained and focused.

The result is a cheaper and better compiler for codebases of different sizes and shapes.

What it means for your team

• Faster onboarding at lower cost. The new transpiler brings a codebase, or an estate of them, under Driver at about 90% lower processing cost and nearly 5x faster. Covering the whole estate becomes more practical.
• Current context across active branches. Unchanged structure does not need to be recomputed, so keeping context fresh across active branches runs at about half the previous cost.
• Bring your own model. The new stack is much less LLM-intensive and less sensitive to model choice. You can run the transpiler on your own vendor account and your own models with predictable spend and consistent results.
• Better guidance for any agent. At every level, pre-computed connectivity directs an agent toward relevant code, including connections it did not know it was missing. That guidance supports a frontier model, a smaller model, or a person throughout their work.
• An addition to your existing tools. Driver is a read-only context layer delivered through MCP. It sits underneath Cursor, Claude Code, Codex, internal agents, and CI, alongside your existing search, rules, and tools. Nothing has to be replaced to evaluate it.

What adoption looks like

Connect your software estate, or a subset of codebases, to Driver through one of our version control integrations. Driver performs an initial compilation of each codebase and continuously keeps every configured branch up to date as it evolves.

Then use Driver anywhere MCP is supported. The people and agents querying Driver do not need to clone repositories locally or keep them on the right branch. Bring-your-own-model is available now for teams that want transpiler spend on their own account.

What’s next

The same machinery that rolls a codebase up to an Atlas index can roll an estate up to one index. Inside a codebase, an agent asks, “Where do I look?” Across hundreds of repositories, the earlier question is, “Which codebases are relevant at all?”

Building on these new context foundations, we’re continuing to improve the capabilities of AI agents that need to understand and work on top of your software.

For the full technical story, including the mechanisms, the tradeoffs, and what we’re still working on, read the deep dive: Cheaper, Faster, Better: How We Rebuilt Driver’s Transpiler.

Ready to connect your first codebase? Get started with Driver.