Driver

Version control manages code. CI/CD manages deployment. Observability manages production. But, nothing manages context. That is the framing Adam laid out back in January in our most foundational piece on the category we are building. Context is the missing infrastructure layer of modern software development. Without it, development suffers from context collapse. The shorthand: Driver is to context what Git is to code. The post explains why context belongs in the same conversation as the other layers of the software stack, why retrieval at runtime is the wrong shape for it, and what compilation makes possible across the full software development lifecycle, not just coding. This piece is the strategic foundation under both of the conversations Driver is part of over the next few weeks. It describes how to cross the context chasm. Daniel is giving a talk at Boston Tech Week, co-hosted with Liberty Ventures, on the compiler-based architecture that makes context infrastructure real. For AI infra founders, investors, and engineering leaders. Tuesday, May 26 | 6:00 to 8:00 PM | Boston, MA RSVP: lnkd.in/dFDU29KG Adam is hosting a roundtable at NY Tech Week with engineering leaders from Optiver, ShipBob, and Lucanet on what is working and what is not when teams adopt agentic tools at production scale. Shipping Faster with AI: What's Working and What's Not Thursday, June 4, 4:00 to 7:00 PM | New York, NY RSVP: partiful.com/e/5K5c4eODrGPK… The post: driver.ai/blog/context-i… #AI #SoftwareDevelopment

"Search returns relevance. Compilation returns truth." This is the architectural bet we made at Driver. Daniel walks through exactly why in his latest piece: how a compiler frontend, atomic guiding documents, and a focused runtime step jointly solve the exhaustiveness vs. signal-to-noise problem that no RAG system can. If you've been curious about why Driver is built the way it is, this is the post: driver.ai/blog/compiling…

"Claude has no chance." That's the consultant leading a 10M-line Java ERP modernization describing what happens when you point coding agents at legacy code without pre-computed context. If you've pointed Claude Code or Cursor at a 5M+ line legacy codebase and watched it confidently produce the wrong thing, this is exactly why. Migrations are the highest-leverage use case for coding agents, and at the same time, the one where agents have the least context. The legacy system is the thing nobody fully understands which is why you're migrating in the first place. Years of stale docs, multiple implementations of the same pattern, and metaprogramming nobody documented all adds up to an archeological dig no one can wade through. But the agent has to understand all of it before it can safely change anything. RAG-style retrieval makes this worse, not better, unfortunately. Chunking source into text fragments throws away the structural information such as call graphs, dependency trees, cross-module contracts. These conditions are why an agent needs to reason about a real codebase. Otherwise, it's pattern-matching on snippets, not understanding. Here's what migrations actually need from context: • exhaustive coverage of the legacy code, not samples • automatic currency (legacy is still under active dev during the migration) • structural awareness, not text chunks • cross-repo visibility (monolith + new services + shared libs) Adam on what this looks like in practice, including a 12-week modernization that stalled at 9 months before context infrastructure was added: driver.ai/blog/ai-coding…

A real limitation in most code context tools, including ours until now, is single-branch coverage. Review, pre-merge debugging, and cross-branch work all suffer for it. To make agentic coding effective at enterprise scale, context must demonstrate exhaustive comprehension across multiple branches simultaneously. We've shipped multi-branch support. Our co-founder and CTO Daniel wrote up the data model, the Git-inspired snapshot approach, and the deduplication strategy that makes it work at scale. Read the full piece: driver.ai/blog/from-one-… #contextcompiler #contextcollapse

Most engineering teams putting AI coding agents in production walk the same path: Agents lose context as the codebase moves. A homegrown RAG layer hits a wall. Chunking source code for retrieval breaks the call graph. That's the path @OptiverGlobal walked before they got agentic coding working. @DriverAI CEO Adam Tilton sits down with Matt Nassr (VP Data Eng / AI, @OptiverGlobal) at @techweek_ on June 4 for "Shipping Faster with AI: What's Working and What's Not." Matt spent months on a RAG-based context layer before concluding the architecture was wrong. The fix: a compiler-based approach that pre-computes the codebase so context arrives complete. 90% less manual context burden. 5x more effective agents. Case study: driver.ai/blog/optiver-c… June 4, 4-7 PM, NYC RSVP: partiful.com/e/5K5c4eODrGPK… #NYTechWeek

