Vibecoding at Production Scale Is a Defaults Problem
The talk frames Lovable as a company shipping production software through vibecoding, where users describe what they want and a system builds it. Here is my read on what that frame really means. The interesting question is not how the model generates code. It is what happens in every gap the user did not specify, which turns out to be ninety percent of the surface area of a real app.
Three key takeaways
- Defaults are the actual product when the user is not an engineer. The choices of database, hosting, auth, and UI library determine whether the generated app survives contact with real traffic, far more than any line of model output.
- The blast radius of an agent edit is a load-bearing constraint. A small, scoped agent that touches three files beats a brilliant one that occasionally rewrites the whole repo, especially when the user cannot read a diff.
- The handoff to humans is a feature, not an exit. Generated codebases that another developer can pick up and extend are the actual product, even when the current user has no plans to hire one.
The user is not an engineer, which changes everything
Most AI coding tools are designed for engineers. The user reads stack traces, knows what a Git branch is, can recover from a botched migration. Lovable's audience does not have that toolkit, and that single fact reshapes every design decision underneath the product.
When an engineer hits an error, the right response is to surface the error clearly. When a non-engineer hits an error, the right response is to fix it without asking. The agent has to know not just what went wrong but what the user actually wanted in the first place, and resolve the gap silently. That is a much harder engineering problem, because it means the system has to carry intent forward across many turns of conversation and many states of the codebase.
If your team is building any tool for non-developers that touches code, this is the most useful lens. The user does not want to be educated. They want the thing to work. Every error message you write is a small failure, because the user should not have had to see it.
Defaults are where the product actually lives
Lovable's users do not pick a database. Lovable picks one for them. They do not pick a hosting provider, an auth flow, a styling system, or a deployment target. Each of these defaults is a quiet but enormous choice, and getting one wrong shows up in real failures: apps that cannot scale, login flows that lock users out, deployments that fail on production load.
The interesting product work is in choosing those defaults. Postgres or something simpler. Supabase or rolling auth. Server-rendered or static. The defaults have to be conservative enough to handle the long tail of cases the user did not imagine, and modern enough that the generated app does not feel like a 2018 stack.
This is the part of vibecoding that no demo captures. You see the prompt and the result, and you think the magic is in the generation. The magic is in the defaults, which were chosen by humans on the platform team and tested against thousands of real user projects until they stopped breaking.
If you build agent-driven products, the lesson transfers directly. Spend more time on defaults than you think you need to. Test them against the worst case the user could throw at you. Change them slowly, because every default change retrains user expectations across a population of apps you do not control.
The blast radius problem is the central engineering challenge
When a user says "fix this button," they mean fix the button. They do not mean rewrite the auth system because it happened to be nearby in the file tree. But naive agents do this all the time. They pull a chunk of context, decide something else looks wrong, and start refactoring. The user comes back to a broken app and no idea why.
This is the blast radius problem, and it is the central engineering challenge in any agent that edits real code. Lovable has to scope edits aggressively. The agent should know which files are in scope for the current task, which are not, and what happens if it strays. There needs to be a rollback path that is one click for the user, not a Git command. There needs to be a diff layer the user can understand, probably visual rather than textual.
The pattern that works is small agents with tight scope. A button-fixing agent does not need to read your database schema. A schema-changing agent does not need to touch the UI. Composing many small, predictable agents beats one large agent with permission to do anything, even when the large agent is more impressive in isolation.
This applies far beyond vibecoding platforms. Any agent that touches a real system has a blast radius. The engineering work is in making that radius small, predictable, and reversible.
The handoff to humans is the actual quality metric
Some projects on a platform like Lovable outgrow it. The user gets enough traction to hire a developer, or learns enough code themselves to take over. At that moment, the quality of the generated codebase becomes visible in a way it never was before. Is the structure something a human can understand? Are the abstractions reasonable? Can a new developer find where to add a feature without reading every file?
Most generated code fails this test. It works, but it is structured in a way that makes sense to the agent and not to a human. Folder structures are flat or weird. Naming is inconsistent. The same problem is solved three different ways in three different parts of the codebase, because the agent did not remember what it did last time.
A serious vibecoding platform has to optimize for the handoff even if users currently do not ask for it. The reason is simple. The users who succeed eventually need developers. The users who churn never needed them. If your platform is only loved by the users who churn, you have a problem.
This is a quiet quality bar that does not show up in any demo. It shows up six months after a successful app launch, when the user hires their first engineer and that engineer either says "this is fine" or "we need to rewrite all of this." Optimizing for the first answer is the actual game.
Internal use of the agent shapes the product
Lovable ships the platform with Claude Code or something close to it. That matters because the team is its own user. They feel the friction of every misstep the platform makes, because they hit the same misstep building the platform itself.
This is the underrated benefit of building agent products with agentic tooling. The development loop and the production loop reinforce each other. The team learns what works because they ship the way their users ship. The patterns that survive both contexts are the ones that go into the product. The patterns that only work for engineers stay internal.
If you build any agent product, the team should be using a similar agent to build it. Not the same agent, necessarily, but one with similar properties. The empathy gap between "I built this with my IDE" and "my users build with the agent I built" is too large to bridge any other way.
Support load is a system problem
When a non-engineer hits a problem they cannot describe, support becomes the most expensive part of the company. Lovable has to make the system self-diagnose, self-explain, and escalate cleanly to a human or a more capable model when it cannot resolve the issue. Otherwise the support team becomes the product.
The interesting design move is treating support as a tier of the agent system, not as a separate org. The agent should know when it is in trouble. It should escalate to a higher-context model. If that model also fails, it should escalate to a human, with a clear handoff that includes everything the human needs to take over.
This pattern shows up in any agent product at scale. The escalation ladder is a feature. Build it deliberately, or watch your support team grow faster than your engineering team.
What this means for the next wave
Lovable's position points at something larger. The audience for AI-assisted software is wider than the engineering team. It includes founders, designers, operators, and people in roles that did not exist five years ago. Building for that audience requires different muscles than building for engineers. The defaults matter more. The scope of agent action matters more. The handoff to humans matters more. The cost of one wrong default ripples across thousands of apps.
The teams that develop these muscles now will have a real advantage. The engineering audience is well-served and saturated. The non-engineering audience is barely served at all, and the value of serving them well is enormous. The next generation of platforms that look like Lovable will not compete on model quality. They will compete on the quality of every choice the user did not have to make.
That is the bar, and it is a high one. Make the right choice for the user, every time, in a thousand small ways. Then make the result legible enough that a human can take over when they need to. Everything else is detail.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: How Lovable vibecodes production software at scale at Code with Claude London 2026. https://youtu.be/mhW-XXnDFSU