I went back on Code Story this week. Noah Labhart and I first talked in Season 8, when I was building Weavy. This time the conversation was about something I've gotten pretty opinionated on over the past year: most AI coding tools are doing the job in the wrong order, and it's going to catch up with them. You can listen to the full episode on Apple Podcasts.
Here's the short version of the argument. Go listen to the episode for the parts I can't fit here.
The experiment that changed my mind
When I started building my own AI coding platform, I ran a deliberately awkward experiment. Instead of reaching for the newest, smartest model, I asked the opposite question. What if I used an older, cheaper one? Could I build something that held up using Claude 3.5 Haiku instead of whatever frontier model shipped that month?
The answer was almost. It got close. And getting close taught me more than shipping would have, because it exposed the thing nobody wants to say out loud.
Most AI builders are standing on the models like surfers waiting for the next wave. When a prompt-first tool gets noticeably better, it's usually because the underlying model got better, not because the tool did. That's a fragile place to build a company. You're renting your improvement curve from someone else, and you don't set the price.
Probabilistic tools doing a deterministic job
The deeper problem is a mismatch. AI is probabilistic. Coding needs to be deterministic.
Every time you prompt an LLM, you get slightly different output. Sometimes it works. Sometimes it's close but subtly wrong. That variance is fine for a first draft of an email. It's a real problem when you need to trust that the first app you build and the ten-thousandth app come out the same way, with the same structure, and the same guarantees.
So with Gainable I flipped the order. The LLM does the thinking early, where judgment is exactly what you want. It doesn't do the coding late, where you want none.
You feed Gaia your data, usually an Excel file, a CSV, or a connected source. Gaia reads it, figures out the domain, whether that's a CRM, a sales pipeline, or an inventory tracker, and proposes what the app should be. You say yes or no. It builds a data model from what it learned, designs the app around that model, and writes a contract: a precise specification of everything that needs to exist.
At that point the LLM's job is done. A compiler takes the contract and builds the application, the data models, the API endpoints, the views, and the widgets. Because the build is deterministic, the same contract produces the same app every time. The fuzzy work happens where fuzziness helps. The exact work happens where exactness is the whole point.
Free-range coding
I have a name for the other approach. Free-range coding.
When you throw a prompt at a general code generator, the model gets to make a thousand choices, and it will. It reaches for React because that's what it saw most in training. It adds a styling framework. It pulls in a dependency for a button. Each of those is a small decision, and the more decisions a model gets to make, the more chances it has to make a wrong one.
There's a second issue underneath that. LLMs are trained to be helpful, almost eager. They want to show you the interesting tool, the clever pattern, the impressive stack. That instinct is the opposite of what production software needs. Production software needs the boring, reliable choice made the same way every time.
Constraints aren't a limitation on the model. They're the product. Gainable pins the model down to good decisions early, then gets out of its way.
The token bill nobody's pricing in
Here's the part that made the conversation fun. Token prices today are heavily subsidized.
You can build a full application right now for pennies in tokens. At scale, that math doesn't hold. Frontier providers are effectively spending on inference to win market share, and that phase doesn't last forever. I think we're heading toward credit-based pricing replacing all-you-can-eat subscriptions for frontier models, and when that shift lands, a lot of AI products are going to discover their unit economics never worked.
Gainable was built token-efficient from the first day, because that constraint was baked into the architecture, not bolted on later. We use a smaller model for generation and a stronger one for validation, and most of the cost lives in a compiler that doesn't burn tokens at all. It doesn't need cheap tokens to make sense. That's a quieter advantage than a flashy demo, and I think it's a more durable one.
Where the moat lives
If everyone rents the same models, people reasonably ask where the defensibility is.
My answer is that the moat was never going to be the model. It's the compiler, the validators, the constraints, and the decision to put the LLM early in the pipeline instead of late. It's a system that runs reliably on cheaper, older models instead of one that needs the next release to survive. That's hard to copy, and it gets more valuable the more the models commoditize.
Listen to the episode
We got into more than I can put here, including deterministic app factories, why I think flat frontier-model subscriptions are on their way out, and what that means if you're building on AI right now.
If you build internal tools and you're tired of probabilistic output and the errors that come with it, the episode is worth your time. You can listen to the full conversation on Apple Podcasts, and if you want to see the approach instead of hear about it, try Gainable with a spreadsheet you already have.