Most agentic coding failures aren't model failures. They're context failures. An agent starts a task and reasons about the code it can see. But the context it actually needs (cross-service dependencies, shared state, the real call graph) isn't visible from where it's sitting. The output looks right. It isn't. @DriverAI CTO Daniel Hensley (@dw_hensley) is giving a technical talk on the fix at @techweek_ Boston: a compiler-based approach that pre-computes exhaustive, dependency-aware context ahead of time, so it arrives complete instead of being retrieved on demand. @OptiverGlobal cut manual context burden 90%, made AI coding agents 5x more effective, and deployed in under two weeks. Case study: driver.ai/blog/optiver-c… Tuesday, May 26 | 6-8 PM | Boston Co-hosted with Liberty Ventures. RSVP: partiful.com/e/CqAXMakyIu2A…

Highly distributed, multi-codebase systems have structural properties that current AI coding tools can't navigate. What we've found is that the multi-codebase problem is a context problem, and context problems are solvable if you treat them as compilation rather than search. 𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 We've been working with engineering teams that have many codebases totaling from 3 million to 40 million+ lines of code. A number of them run microservices architectures with hundreds of repos. A pattern we keep seeing: AI coding agents fall down significantly when a task crosses a service boundary. And when you're developing against a large microservices architecture, this is constant. Three challenges drive this. 𝗖𝗼-𝗹𝗼𝗰𝗮𝗹𝗶𝘁𝘆. In a microservices architecture, no developer has every relevant repo cloned and open, and often doesn't start a task knowing which repos are relevant. An agent inherits this limitation. It can only reason about what it can see, and in a distributed architecture, most of the relevant context is somewhere else. 𝗜𝗺𝗽𝗹𝗶𝗰𝗶𝘁 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀. In a monolith, dependencies are explicit via imports, function calls, class hierarchies, etc. and an agent can trace them. In a microservices architecture, the connection is often a URL string in a config file, or two services reading from the same database table without either one knowing about the other. These relationships are real and load-bearing, but invisible to tools that reason at the code level. 𝗡𝗼𝗻𝗹𝗶𝗻𝗲𝗮𝗿 𝗰𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆. A codebase with N symbols has N-squared potential relationships. Teams try to solve this by introducing context about the service layer into their repos, but it doesn't scale: documentation rapidly goes stale and RAG-based approaches chunk code into text fragments, destroying the structural relationships that matter most in distributed systems. Furthermore, identifying the structural connectedness through interfaces of isolated services requires its own derivative analysis. 𝗔 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲 𝗖𝗼𝗺𝗽𝗶𝗹𝗲𝗿 𝗶𝘀 𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹 Our approach at Driver starts with what Adam and I call our transpiler: a compiler-like architecture we built that begins by parsing code via static analysis and emits structured context instead of executable code. A core feature here is exhaustiveness. Symbol tables, dependency graphs, and syntax trees are all computed deterministically for every file and symbol in each codebase. This is the foundation, and it matters. It means every codebase we process is understood exhaustively, not sampled. For microservice architectures, and other intensively multi-codebase systems, we have observed that this exhaustive understanding of each individual codebase is absolutely necessary but not sufficient. The reason is that the connections between services don't live at the level of syntax analysis or even analysis of any kind of any one codebase. In a monolith, you can follow imports and function calls to trace a dependency. In a microservices architecture, the dependency might be an HTTP endpoint defined in one service and called via a string constant in another (a more difficult version of the "stringly-typed" problem). It might be a shared database table, a message queue topic, or an event schema that two services conform to independently. These relationships are invisible to any tool reasoning within a single repo, no matter how thoroughly it parses the code. To capture these, we needed to go further: later stages of the transpiler that synthesize across the parsed structure of individual codebases, and a runtime layer that can reason across all of them simultaneously. 𝗔 𝗨𝗻𝗶𝗳𝗶𝗲𝗱 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝘁𝗵𝗮𝘁 𝗨𝗻𝗹𝗼𝗰𝗸𝘀 𝗠𝘂𝗹𝘁𝗶-𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲 Two developments have unlocked multi-codebase context. 𝗛𝗶𝗴𝗵𝗲𝗿-𝗹𝗲𝘃𝗲𝗹 𝘀𝘆𝗻𝘁𝗵𝗲𝘀𝗶𝘀. Beyond symbol-level static analysis, later stages of our transpiler produce intermediate representations (IRs) at many different levels of abstraction. These culminate with what we call Deep Context Documents: atomic, codebase-wide documents that describe architecture, major components, how they interact, and (crucially) where to go for more detail. These are synthesized by exhaustive review of all the structured content from earlier transpiler stages. They capture the conceptual and architectural relationships that exist above the code level, including cross-cutting concerns, integration patterns, and service boundaries. For an agent, this solves the "don't know what you don't know" circular problem that is so challenging without exhaustive context. 𝗠𝘂𝗹𝘁𝗶-𝗰𝗼𝗱𝗲𝗯𝗮𝘀𝗲 𝗿𝘂𝗻𝘁𝗶𝗺𝗲 𝗽𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲𝘀. We built a runtime layer where an agent connects to Driver via a single MCP integration and can query context across every codebase in an organization. Via the primitive tools, all pre-computed artifacts are queryable per-codebase: architecture overviews, file-level documentation, code maps, changelogs, source files. We also provide a single deep context sub-agent tool. Under the hood, this runs a dedicated context agent with access to all pre-computed artifacts. When a task spans multiple services, the agent queries context from different codebases exactly the way it queries within one. It synthesizes everything into a single, high-signal response tailored to the task at hand and returned to the caller. The combination is what matters. The transpiler's static analysis gives you exhaustive per-codebase understanding. The higher-level synthesis captures cross-cutting relationships that don't live at the code level. The runtime makes all of it queryable across every codebase simultaneously, so the agent sees the full system, not just whatever repo it happens to be sitting in. No co-locality requirement, manual assembly, or re-deriving what was already known. 𝗪𝗵𝗮𝘁 𝗪𝗲'𝘃𝗲 𝗦𝗲𝗲𝗻 A customer had a bug where bookings were completing despite no payment records. The investigation spanned 4-5 services across order orchestration, admin, and payments. This bug had been investigated multiple times before and missed. One engineer used Driver to trace the issue iteratively: broad exploration first, then narrowing hypotheses, then precise constraints. Driver pinpointed the exact method where validation logic silently passed orders with zero payment records. Total hands-on time: about 30 minutes. As the engineer described it, instead of needing three people with intensive knowledge of different services, one person got 80% of the way there, then brought in specialists to confirm. Another team with 200+ microservices built a workflow on top of Driver that takes a single Jira ticket, identifies which repos are impacted, gathers context across all of them in parallel, and generates per-service subtasks with specific file paths, class names, and implementation patterns. The constraint before, as one of their engineers put it: "you've got to know which repos." With all repos accessible through a single integration, that constraint disappeared. Beyond debugging and ticket analysis, teams report that Driver changes the baseline for development in multi-codebase environments. Concerns that historically slowed work (unknown blast radius, missing context from adjacent services) are addressed by the same cross-codebase context layer. One large microservices team reported 2x average PR velocity team-wide after introducing Driver. 𝗧𝗵𝗲 𝗕𝗿𝗼𝗮𝗱𝗲𝗿 𝗣𝗼𝗶𝗻𝘁 A fundamental tradeoff of microservices has always been autonomy in exchange for complexity. Small, independent services are easy to deploy individually but hard to reason about collectively. AI coding tools struggle with this in the same ways developers do. This is a genuinely complex problem and the fact that tools today (for agents and humans) are often single- or few-codebase centric exacerbates this issue. This tension has significantly held us all back. What we've found is that this is a solvable problem if you approach it at the right level. Per-codebase exhaustive context compilation is the foundation, but the microservices unlock is at a higher layer: synthesized understanding that captures cross-service relationships, and a runtime that makes it all accessible through one integration. The agent sees the whole system and understands the connections relevant to a particular task. The more codebases you have, the more immediately this compounds. If your team is running a distributed architecture and your agents are struggling with cross-service work, the issue is probably not the agent. It's what the agent can see.

