Why we built Supermodel

When mathematicians get to know each other, one question they may ask is “do you think that math is invented or discovered?”

This will give the asker an insight into the process of the other mathematician.

If they say mathematics is invented, they are saying that we begin with a blank slate and make the rules up as we go along.

If they say that mathematics is discovered, they are saying that everything that can be known is already known, just not by us yet.

The question is a matter of opinion. Some will give a balanced reply like, “We discover math by inventing mathematical techniques”.

In software engineering, we could ask a similar question, “do you think that software is invented or discovered?”

Until recently, the same question was boring to ask software engineers. Every piece of software that was ever written was invented by a person.

That isn’t true anymore. There’s an alien living in your computer now, and it writes programs that didn’t exist before you asked for them.

So the question is suddenly interesting. Did you invent your product, or did you discover it?

A clever engineer might answer the way a clever mathematician does: I discovered my software by inventing new techniques. Fine. But that dodges the thing that actually matters. If our job now involves routinely finding fully-formed worlds on our computers, then our job also now involves understanding what we ship. You can’t be responsible for code you don’t understand. And to understand something, you have to model it.

That’s what we set out to do. We built Supermodel to make models of agent-written software, so that the humans and agents working on it can actually know what’s there.

The model has to come from the code, not the LLM

There’s an obvious shortcut: have the LLM write the program, then ask the LLM to explain it. This works on toy problems. It falls apart on real ones.

The reason is simple. Programs are deterministic. Every symbol means exactly one thing. Every call goes to exactly one place. LLMs are probabilistic. They guess, confidently, based on what similar code usually looks like. A good guess about a real system is still a guess. When the system gets big enough, the guesses compound and the explanation drifts from the code.

If you want a source of truth about a program, you can’t ask something that hallucinates. You have to read the program itself.

At the logical level, every program is a graph. Symbols relate to each other in a parse tree. Functions call each other in a call graph. Modules depend on each other in a dependency graph. These aren’t metaphors; they’re the actual structure the compiler sees. A codegraph is all of them together, filtered and labeled so a human or an agent can reason about the system without drowning in it.

Engineers have always had codegraphs in their heads. The point of pride used to be keeping the whole thing up there. That works when you’re alone. It breaks the moment you need to collaborate, which is why onboarding a new engineer to a mature codebase takes months.

You are now collaborating with an alien every day. The onboarding problem is no longer monthly. It’s every context window.

Why agents need this too

You might reasonably ask: if the agent can write code without a graph model, why does it need one to work on code that’s already been written?

Because writing from scratch and modifying an existing system are different problems. When an agent generates a new function, probabilistic reasoning is an asset. The agent is drawing on everything it’s seen. When an agent edits a real codebase, probabilistic reasoning is a liability. It needs to know, not guess, where a symbol is defined, what calls it, what breaks if it changes. Guessing at the structure of code that already exists is how agents produce confident, plausible, wrong patches.

An agent grounded in a real codegraph stops guessing about the parts it can look up. We bet that software writers (human or computer) will always need models, and that the correct type of model for software is a graph, and the correct graph model is the one that we have created. We believe that graph models are infrastructure.

Try it

Our goal is to model any program in any language.

We’ve distilled our effort into this cli tool:

npm install -g @supermodeltools/cli

Go to your project and run:

supermodel watch

You’ll get a live graph model of your code that you or your agent can query. More at supermodeltools.com.