How Lovable Vibecodes Production Software at Scale

1. Vibe coding at consumer scale is a different problem

Vibecoding a prototype is one thing. Running a platform where non-developers use AI to ship production software — software that real businesses depend on — is an entirely different engineering problem.

Lovable reached $400M ARR and more than 8 million users by solving that second, harder problem. The apps built on Lovable now serve more than 600 million monthly sessions. The person who built each of those apps is typically not a developer. They cannot inspect the generated code, cannot read a stack trace, and cannot fix a broken output by hand. When the AI makes a mistake, the user is stuck — and they have no fallback.

This is the core constraint that shapes everything about how Lovable is engineered. A developer-facing AI tool can produce code that’s 80% right; the developer fixes the remaining 20%. A consumer-facing AI tool must produce code that simply works, because the user has no way to participate in the remaining 20%.

Fabian Hedin, co-founder and CTO, built Lovable’s engineering systems around this constraint from the start. Every infrastructure decision — from how the platform selects and orchestrates Claude models to how it evaluates new model releases before deploying them — traces back to one requirement: the output must be reliable for people who cannot verify it themselves.

2. The agentic architecture: orchestrating Claude at every layer

Lovable is not a thin wrapper around a single Claude API call. Under the hood, it runs an agentic architecture with a main orchestrator agent that reasons about a user’s intent, breaks the work into tasks, and dispatches subagents to handle each task — matching each piece of work to the most capable model for that specific job.

This tiered approach exists because different tasks within a single build have different requirements. Planning and high-level reasoning benefit from Claude’s strongest models. Faster, more routine tasks — formatting, summarizing, checking for regressions — can be handled by smaller, quicker models without sacrificing quality. Using a heavyweight model for everything would be slower and more expensive; using a lightweight model for everything would produce worse output. The orchestration layer manages that tradeoff automatically.

The orchestrator also handles recovery. When a subagent produces an output that doesn’t meet quality thresholds, the orchestrator can retry with a different approach, escalate to a more capable model, or surface the issue to the user with a targeted question. This recovery loop is invisible to the user but critical to reliability: without it, a single bad model output would break the entire build.

3. The fleet-learning layer: catching mistakes at scale

A single model can produce a bug. An orchestrator with recovery logic can catch many of those bugs. But when you have millions of users generating tens of millions of builds, some failure patterns only become visible at fleet level — you see them not in individual sessions but in aggregate, across thousands of similar requests.

This is the problem the fleet-learning layer is designed to solve. Rather than treating each user session as independent, Lovable monitors outputs across the entire fleet, looking for systematic patterns in what goes wrong. A particular class of prompt might reliably produce broken authentication flows. A certain kind of component request might generate CSS that looks right in the preview but breaks in production. These patterns are invisible in any single session; they only emerge when you look at the fleet as a whole.

When the fleet-learning layer detects such a pattern, it doesn’t wait for users to report problems. The system identifies the failure class, characterizes what triggers it, and uses that information to improve how the orchestrator handles similar requests — either by adjusting the prompt strategy, routing to a different model, or flagging the output for additional validation. The loop closes before the mistake reaches most users.

This is one of the most important architectural differences between running AI for developers and running AI for consumers. A developer who hits a systematic model failure will probably work around it or report it. A non-technical user who hits the same failure will simply give up and churn. Fleet-level mistake detection is not a nice-to-have; at consumer scale, it’s what separates a platform people trust from one that frustrates and loses them.

4. The eval loop: gating every model upgrade

Lovable runs on Claude. That means every time Anthropic releases a new version of Claude — or Lovable considers adopting a different model configuration — Lovable has to answer a non-trivial question: is this new model actually better for our users, and specifically better in the ways our users care about?

The naive answer is to run standard benchmarks. The problem is that standard benchmarks don’t measure what matters for Lovable. They measure coding ability in the abstract; they don’t measure whether a healthcare startup’s patient intake form still works after a model upgrade, or whether the AI now one-shots a complex multi-step build that previously took thirty prompts to complete.

Lovable’s eval loop is built around their actual usage. The team maintains a suite of tasks drawn from real user sessions — representative builds that cover the range of what Lovable users create. When a new model is being considered, it runs through this suite. Outputs are evaluated against the existing model on metrics that map directly to user experience: does the app work on first load? Does the authentication flow succeed? Does the generated code deploy cleanly?

A new model must clear these gates before it’s deployed. This is how Lovable has been able to use each major Claude release as a meaningful step change. Claude Sonnet 3.5 enabled their first functional agentic systems. Claude Opus 4.5 delivered a step change in reliability on long-horizon tasks, unlocking a class of projects that weren’t previously possible. Each of those transitions was gated through the eval loop before users saw it.

5. What keeps improving: the feedback flywheel

Building the initial system — orchestrator, subagents, fleet learning, eval loop — is a one-time problem. Keeping it improving is an ongoing one. Lovable’s model for continuous improvement is a feedback flywheel that tightens the loop between what users do, what the system learns, and what future users experience.

The core mechanism: every session produces signals. Which prompts needed multiple retries? Which outputs did users discard and re-generate? Which builds never made it to deployment? Aggregated at fleet level, these signals reveal where the system is still falling short. The fleet-learning layer uses them to prioritize what to fix next — not by hunches or individual bug reports, but by systematic signal from real usage.

This flywheel compounds. Early improvements reduce the most common failure classes, which improves user retention, which grows the fleet, which generates more signal, which enables better prioritization of the next round of improvements. Platforms that instrument this loop carefully get better faster than platforms that rely on individual user feedback alone.

The eval suite participates in this loop too. When the fleet-learning layer identifies a new systematic failure class, Lovable adds a representative version to the eval suite. The next model upgrade must clear that case. The suite grows to cover more of the real failure landscape over time — the eval suite learns from what the fleet has seen.

6. Engineering lessons for AI-first teams

Lovable’s architecture encodes several engineering lessons that generalize beyond their specific platform.

Match model capability to task complexity. Using your strongest model for every task is wasteful; using your weakest model for critical reasoning produces worse output. The right architecture has a routing layer that allocates model capability where it matters.

Non-technical users require a different reliability bar. If developers are your users, partial reliability is acceptable because they have agency to fix problems. If non-technical users are your users, you cannot externalize the remaining unreliability to them. Every percentage point of failure rate falls entirely on the platform.

Fleet-level instrumentation is not optional at scale. You cannot reason about what’s going wrong across millions of sessions from individual logs. You need aggregated views: failure pattern detection, clustering similar error classes, and a feedback path from detected failures to system improvements.

Eval suites must reflect your actual usage. Generic benchmarks answer the wrong question. Build your evals from real production tasks, weight them by how frequently those tasks appear in real usage, and run every model upgrade through them before deployment.

The feedback flywheel is the strategic moat. Product quality that compounds over time — because each improvement produces more usage signal, which enables the next improvement — is harder to replicate than any individual technical advantage. Building the loop is what creates durable advantage.

Test: "auth flow generation"
Input: [the prompt or context that produced a working auth flow]
Expected: the generated code deploys and the login/logout cycle succeeds
Pass criteria: no 4xx/5xx on auth routes, session persists across page refresh

For each AI output, log:
- timestamp
- input prompt (or a hash of it)
- whether the user accepted the output or regenerated it
- whether the output made it to "done" (deployed, sent, published — whatever done means for your use case)

Ask yourself (or ask Claude with your logs as context):
- Which input categories have the highest regeneration rate?
- Are there common phrases or structures in the prompts that correlate with failures?
- Is the failure rate changing over time (model drift, prompt drift)?