As a dev community, we keep making the same mistake.  We chase better models to fix our AI coding agents. It never works. Why? Agents don't fail because of the model. They fail because of missing context. Missing context = AI agents confidently failing. @OptiverGlobal had 120+ commits/day and millions of lines of code. RAG couldn't keep up. Driver gave their agents compiler-level context automatically, on every commit. When you focus on the right problems, the results are dramatic. 90% less manual context work. 5x more effective agents. <2 weeks to deploy. Full case study: driver.ai/blog/optiver-c…

In fast-moving codebases, small changes can quickly throw #AI coding agents off. With @driver_ai_ , we introduced a compiler-driven context layer that keeps agents accurate without the manual overhead. Read the case study: driver.ai/blog/optiver-c…

Why do AI coding agents fail on real codebases? Not for lack of intelligence. It’s lack of information. Here's what codebase context actually is and why it matters. Codebase context is the structured understanding of a software system: architecture, component relationships, design patterns, dependency chains, type hierarchies, history. A codebase with n symbols has n² potential relationships. Context captures that structure which code searches entirely miss. It's different from documentation. Docs are written for humans, by humans, and go stale with every release. Codebase context is computed from source code itself, kept in sync automatically, optimized for AI agents. The common workarounds are markdown files in the repo, grounding prompts, RAG pipelines. They help but don't scale. Markdown files get dated. RAG chunks code into text fragments and loses the structural relationships that matter most. The right approach is pre-computation. Analyze the codebase ahead of time. Build the syntax tree. Resolve every symbol. Trace call chains. Produce structured artifacts. Then serve exactly what the agent needs, all signal, no noise. This is the compiler approach to context. Codebase context IS infrastructure just like version control and CI/CD. Every team hits the context problem at scale. The teams that win treat it as an infrastructure, not a tool or process. → Full post: driver.ai/blog/what-is-c…

