Cheaper, Faster, Better: How We Rebuilt Driver's Transpiler

We’re rolling out a new version of our transpiler, the context compiler technology at the heart of Driver’s products. 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.

These are big changes to how both we and our customers think about onboarding a software estate with Driver. But beyond cheaper and faster, the new transpiler’s content also drives better performance for agents.

In my medical imaging past, saying you could improve signal-to-noise ratio (SNR) and resolution at the same time would raise eyebrows. You typically needed to take advantage of new physics or some other significant change of state to make that possible. Similarly, making our transpiler cheaper and faster and higher quality required major architectural changes.

In this post I’ll go into the what, the why, and the how of the rebuild.

The Same Vision, with Better Building Blocks

Pre-computing context with a compiler-like architecture is still our core guiding vision for accurate and efficient context management at arbitrary scale. We now have a better implementation of that vision. Pre-computing allows us to understand codebases of any size then choose how to project that understanding into the right concrete structure at different altitudes so that agents working at runtime can’t miss important context. This leads to a strong sense of joint optimization between what the compiler should compile and how the runtime (the API shape and the agent’s behavior) should traverse it. Earlier this year we wrote about “progressive refinement” as an important runtime paradigm in Compiling Context, Delivering Signal. We feel the same way today, but we’ve learned a lot about how to realize it better since then.

The oldest parts of our transpiler were originally built with technical documentation for humans as the primary use case (agents didn’t exist yet!). Even as agents came online and became our primary user, their capabilities and limitations (initially small context windows and little or no effective tool use) were very different from what they are today. In this formative milieu, the old transpiler was built around exhaustive per-file documentation modeled on traditional symbol-based tech docs, lightweight folder documentation, and a small set of codebase-wide guides built with a secondary engine, all shaped to support a progressive refinement flow. It did its job for the moment it was built in, and customers got a lot of value out of it.

But the needs of customers and agentic users outgrew this approach. Agents became significantly more capable, able to wield sophisticated tools, and with much larger context windows. The larger windows entirely removed old constraints around token limitations (though those have since re-emerged as a token-efficiency cost concern). There was a brief period when agents fell almost comically flat on large codebases, but in-house and ad hoc solutions got good enough, quickly, to close the most egregious gaps. Focusing on articulation, recapitulation, and summarization of local information, such as the contents of a file, stopped being valuable, and failure modes shifted to larger-scale problems of access and navigation. As the industry seeks to automate fleets and software factories, this remains the challenge. At the same time there has been a significant shift in expectations to quantify, justify, and control the cost of AI systems. The era of unmitigated tokenmaxxing was colorful but brief. Driver’s cost basis with the older transpiler was relatively high, with an intensive LLM-upon-LLM structure. That is too much friction for customers today.

With this in mind, we embarked on internal research and experimentation into agentic failure modes and into what makes context valuable to an agent. We learned three things, and a fourth that runs through all of them:

1. The scarce content is what is connected to here, at every granularity. An agent being blind to code that matters for a task is always a potentially catastrophic problem.
2. Effective aggregation and higher-level semantic understanding are not easily built from large quantities of lower-level prose. Structure both survives and enables effective aggregation.
3. Navigation is the bottleneck, not reading, and the first thing an agent reads (and the earlier elements of a trajectory more broadly) shapes everything after it.
4. In communicating content to an agentic system, it is important to acknowledge potential incompleteness. More broadly, framing matters a lot, not just content, in shaping downstream behavior and outcomes.

We needed a fundamentally different compilation model that targets these needs at a much lower cost. As we’ll see, the first three learnings each became a layer of the new compiler, and the fourth became a discipline that every layer follows.

Building for Agents, Our Primary User

With all that we’ve learned in three years building the transpiler and our recent deep dives studying failure modes for agents with context, we can better answer the question at the center of the rebuild: what should a compiler of codebase context actually compile?

Who consumes codebase understanding today? Agents, with increasingly capable underlying models and tool use, increasingly deployed as autonomous elements. What do they need? Navigational aids, an understanding of disparate relationships, and guarantees of both efficiency (tokens) and exhaustiveness (not missing key context). Not local restatements or summaries of code. And how can we better deliver that? Instead of LLM prose, build structured claims, created deterministically by clear algorithms that target relationships (syntax trees, grep, git co-change, and so on), and expose that information at different altitudes. In short: lean even harder into the compiler analogy.

