Building Production-Grade Apps Without the AI Roulette: Rickard Hansson's Deterministic Approach to AI Development

When Rickard Hansson first appeared on Code Story back in Season 8, he was building Weavy—collaboration infrastructure designed to make it ridiculously easy to embed rich features into any application. That product is still humming along, moving upmarket with enterprise clients and proving that there’s real value in solving the collaboration problem well.

But Rickard’s been thinking bigger. And after spending time experimenting with the wave of AI coding tools flooding the market, he realized something fundamental was broken about how everyone was approaching the problem.

The Problem Nobody’s Talking About

Here’s the thing about most AI builders today: they’re standing on the models like surfers waiting for the next wave. Lovable gets better? It’s because Claude got better. Replit ships an improvement? Model upgrade. The tools themselves aren’t actually improving—the underlying LLMs are, and everyone’s riding that coattail.

But that’s a fragile foundation to build on.

When Rickard started experimenting with building his own AI coding platform, he asked himself a radical question: What if I used an older, dumber model? Could he build something that worked as well as Lovable using Claude 3.5 Haiku instead of the latest frontier model?

He could. Almost.

But along the way, he discovered the real problem: AI is probabilistic, and coding needs to be deterministic.

Every time you prompt an LLM to do something, it generates different output. Sometimes it works. Sometimes it doesn’t. Sometimes it’s close but not quite right. That’s fine for creative tasks. It’s a nightmare for building production applications where you need to trust that the first app and the ten-thousandth app come out exactly the same way.

The Gainable Flip: Moving the LLM Earlier

This realization led to Gainable, and it’s a fundamentally different approach to the problem.

Instead of using the LLM to write code (the thing that needs to be deterministic), Gainable uses the LLM early in the pipeline to understand and analyze. You feed it data—typically Excel sheets or Google Sheets—and the LLM does the judgment calls. It analyzes the data, identifies the domain (CRM, sales pipeline, inventory, whatever), and makes suggestions about what kind of app you actually need.

You say yes or no to those suggestions. The LLM learns what you want. Then it creates a data model.

That data model gets passed to the next stage where the LLM designs the application—still not coding it, just designing it based on what it learned about your data.

Only then does the LLM create a contract—a specification in JSON format that defines exactly what needs to be built. And here’s the key: that contract is deterministic.

Once you have the contract, the LLM is done. A compiler takes over. It builds the entire application—data models, CRUD API endpoints, UI, widgets, everything—in 45 to 50 seconds. Zero errors. Every single time.

This is the architectural insight that separates Gainable from everything else: the LLM does the fuzzy thinking early, and a deterministic system handles the precise execution.

Why “Free-Range Coding” Is a Problem

Rickard coined a term that perfectly captures what’s wrong with current AI coding tools: “free-range coding.”

When you throw a prompt at Lovable or Replit, the LLM goes wild. It uses React because that’s what it knows best from training data. It adds Tailwind. It pulls in a thousand dependencies for a button. It makes a thousand choices because it can.

But here’s the thing: React was designed for teams of engineers working on different components. It’s not the best choice for a singular AI agent trying to understand and modify code. And the more choices the LLM can make, the more wrong choices it’s going to make.

LLMs are also designed to be helpful—almost to a fault. They want to show off, use the coolest tools, demonstrate their capabilities. That’s the opposite of what you need for reliable code generation. You need constraints. You need guardrails. You need the system to make the boring, reliable choice every single time.

Gainable constrains the LLM to make smart choices early and then gets out of the way.

The Uncomfortable Truth About Token Economics

Here’s where Rickard gets provocative: token prices are still heavily subsidized.

Think about it. You can build an entire application with Gainable for pennies in tokens. That doesn’t make economic sense at scale. The frontier model providers are essentially losing money on inference to gain market share and lock in users.

What happens when that ends? When token pricing normalizes? When you can’t sustain a business model based on subsidized AI?

Rickard sees the signals pointing toward credit-based pricing models replacing flat subscriptions for frontier models. The era of “unlimited API calls for $20/month” is ending. It has to.

And when that happens, a lot of today’s AI products are going to break. They’re built on the assumption of cheap tokens. They don’t have a real business model underneath.

Gainable, by contrast, is architected to be token-efficient from day one. It doesn’t need cheap tokens to work. That’s a competitive advantage that most people aren’t thinking about.

Building Moats in a Commoditized World

The natural follow-up question: if everyone’s renting the same models, where’s the moat?

Rickard’s answer is elegant. The moat isn’t in the model. The moat is in the compiler, the deterministic validators, the constraints, the architecture. It’s in understanding that the right place for the LLM in the pipeline is early—doing analysis and design—not late, trying to generate production code.

It’s in building a system that works reliably with cheaper, older models instead of needing to ride the wave of frontier model improvements.

That’s defensible. That’s hard to copy. That’s a real moat.

What’s Next

Gainable is live and ready for you to try. If you’re building internal tools and you’re tired of the AI roulette—the probabilistic output, the errors, the dependencies on the next model release—it’s worth exploring.

The vision here is clear: remove data and engineering from being the middle man. Let your team build the apps they need, when they need them, without waiting for AI vendors or engineers to catch up.

Want to hear more? Listen to the full episode with Rickard Hansson on Code Story to dive deeper into deterministic app factories, the future of token pricing, and why the Stability AI government shutdown might be a turning point for the entire AI industry. You’ll also get Rickard’s thoughts on why flat subscriptions for frontier models are done and what that means for your AI strategy.