Thanks, @EPDTNEWS, for naming Driver one of the top startups of 2024: epdtonthenet.net/article/211905…

Come see us in Hall B4, Booth 245 at @electronicaFair next week! CEO @adamtilton, CTO Daniel Hensley, and several of our engineers will be at the booth to show you how Driver can help your teams understand complex codebases in minutes, write technical documentation significantly more quickly, and speed engineer onboarding by 2x. Happy travels and see you there!

Our #engineering team has been using Driver to dig into fun old codebases, like #Doom and #Apollo11, and made some cool discoveries. We'll share them here soon. In the meantime, first correct answer gets a Driver swag bag delivered to your door.

Our customers can understand complex technology within minutes and, on average, onboard #engineers 2x as fast and draft documentation 50% more quickly. DM us for a demo!

We’re closing out announcement week and a big turnout @embedded_USA. Thanks to everyone who helped make this week a success. We are onboarding quickly, so if you’re interested in learning more, send us a DM.

We’ve been working in stealth mode for a little over a year with several teams and enterprises. Here’s what our early adopters have to say about Driver’s impact to date.

Thanks @AllAboutCircuit . "When we talk to customers, we hear it takes anywhere from three to six months for an engineer to onboard onto a new piece of technology. And this doesn't just mean when they join the company. Every single new project is an onboarding, and engineers constantly have to learn how to use something new.” @adamtilton #IoT #embedded allaboutcircuits.com/news/driver-em…

Congrats to the Driver.ai (YC W24) team on the $8M seed! Driver's platform generates customer-facing technical support documentation 50% faster, freeing up half of engineers' workdays— enabling faster onboarding and product time-to-market. techcrunch.com/2024/10/08/dri…

Congrats to @adamtilton and the Driver team on today’s launch 🎉 Driver’s AI platform automates the creation of technical documentation to empower teams and accelerate product time-to-market. We’re thrilled to welcome Driver to GV! tcrn.ch/3zTdgkZ

Meet Driver, an AI-powered platform that instantly decodes technology and automates the creation of technical documents. We’re reducing the time it takes for teams to understand, document, and deliver technology, speeding up engineer onboarding and product time-to-market. ⏩