As we’ll describe, pursuing this new understanding of what a context compiler should build led to synergies that produced the core cheaper and better result. Starting at the lowest-level foundations with more deterministic, structured context generation, plus a focus on relationships and dependencies, led to a real sum-greater-than-the-parts moment. This made leaf-node content more valuable for agents, but more importantly it finally made “rollup” effective. By rollup I mean the problem of building the right context at a submodule or subfolder level that has dozens, hundreds, or thousands of children. Cracking effective rollup has been one of the biggest unlocks toward a cohesive, altitude-crossing set of context and higher-level content that is not extremely expensive to build.

What Agents Don’t See Well

Agents don’t just struggle with scale. Yes, asking Claude Code to help you work on a 10 million line codebase with no context solution (or even steering markdown documents) will be problematic. Asking it to resolve support tickets that could involve any subset of 100 million lines across a 200-repository estate without a context solution won’t work. But even in much smaller settings there are important and catastrophic failure modes.

Serious engineering organizations have not left their agents with nothing, either. Most have added semantic search and embeddings, AST or symbol indexes, repository instructions like AGENTS.md, and often custom retrieval tools maintained by a platform team. These help, but they are often query-time mechanisms: each answers a question the agent already knew to ask. But how does it know what to ask? This is the age-old “don’t know what you don’t know” problem, and it is the structural limit we described in Compiling Context, Delivering Signal. Retrieval at query time cannot provide the guarantee that exhaustive compilation ahead of time can. The failures that remain in well-equipped organizations are exactly the ones a query cannot reach.

An important source of failure is what we call “dark connections”: important semantic connections between code that are invisible to an agent’s standard repertoire of reading files directly, using tools like grep, or even using language servers (LSPs).

Examples include:

• Connections between languages, such as a frontend in TypeScript and a backend in Python that depend on a shared status enum, with no import between them and no shared greppable tokens.
• Connections across serialization and data-model boundaries, again with nothing greppable in common.
• Registration chains that thread one change through several subtrees, where no single file, and no single edge, shows the whole chain.

These connections are real and critical when building on real code, but often invisible to an agent’s discovery mechanisms and tools. And even when a connection is discoverable in principle, traversal at scale becomes its own problem. If you build the most complete abstract syntax tree (AST) for a 10 million line codebase, hand it to an agent, and ask it to improve some obscure piece of functionality, how does the agent know where to start? A perfect graph no one can navigate is worth nothing.

Key Learnings and How They Map to the New Architecture

Now I’ll describe the major new compiler components we built. Then we’ll be in a good position to bring it all together at the systems level and see how an agent actually experiences the new context.

The Substrate

The work started with a total revamp of how we build the lowest-level, most granular context, which we’ll call the “substrate.” In the older transpiler we used parsing to identify and scope symbols deterministically and exhaustively, but that was immediately and directly fed into LLM-intensive symbol-level descriptions. This was both expensive and largely in the category of local recapitulation, albeit tidy, exhaustive, and structured.

In the new model we still start with symbol parsing, but it has been leveled up. We’ve long built custom symbol and (partial) AST parsers for target languages in a process we call language specialization. We spent a lot of time bringing that to the level of complete ASTs, building differently-shaped symbol tables that enable efficient access patterns for particular kinds of queries, and adding an internal query layer. We’ve started to expose that query layer directly as agentic primitive tools in our MCP, but that’s the subject of a different post.

The language specialization architecture targets a common internal representation, so that it can be queried and reasoned over regardless of language. We continue to improve and expand our approach to language specialization. Recent additions include:

• In applicable cases we build our own type inference for a given language.
• We explicitly target the mapping of enum variant (“sum” types) and struct member (“product” types) references, which can be critical and illuminating in understanding how data structure instances connect to the logic of a program.

This gives us an incredibly rich syntax tree capability, and since it’s built in house, we completely control its evolution and shape. But the symbol table is now only one lane among several deterministic computations used to construct a different kind of base unit of context.

