There will be no god model

Why the future of AI belongs to many startups, not a single lab.

A lot of advice for AI startups is being repeated as if it were a set of rules: “own your intelligence,” “move to open weights,” “proprietary data is your moat.” There’s truth in all of them. But they become far less useful when they harden into prescriptions, especially for a startup that’s trying to go from zero to one.

At the same time, the story from the model labs keeps getting more maximalist. Anthropic is reportedly preparing to tell public-market investors that its TAM exceeds $30T. To put that in perspective, the entire U.S. economy produces roughly $33T per year.

In an IPO, your TAM is your story. It signals to the market the future you think your company can grow into. The future a $30T TAM forecasts is winner-take-all: the “god model” thesis taken to its logical conclusion. One general-purpose model gets good enough that it eats all knowledge work and, with it, the entire application layer. Anthropic becomes the last private company in human history.

I firmly believe this future is false. Set aside antitrust and whether such a model can be built in the first place. Everything right now points the other way: model leads measured in months, open weights closing the gap, and token prices falling fast.

When intelligence is your hammer, everything looks like a nail. But life is not an IQ test, and neither is the economy. The real world is full of friction. Intelligence matters enormously, but so do context, judgment, trust, incentives, taste, relationships, and the idiosyncratic choices people and companies make every day.

Even where intelligence is the bottleneck, diffusion is hard. Models are already improving faster than businesses can reorganize around what those models can do. Closing the gap runs through workflow redesign, incentives, regulation, and culture. Those points of friction are the application layer’s opportunity, and it’s anything but general-purpose.

With that in mind, here are a few pieces of advice I’d give to app builders today.

Focus on building the best product. Intelligence is just one input.

Customers are not buying model weights. They’re buying a product that gets a job done 10-100x better. Intelligence is an extraordinary input to build with, but unless you are a model lab, it’s not the product itself.

Every startup begins with an opinion. The best opinions are sharp and specific. You start narrow, where your understanding runs deepest, and expand as the product earns you the right to.

The same intelligence can support very different products. Coding is a good example: a product built around the IDE (Cursor) can make different choices from one built around the terminal (Claude Code) or a cloud development environment (Replit). What distinguishes them are the opinions behind each: about how developers should work, what the product should own, and what it should rent. The model is one source of differentiation; the product is the set of choices a company makes around it.

Over time, those choices can extend into the intelligence itself. While the labs chase AGI, startups can chase what Jonathan, founder and CEO of our portfolio company Turing, calls “artificial narrow intelligence.” While a lab needs to preserve capability across a wide range of tasks, an app company can optimize intelligence around the particular job it cares most about.

At zero to one, optimize for your rate of learning.

Once you’ve formed an opinion, the loop that follows is the one zero-to-one startups have always run: opinion → product → use → learning → a sharper opinion.

At this stage, you’re searching for what’s true about the problem: which parts of your initial thesis survive contact with the customer, where the workflow is different from what you assumed, and what the product needs to do before somebody will rely on it.

Every early-stage founder still faces the old chicken-and-egg problem. You need to understand the workflow before you can build the right product, but customers generally will not let you deeply into that workflow until you have something useful enough to earn their time. That’s why the wedge matters. A good wedge gets you close enough to one important piece of work that you can stop reasoning about the customer from the outside and start seeing the problem for yourself.

Once you have your opening, you need to go “guns blazing,” as Jonathan puts it. If the strongest frontier model gets you into an important customer three months sooner, use it. I’d rather see a seed company overspend on tokens and get another 1,000 real workflows than optimize an inference stack for a product customers are lukewarm about.

The teams that worry me are the ones running this logic in reverse. They’re extremely sophisticated about technical decisions they don’t yet have enough information to make: which model they intend to post-train, how they’ll serve it, what the economics should look like at scale. They’re less certain why their first 10 customers will care. They’re answering questions the product has not yet earned the right to ask.

Before you worry about moats, you need to build something worth defending. Early-stage founders should spend less time trying to name the moat at the beginning and more time creating the conditions to discover one. Running fast learning loops is what gives you the information to find out.

Be flexible about where your intelligence comes from.

Jonathan has another framing I like: be “Switzerland.”

For each part of the workflow, use whatever does the job best. That may be the strongest closed model available, a smaller open model, something you have adapted yourself, or ordinary software.

I would think about open weights the same way. They can buy you lower cost, lower latency, more deployment flexibility, or the ability to customize something important. Those can be excellent reasons to use them. “We should own more of the stack” is not, by itself, a good reason.

Jeff Bezos made a version of this point nearly 20 years ago with the story of a brewery that once had to generate its own electricity because there was no grid. Power was necessary to make the beer, but generating it did not make the beer taste better. Once somebody else could supply the undifferentiated infrastructure, the brewery was better off spending its attention on the thing customers actually cared about.

I think that’s still the right test. Does moving down the AI stack make your core product (“your beer”) better? If an open model makes the product dramatically faster, solves a real deployment constraint, or enables a workflow the API cannot, go deeper. If it mostly makes the architecture look more sophisticated, I’d much rather spend those engineering hours understanding the customer.

“Proprietary data” matters when it gives you a proprietary way to get better.

I see some version of the same flywheel in a lot of vertical AI pitches: “we enter the workflow, collect proprietary data, improve the system, win more customers, collect more data.” That can absolutely work. But not all proprietary data compounds in the same way.

The core thing to understand is what being inside the workflow allows you to learn. You can own that learning while continuing to rent the underlying intelligence.

Cursor is a great example. At enormous scale, it can observe whether users accept or reject suggestions and whether the code its agents generate survives in the codebase. Some of those signals feed back into training its own models. But they also teach Cursor how to get more out of the models it already has: improving the context and tools available to an agent, tuning the harness around different models, or learning which model is best suited to a particular task. Product use teaches Cursor both how to build better intelligence and how to make better use of intelligence it rents.

Many vertical AI companies will have less tidy loops. Sometimes the customer data itself can be reused. Sometimes it can’t leave the customer’s environment, but you can still learn something general about the work: what good looks like, where the difficult cases are, and how performance should be judged.

Post-PMF, scale widens what’s worth owning.

Scale changes the calculation. A specialized model for a task that happens a thousand times may make no sense. Run that task millions of times and a modest improvement in cost, latency, or quality can become extremely valuable. This is where questions that were premature at seed around how much intelligence to own, where to run it, and how much to customize can become genuinely strategic.

Jonathan’s idea of the marginal return to intelligence is useful here. Some parts of a product deserve the strongest reasoning money can buy because a few additional points of quality have enormous economic value. Elsewhere, the model may already be good enough and the customer would much rather have a faster, cheaper answer. At scale, you finally have enough evidence to know which kind of problem you are looking at.

Summing up

A lot of what I’d tell a seed-stage founder today is what I would have told them before ChatGPT: have a strong opinion about the product, get it into real use as quickly as possible, and learn as fast as you can.

You’ll rarely know in advance which decisions become durable IP and which turn out to be temporary scaffolding, and you don’t need to. The point is to build a product that keeps teaching you where more ownership creates value, and to go deeper when the evidence supports it.

The labs have an incentive to continue telling the god-model story because their capital requirements demand it. But the market for intelligence is not the same thing as the amount of economic value one company will capture. Anthropic can assert that AI touches $30T of work without it following that those trillions all accrue to Anthropic.

Founders are building toward a different future: not a single intelligence that swallows everything, but thousands of products that turn intelligence into work done exceptionally well. My bet is on that future.