Why We Started Driver AI

After I sold my second company, Aktive, to a Fortune 100 fitness and apparel company, I spent a few years in-house leading various software efforts for the innovation team. While I’d spent most of my career as an engineer and entrepreneur, I quickly came to understand what enterprise technology teams have been wrangling with for decades: complex codebases that are critical to the business but no one fully understands.

Anytime I heard the phrase “integrate with the enterprise,” I knew a project was in trouble. Because in order to integrate with the enterprise, we had to understand the enterprise. It didn’t matter if the codebase we were working with was a few months or a few decades old. The documentation was almost always outdated, the software had been developed over many years by a revolving door of engineers, and we couldn’t make heads or tails out of how to use individual libraries, applications, SDKs, APIs, etc., let alone master the entire applications landscape comprised of thousands of repositories on GitHub.

The No-Solve Solve

To “solve” this problem, we did what every other company was doing: We built or hired a team.

They’d spend months determining the existing capabilities of the codebase, how they’re implemented, and what the lift would be to accomplish our new goals. We’d spend hundreds of thousands of dollars and many months running these initiatives.

What we accomplished during discovery was a detailed project plan for how to spend more money and hire more developers who would work over many more months to deliver the real value. Projects were typically multi-year engagements. It didn’t matter if we were working on firmware, mobile SDKs to manage bluetooth peripherals, backend data infrastructure, cloud machine learning operations, or internal tools for operations.

It was maddening. The leaders and individual contributors were excellent to work with, but there was only so far any of us could take a project with that level of technical discovery. Looking for a solve, I spoke to enterprise leaders at other companies and very quickly came to understand this problem was everywhere.

Anyone who had to write about technology—whether it was documentation, project plans, architecture proposals, or answers to custom questions—felt handcuffed by codebases they didn’t know how to navigate or have the budget or time to sort through.

From Months to Minutes

Eventually I left, frustrated with the never-ending tech discovery cycle but having learned some incredible lessons about software delivery at scale. I joined a mid-stage startup as an individual contributor to reconnect with my desire to build hard and interesting technology.

In 2023, I was building a Python API for a piece of lab equipment that communicated over TCP/IP. It was a great piece of equipment, but the API was tedious, the documentation was mediocre, and the example code was written in Matlab. Here I was again, but this time at a startup company without all the overhead (and resources) of a Fortune 100.

I was ready to grit my teeth and power through another long and time-consuming discovery process. Except ChatGPT 3.5 had just been released.

We were fast friends.

I used a notebook to craft lengthy prompts by organizing relevant excerpts from the documentation and example Matlab code and asking ChatGPT to draft example Python code. I was pretty shocked at how well it worked. The code provided did what I asked, but never exactly how I wanted.

The code was missing basic things like logging and error handling. It also didn’t have a broad enough context for good design (like not being able to abstract commonly used code into patterns). Rather than implementing the code it suggested, I used that code to articulate a design.

In the end, all of the output from ChatGPT ended up in a well-organized document that served as a design specification. From there, it took me a few days to write the Python API to fully enable remote control of the instrument (using GitHub Copilot, naturally). From months to a few days. Wow.

I shared this experience with Daniel, a napkin sketch for a product idea, and a bunch of literature on Large Language Models to illustrate how I wanted to go about building the product. He started prototyping Driver AI, and I got to work with Jimmy setting up a company. Driver AI was born.

Driver AI is the new way to write technical documents. It helps anyone in an organization write interactive documentation, fueled by LLMs, that explains millions of lines of code in minutes instead of months.

This helps teams very quickly understand complex codebases. It also significantly cuts down the discovery phase, so teams can rapidly accelerate delivery and reallocate critical resources to innovation.

Driver AI is the Solve

Driver AI has the concept of a workspace, where you can add code from codebases, PDFs for technical specifications and data sheets, links to resources or other documentation, and more. From this information, Driver automatically creates structured, interactive documentation for you.

This is critical, because not only does it provide you a navigable map to the resources, it also provides this navigable map to the LLM. Both of you can quickly find what you need when you need it.

Once you’re organized, you’ll want to accomplish something. I don’t know what exactly you’ll want to accomplish—create an onboarding plan for new developers? Get a deep explanation of a specific API?—and that’s why we made this step interactive.

To get started, you'll create a custom note from a prompt. It can be a question like, "What are all the error messages in this codebase?" or "Explain how to configure the flux capacitor on this DeLorean?" (assuming you have the source code for a time-traveling DeLorean uploaded).

The response is presented in a fully editable and interactive document. You can ask Driver to review source information, share code examples, provide additional details on a highlighted section, or try again.

Even better, Driver AI automatically stays in sync as the business evolves, so the technical discovery process only gets faster over time.

You can see what this looks like here:

As we’ve explored this problem, we’ve found that it’s a problem everywhere. Even small companies struggle with legacy (because as soon as code is shipped it becomes legacy).

The response to Driver AI is like nothing any of us have experienced before. An EVP at a leading Global Semiconductor Company recently called Driver AI, “a paradigm shift for managing our complex software delivery pipeline.”

We’re thrilled to finally be able to offer an easy solve for navigating complex codebases for companies of all sizes. We’re grateful to every company we get to partner with to free up more of your time and resources to do what you do best.

Any questions, email me at adam.tilton@driverai.com.