Because the value is in navigation and connection, we settled on a single primitive: a relationship edge between two files in the codebase, carrying the symbols implicated on each side. References can be internal to a subtree or between files located anywhere in the codebase, and the symbol-grain graph from language specialization sits beneath it. Along with the qualified identifiers for the two sides, each edge stores metadata such as its provenance and whether more than one method found it. All of this is computed deterministically, without LLMs.

What do I mean by “provenance”? How the relationship was identified, and sophisticated syntax tree parsing is only one method. Others include exhaustive literal searches using tools like grep; value-set matching, where we identify distinct types whose variant values match exactly and are therefore semantically connected; and connections revealed by a high frequency of co-change across git commits. When two lanes independently find the same edge, we merge them into one record with the provenance union recorded on it, and the edge takes the stronger authority of the two. There are a number of other helpful deterministic things we can do to provide powerful metadata. For example, we weight field and variant threading by inverse corpus frequency, so that ubiquitous names like id and name down-weight themselves. Metadata like this bakes categorization and relative importance into the deterministic structure, to be wielded, queried, and filtered by secondary processing and by agents directly. We can even score a coupling for how “non-obvious” it is: the lanes that see what a parser can’t (value-set matches, co-change history) score highest, and the score rises with how far apart the two ends sit in the tree and whether they cross a language boundary. That is precisely the class of potential dark connection an agent cannot reliably find on its own. In general, provenance weighting is very useful for downstream processing.

In this manner, we exhaustively map over every leaf-node file in a codebase and compute these relationship records for each. This forms an exhaustive, granular, structured, and consistent core context that is fundamentally different from the earlier symbol-plus-description granular core. The high-volume edge creation is entirely non-LLM. At the file level, the only place a model writes anything onto an edge is the co-change verdict: after deterministic metrics select the file pairs that change together often enough to matter, a model judges each pair and writes a short note on why they are coupled. Proposing non-obvious couplings that the deterministic lanes missed, and narrating why a connection matters and when it must be considered, happen one altitude up, at the folder level, which we’ll come to next. Models discover, narrate, and enrich; the fundamental context components are constructed deterministically.

The Rollup

Tiny codebases are generally not a problem. One of the hardest issues in context engineering and agentic development is coping with sheer scale such as a monorepo with tens of millions of lines of code or hundreds of related and interacting microservices. From our compiler perspective, a critical technology need is to build context at different levels of abstraction. Whether organized by file tree, by language module, or purely from a systems-architecture point of view, right-sized and right-focused content at different levels is essential to solving the navigation problem through paradigms like progressive refinement.

Building effective semantic context automatically for any arbitrarily large codebase is challenging. One lesson we learned doing this in the past is that it is hopeless to do it well when built mostly on LLM prose. Climbing from files to folders by aggregating paragraphs of text, even when well scoped to the file tree and to exhaustively orthogonalized symbols, does not scale. It turns into prose aggregation and summarization, which is not the same thing as semantic rollup. For the latter, we need to understand and express larger, emergent structure and state the most important connectivity facts at the current altitude.

So what do we do differently now? First, our base is the typed relationship edges described above. At the folder level, the rollup starts as arithmetic rather than any kind of LLM string processing: a folder’s edges are the union of its children’s outgoing edges, and edges that resolve inside the folder become interior. This is deterministic, cheap, and lossless.

Then we have dedicated algorithms to provide the right narration at each folder level. For this we use a lowest-common-ancestor (LCA) algorithm alongside tightly constrained LLM narration. A cross-subtree coupling is an outgoing edge in both leaf folders and an interior edge at their LCA. That is, an edge is interior to exactly one folder: the first folder in the tree that can see both of its ends at once. This is computed deterministically, and it is where the edge is placed and narrated by an LLM, which gives a basic description and answers why does this coupling matter, and what must change with what.

Consider adding a new provider to a system. That is not one local edit. It threads through a registration chain across subtrees: a backend enum, a marker subclass whose literal must equal the enum value, a dispatch map and its reverse lookup, a route, and a frontend type that mirrors the backend with no import to enforce it. No single edge captures the chain, and no individual file can “see” it. But the folder at the chain’s LCA can, because it is the first layer that sees what nothing below it can. Driver’s new transpiler narrates it there as one coupling with one modification guide. In this way, making disparate cross-subtree couplings visible at higher altitudes simply falls out of the tree once edges are the first-class granular data, with no LLM reasoning needed to identify them.

