Generators are All You Need

The Problem with Building on Existing Code

If you've been in development long enough, you know that one of the hardest parts of coding is building on top of existing code. I remember reading a statistic suggesting that starting a codebase from scratch is faster than building on an existing one. With AI, some of that has gotten better. But we also spend a lot of time forcing AI to work within the code we already have, and that comes with its own problems. If I were to make up a statistic myself, I'd probably say it's still faster to have an AI build something from scratch than to have it wrestle with an existing implementation.

The Open Source Dependency Trap

One place I keep running into this is with open source. I love open source. I've personally maintained one of the largest open source codebases on GitHub. But when you're using it inside a company, you can spend a surprising amount of time dealing with bugs, gaps in functionality, and dependencies that nobody has had time to maintain.

• People are often doing this work for free.
• It's not reasonable to expect them to deliver everything a company needs.
• Still, a lot of time gets spent trying to make those dependencies fit the codebase.

Generators: The Pain Point

Some of the most important tools we use are generators: things that generate OpenAPI documents, internal APIs, or the scaffolding we build the rest of the application on. At one point, I spent maybe a month trying to get code generators to work. I had an AI go through OpenAPI generators across every language, and every one we tried was missing something that prevented it from handling the full specification we needed.

Usually, you'd patch the dependency or vendor it and maintain your own copy. But I wanted to experiment, so I thought, why not have a coding agent build the generator?

The Hypothesis: Agents Build Generators Well

My hypothesis was pretty simple:

• Coding agents are good at problems where they can verify the result.
• Generators seem like a good fit for that.
• You have a specification and an expected output.
• You can define the behavior through a contract and check it with end-to-end tests.
• The agent has something concrete to work toward and a way to tell whether it's getting there.

The Result: One Hour Instead of One Month

It took me one hour to build the generator. I remember thinking, why did I spend a month trying to force all of this to work? That experience changed how I thought about where to use AI.

As these models get smarter - and I mean really smart, to the point where maybe they can even solve Navier-Stokes - I expect them to get very good at building things like compilers and generators. Even with what we have today, having an agent build a generator can be more efficient than writing and maintaining all the code it produces.

Converting to Generated Code

So we went on a bit of an escapade and converted a vast majority of our code to generated code. By that, I mean we had an AI build the generators, then used those generators to produce code from specifications. Kind of meta, but it works. It's been much easier to maintain.

The key advantages:

• Our generators contain less code than the code they produce, so we have less to work through when something needs to change.
• We change the generator, regenerate the code, and that change carries through the rest of the codebase.
• Having an AI repair the generator is often more efficient than having it work through all the handwritten code we'd otherwise need to maintain.

A Different Way of Working

This feels like a different way of working from asking an AI to vibe code an entire app, or having a human write the whole thing by hand. We're putting more of the work into the specifications and the generators, and we're using tests to check that the generated code does what we expect.

Based on my experience, I think a lot of coding could end up looking like this:

• Maintain a collection of generators and use them to produce the code we need.
• Define the contract and make sure tests cover it.
• Once we have a contract we can verify, give the agent a problem it can keep testing and refining.

There's still work in defining the contract and making sure our tests cover it. But once we have a contract we can verify, we give the agent a problem it can keep testing and refining.