On the cost side, most of the rollup is deterministic processing. The LLM narration needs no source code, and no child documentation either, only the rich coupling metadata from the connected edges and the underlying deterministic processing. That is a very small number of input tokens, and in one inference call it produces a structured output shaped like this:

folder_narration:
    summary:  <what this folder's structure couples together>
    coupling: <subtree A> <-> <subtree B>
    why:      <one sentence, citing only supplied paths>
    pattern:  <cross-subtree claim with >= 2 citations, or dropped; top-level folders only>

Every claim must cite something in its anchor set. Unanchored claims are regenerated once, then dropped. The narrated claims that survive are derivative but highly structured, terse, and located precisely where they matter in the codebase. This captures the whole redesign in miniature: deterministically establish the what, and spend a small, constrained amount of intelligence on the why.

What about large files, large codebases, and the enormous quantities of deterministically computed edges they produce, especially at folder rollup? We store data at full depth but control what is presented through tooling at each level, with callers able to pull deeper if they want. All of the scoring and weighting metadata makes it easy to construct an ordered, prioritized list, so the model narrates the most non-obvious couplings first. Our serving tools (the MCP tools, for example) return a truncated list of the heaviest, most-connected couplings by default, but everything cut at serve time is named and counted rather than silently dropped.

Furthermore, we progressively enable deeper assessment as we recurse toward the highest semantic altitudes, the root and other top-level folders of the codebase. When processing the root, we look beyond just its depth-one child folders and pull up the most salient couplings from deeper in the tree. This lets us build the right-shaped processing for an arbitrary codebase, in a way that is far superior to the older transpiler’s approaches.

This new approach really shines at scale. For extremely large codebases, this largely arithmetic processing works very well when recursing upward from leaf folders, through mid-level folders, and finally to the root. That is not the case for prose-aggregating algorithms, even when they have a lot of structure. Inherently and invariably, that turns into an exercise in summarization and compression in prose, which quickly becomes dangerously lossy and capricious. Even when important ideas survive, they may be muddled and incomplete, and arbitrary omissions of critical content cannot be handled systematically. That sets any derivative reasoning about systems-level architecture on very dangerous footing. Building from structured entities that can be composed arithmetically is a much better solution, and our focus on relationship edges with extremely terse narration provides exactly the information density needed for higher-altitude synthesis.

Finally, do we keep any prose at the file and folder levels beyond the narrated edges? Yes, and this is important. We still compute a few prose entities, like single-sentence and single-paragraph descriptions, for every file and folder in the codebase. These are relatively cheap to produce (bounded to a handful of inference calls per file or folder) and very useful, especially for the Atlas engine discussed below. In the broader space of knowledge-graph creation, we think it’s important to take advantage of the ability to generate new content during pre-computation, and not merely associate bits of source. So even though the new transpiler is significantly more deterministic and relationship-identifying in nature, it still makes judicious use of derivative, generative, narrative content throughout.

The Atlas

The final component of the new transpiler is what we call the Atlas engine. It is a critical one, and it was the final keystone put in place to replace the older system in full. It could only be built on the foundations of the new granular substrate and rollup content.

The Atlas engine replaces the older “AutoDocs” engine, which created two codebase-wide documents in the old transpiler: the architecture guide and the LLM onboarding guide. Documents like these are the capstone of the progressive refinement paradigm. An agent reads them to immediately get its bearings on where to go for details inside the codebase, whether that codebase is 10 million lines or 10 thousand. In the ideal, this provides a stabilizing and consistent ability for an agent to “not miss,” to know exactly where to go for relevant details next, and to efficiently understand the critical context for the task at hand regardless of codebase size or complexity. And because they are the first thing read, these documents have an outsized effect on the rest of the agent’s behavior and on the progressive refinement flow in general. In practice, though, having the same rigid interface for a 10 million line codebase and a 10 thousand line codebase is highly sub-optimal. The “consistent” documents necessarily sit at different levels of abstraction in the two cases, and there is no way to map them to the inherent complexity and shape of a sophisticated codebase.

Key differentiators of Atlas compared to AutoDocs, which we’ll cover in more detail:

• It is not tied to the file system organization.
• It is built on top of the new file and folder substrate rather than on its own exhaustive compilation pass.
• It is not a fixed, static set of documents; it produces an index and as many sub-documents as the codebase warrants.

So far we have still been tied to the file tree, the directed acyclic graph (DAG) of files and folders. Content organized along those lines is important. It is easy and natural, since the file tree is the organizing structure of source code today, and, importantly, agentic systems that take action do so concretely at the file level. But having only DAG-oriented context is a limitation. We have long wanted semantic, architectural, and systems descriptions that are not tied to the file tree per se. The older AutoDocs engine had limited ability to do this, and only in prose.

With the new substrate we felt confident we could go after content organization beyond the file tree. True to the theme, we did it with deterministic algorithms. In particular, we apply clustering over the relationship graph described above to build a systems-level semantic view of the whole codebase. Because the clustering is built over the edges and not over directories, it escapes the file tree by construction. Directory affinity is one weighted signal among many. Architecture that doesn’t match the folder layout finally becomes expressible.

Furthermore, we let the codebase’s size and complexity drive how that clustering reifies into a top-level index (always) and into sub-module-level architecture documents (which can themselves index more detailed sub-documents). The Atlas engine sizes itself: a small codebase collapses to one page, and a very large codebase recurses to a number of altitude levels that is a function of the codebase complexity. In the latter case, higher-level documents index the sub-documents structurally and exhaustively. Every source file lands in exactly one section, can appear in other sections’ halos of closely connected files, and every page reports its own coverage. Because the grouping is systems-level clustering rather than a directory listing, navigation by an agent in the progressive refinement paradigm is straightforward.

Unlike AutoDocs, the Atlas engine never runs an exhaustive pass over lower-level content. It reads what is already compiled and spends a couple of LLM calls per section. This is dramatically cheaper than AutoDocs, and it represents a long-desired ability to drive a coherent multi-pass compiler process efficiently end-to-end, building everything we need to serve a runtime progressive refinement paradigm.

In this way, we now have a top-level content engine that escapes the file system structure to express architecture, sizes its content to the size and complexity of the underlying codebase, and is created much more cheaply than the previous solution. Additionally, the new Atlas performs better at the critical function of providing initial guidance in progressive refinement flows and bringing an agent up to speed on the contents of a codebase in general.

How an Agent Experiences the New Transpiler

With the three layers described, we can now put them together from the agent’s side. The compiler builds bottom-up, but an agent reads top-down. Let’s drop an agent into a 10 million line codebase with a task and Driver’s MCP in hand and watch its trajectory, one altitude at a time. This flow is codified in request_context, our subagent-as-a-tool, but it can just as easily be assembled or modified from Driver’s primitive MCP tools as a user sees fit.

The flow starts with orientation using the Atlas. Before it navigates anywhere, an agent reads the top-level Atlas index: a thematic map of the codebase, clustered by what the code does rather than where it lives. Two or three sections stand out as relevant to the task. Alongside the index, it also reads the root-level connectivity narration: the top-of-tree summary of what couples to what across the major subtrees.

The agent then drills into each of the major relevant sections using more Atlas MCP tools. Here it sees the central files, the neighboring sections, and the coupling rules that cross the section’s boundary, with each rule stating where it came from and how confident we are in it.

It then fetches Driver’s connectivity information for a particular folder which provides important narration: if you change this here, that changes there, because, with the provenance of the coupling and, for the top-level folders, the most salient couplings pulled up from deeper in the tree. This is where the cross-subtree chain from the rollup section becomes visible as a single fact.

The agent then uses Driver to fetch the relationship substrate of the important leaf files: which files consume each of them, what they mirror in another language, and what historically changes alongside them. Each edge says what method found it, what that method is exhaustive over, and what it knowingly cannot see.

At this point the agent can read raw source with high precision. At the lowest level of investigation, it checks a symbol’s blast radius through Driver’s symbol-table tools, which query across every language in the codebase at once.

When this flow runs inside request_context, a final brief is assembled with framing tuned to agent behavior, telling the receiving agent to treat everything in it as candidates to verify and to look outward from them.

There is an important pattern in this progressive refinement. At every altitude, the pre-computed context pushes the agent back toward the relevant set of code. Whichever direction it started in, it is pulled toward what matters, including toward the things it had no way to know it was missing. That is the product of multi-altitude connectivity: it acts as a restoring force on any actor, LLM or human.

Why the Transpiler Got Cheaper and Better at Once

With all of this under our belts, we can be precise about how the new system is cheaper and better than the old stack.

Until this rebuild, we had been compiling the same understanding multiple times with heavy dependency on LLMs. The new transpiler stack was built up orthogonal to the old system until we could replace it in one fell swoop.

Three things make the result cheaper and better than the older system rather than cheaper and worse:

• The expensive thing was not the valuable thing. Most spend went to restating local source at the most granular level, and then doing it all over again in a second pass to create the guiding high-level documents. Removing both removed most of the cost and none of the value.
• Deterministic content is nearly free, more complete, and more rigorous. Relationship information is the right kind of information for large-scale context engineering, and it can be built from deterministic methods like language parsing, literal search, and version history. A parser doesn’t hallucinate a call edge, and a literal search cannot miss a literal. The result is much higher SNR, in a structure that makes higher-level semantic rollup with LLMs much better.
• Structure makes aggregation possible and cheap. Typed edges roll up arithmetically while prose has to be re-read and re-synthesized. This is why a folder can be narrated from a few hundred tokens of metadata, and why recursive semantic rollup to the top of the codebase is finally effective.

On top of these, we also gain content-addressing at every layer such that unchanged structure costs nothing. Across a chain of update commits, most steps require no Atlas model calls at all, because nothing the commits touched changed the input hashes of any Atlas section.

As for exhaustiveness and the amount of work, in one greenfield comparison on a single codebase, the count of processing tasks the transpiler ran barely moved across the switch: 6,355 before and 6,351 after. Exhaustiveness was never something we were going to give up. We do not do less work now; we shifted the kind of work we do toward what is more valuable and more deterministic.

Updates improved by about half rather than by the 90% of greenfield onboarding, primarily because with the connected edge graph even a single changed file can invalidate relationships that have to be recomputed back up through the subtrees it touches. Relationship-edge computation is now the largest single line in our update cost, and there is plenty we can do to further optimize here.

Perspectives and Takeaways

A few final thoughts on perspectives this work has highlighted and that we’re carrying forward.

A Bigger Notion of a Syntax Tree

Language specialization, our process of building language-specific compiler frontends, is a big part of the core deterministic processing of the new transpiler, but as we discussed, it is one of several lanes used to identify relationship edges. Where we’re taking this, internally and conceptually, is to unify all of these lanes into a broader, superset idea of the traditional syntax tree or symbol table. We’re working to fold the other sources into the same internal structure, so that dark connections are built into a unified symbol-level graph that can be queried and accessed with the same convenience and speed as a high-performance syntax tree or dependency graph. That is valuable for internal compiler activity and for the primitive tools we expose directly to agents and users.

Structure or Ad Hoc?

We’ve talked a lot about using determinism and structure in new ways to power the new transpiler, in contrast to more unstructured LLM processing loops inside the transpiler and, by extension, inside agent harnesses at runtime. Is there a bitter-lesson problem lurking here? Models improve relentlessly, so structure built today is scaffolding to be torn down tomorrow. If you squint, the first rendition of our transpiler can be read that way.

Over-constrained structure that doesn’t match runtime conditions is a real liability. But the ability of structure to preserve information as it ascends semantic altitudes seems foundationally important to us. Compared to unstructured prose manipulation, it provides an inherent composability and scaling that are strong foundations to build on indefinitely. So it feels less like structure versus flexibility and more like structured primitives used flexibly. We can be rigid where rigidity buys a guarantee, such as building on granular connectivity primitives and pre-computing navigational information at every level. And we can be flexible and loose in how agents access, assemble, and wield that information in runtime flows.

This is also why the restoring force we saw in the walkthrough matters. The industry is seeking more autonomy, with software factories doing as much as possible without human intervention. Autonomous actors are high-variance when applied to large, complex systems. Whether a frontier model, a cheap model, or a human, an individual actor acts on the information at hand, and at statistical scale will head the wrong way some of the time. If you want consistent outcomes from high-variance actors, you need constraints; that is core statistics and information theory. Exhaustive, pre-computed, multi-altitude connectivity is that constraint, applied as information rather than as rules: whichever way an actor starts, every altitude pulls it back toward the relevant set. That is how we can effectively start to build trust in automated agentic systems. As models get cheaper, better, and faster, they will wield our compiled systems that much better and faster, and the weaker the reasoning at the wheel, the more of the steering the context does.

Much as vision systems trade depth of field against focus, the practical need to move between strategic perspective and tactical code-editing in software development means that context which helps with that navigation is useful, regardless of how “intelligent” the actor is. We’re still working on the best way to pre-compute that kind of information, and we’re learning a lot every day.

Progressive Refinement Is Still Key

The walkthrough above is progressive refinement in its current form, and it’s important not to lose sight of the joint optimization between what a compiler produces, the shape in which it is exposed to a runtime environment, and how that runtime best uses it. We’re excited because the new transpiler improves the model at both ends: better fit-for-purpose top-level content (Atlas over AutoDocs) and the file substrate with folder-level rollup beneath it. Just as importantly, the cohesion of the new multi-pass system feels like a much stronger base from which to keep learning, and to fold those learnings into how we set up progressive refinement as everything, including model capabilities, keeps evolving.

What This Enables

We’re really excited about the new transpiler and what we’ve seen so far. As we roll it out across our customer base, we’ll continue to iterate and improve. Areas we’re actively working on:

BYOM Enablement Now

The much lower cost and latency to onboard matter a great deal for customers who want to bring their own model. Earlier this year we made the transpiler easily configurable against different sets of backing models, and customers can now choose to bring their own model to power Driver’s transpiler in their deployment. This gives them tight control over and visibility into transpiler spend, and lets them take advantage of their own vendor deals and unique models. The new stack is much less LLM-intensive, hence the cost and latency improvements, but it is also less LLM-sensitive, because so much of the work has been pushed into deterministic steps. BYOM deployments across very different model configurations should therefore perform consistently. We’re excited to explore this further with customers.

We’ll also be following up on the update side, which saw roughly 50% cost reductions out of the gate rather than the 90% of greenfield onboarding. As noted above, that is largely the need to back-propagate changes across the graph subtrees affected by even a small change.

Estate-Level Context Next

Today, customers get a lot of value from trivial access to every codebase they onboard to Driver, always up to date on every branch. Whether it’s an engineer working locally, a CI/CD agent, or support and product staff working in Claude Cowork, there is no need to clone repositories or keep them current and on the right branch. They can plug Driver into any agentic system that speaks MCP and have instant access to pre-compiled content for every codebase, without bringing the code local or managing codebase state and LLM access themselves.

We have many new use cases with customers beyond the core software engineering case, such as helping support teams resolve tickets faster, at higher volume, and more autonomously. In general, we see more and more use of Driver where the work depends on understanding the source but the user did not write the code or otherwise cannot or does not want to articulate where or how. They may not even have direct access at all. They need estate-level help.

This lines up well with a consequence of the new stack: we now have a coherent, affordable methodology for rolling up and pre-computing context at progressively higher levels of abstraction. All of this points to an obvious next step: pre-compute context at the level of the entire estate. Many customers have asked for this over time, and the new machinery is what makes it approachable. It is the same projection problem one level up, delivered by extending the Atlas engine and the codebase map one altitude higher. Inside a codebase, the agent asks “where do I look?” Across hundreds of repositories, there is a prior question it cannot even ask today: “which codebases are relevant at all?” An estate index answers that from what every codebase has already compiled.

We have a lot of work to do to prove this out at scale, but whether it’s powering codebase resolution for a support team or a product manager, or letting a CTO’s agent reason about a major migration across many hundreds of repositories, we’re excited about where this can go. Assuming an ideal, complete understanding of a codebase, the compiler’s job is to project that understanding into the forms and altitudes its consumers need: to the file, to the folder, to the codebase as a whole, and next to the estate.