17 Edits, Then 3 Prompts: Lovable Builds the Same App Twice

Nathan Labenz welcomes Anton Osika, founder of Lovable, and Isaak Sundeman, an AI engineer at the Stockholm company, for a hands-on episode of The Cognitive Revolution. Lovable markets itself as a superhuman full-stack engineer: show up, describe the software you want in natural language, and let the system try to build it. Labenz wants something harder than the usual interview. He and Osika will talk about product philosophy and the future of human coding, while Isaak, partly in the background, actually ships an app on the live feed.

The assignment is a product-comparison tool with a little dynamism in it. Paste a couple of links, and the app should not only fill a table but decide what comparison even makes sense for that kind of product. Labenz's washer has just broken. His wife is bouncing between Wirecutter and Consumer Reports, and the real pain is upstream of any spec sheet: he does not know which dimensions matter. Front loader versus top loader was not a question he had considered at all until he educated himself enough to see it.

If the AI were really serving him, it would flag the things people find important about a category he has never shopped, then populate those dimensions. Isaak wants to start painfully simple: get some URLs into the system, hook them to a model, and iterate. He floats a search API that could look products up automatically, then they constrain the first version as much as possible. The user will paste a few product URLs and compare those, not wander into an open-ended shopping assistant on day one.

Isaak types the first prompt in the open: create a product comparison tool, stand up the UI, let the user drop product URLs into input fields. Labenz asks for an Analyze button. Isaak is already thinking about scraping the pages and calling a model, and Osika slows him down—start with a really nice UI; hook GPT later. The prompt on screen has a few typos. Osika is unbothered. The model understands imperfect spelling perfectly well. What actually moves the outcome is formatting and sequencing: what you ask, in what order, and how specific you are once an app already exists and you want to change it.

The system first writes a plan, including the design, then generates what they consider web-app best practice. Most software today is a web application, Osika notes, so the output is React. Within about a minute there are URL fields and a compare control. Because they are in Sweden, Google hands back local washing-machine listings. Clicking Compare does nothing, which is the point: there is no backend yet. The Analyze feature is coming, and the product even surfaces a little heads-up to that effect.

Backend arrives when you need external data or AI features. Lovable's path is a one-click hookup to Supabase, the backend-as-a-service they treat as covering database and authentication. Isaak logs in while Labenz and Osika zoom out. The low-level work and the big-picture conversation are now running on the same clock, which is the format Labenz wanted: a two-track experience in which every architectural claim can be checked against a half-built app.

Asked for the medium-term future of software, Osika goes back to childhood. He started coding young, making computer games, and he still talks about that skill as a superpower: a way to understand the world, communicate about technology, and make things come into existence. Much less than 1% of the world's population has it. With AI, he argues, the other 99% will be empowered to create, solve problems with software, and edit and improve the tools they use. Everyone will be able to run a version customized for them. Because AI writes code much faster than humans, he expects a Cambrian explosion of high-quality software and a much larger unleashing of human creativity. How that hits the current software workforce is more complex. The obvious change, in his eyes, is the superpower spreading.

Labenz pushes on the example itself. If models keep improving, will there be a dedicated comparison UI at all? He has been hearing the generative-UI story: no more software, just a general interface to AI. Osika is confident that is not the whole answer, for a simple human reason. People prefer things that are predictable and the same, and they prefer products whose UX has been tested by many other humans. An interface regenerated from scratch every time would be different for you and for your grandmother. You could not teach anyone how the software works. He expects people to keep using the same software with the same UX most of the time, the way they build muscle memory for Slack or an email client.

Nailing that UX, he adds, takes so many iterations of making a product lovable that they named the company after the problem. AI should speed those iterations, not erase the destination. There will be far more generated components, pulling the right context for the task at hand, nested inside software that still has a stable shape. Labenz agrees for power tools like Gmail. He still holds a competing picture from abundance: how does Elon Musk buy a washing machine today? Someone on the team handles it end to end, or it never reaches him. A future user might just say the washer broke, ask for two good options, and never touch a comparison table.

Osika grants the endgame more than the transition. The only important transfer, he says, is what the human wants in this moment, and the information that comes back. Over time, AIs are going to read our minds, or at least become extremely good at predicting what we want in a given situation. Then you will not need a screen that asks whether you care about front-loading. He is not saying that future will not arrive. He is saying standardized UI will last longer than the generative-UI slogan implies, even as the middle of the journey—the dimensions you never knew to ask about—starts to disappear.

Labenz's recurring pain with coding tools is not the first UI. It is DevOps: a missing dependency, a build that will not finish, a port-forwarding mess, something that looks right locally and will not sit on the public internet. Osika's theory is blunt. Software engineering gets hard when different things have to connect. The more components you wire together, the more error-prone the system becomes, exponentially. Lovable's response is to cut the menu. If you need a backend and a database, you use Supabase. If you add payments, there is a clear happy path: the product generates a button, you go set up Stripe, you paste the key, and the payment flow is almost guaranteed to work.

A less opinionated tool, even an excellent one like Cursor, will sometimes generate pieces of software that have not been fine-tuned to work together. Somewhere downstream you hit a problem the model has a hard time recovering from. Labenz sees a Schelling-point effect already forming in codegen land: Tailwind CSS as the default for styling, Stripe as the default for payments. Osika agrees. Human developers had already converged on Tailwind. Large language models accelerate that convergence twice. A person who does not know Tailwind can take months to learn it; a model just emits working code. And models are better at the popular choices because that is where the training data is densest.

He does not treat today's defaults as permanent. Tailwind may not be the last word on styling; Facebook had recently shipped something that could catch on. If a better pattern gets adoption, he expects AI tools to switch overnight to the new Schelling point. The moat, in this telling, is not an eternal list of vendors. It is the willingness to keep the graph of moving parts small enough that a non-coder can finish the job.

Cursor gives developers a dropdown. Lovable does not tell users which model is running. Osika says that historically they have switched overnight after a new model comes out: they try it, decide it is better, and cut over. They do not use a single LLM. They do smart routing across Gemini, OpenAI, and Anthropic, and he imagines DeepSeek joining soon. Labenz adds that nobody should sleep on Kimi. Internally they have an admin selector so the team can experiment. That is not, in Osika's view, the right interface for customers. If you offer a choice to someone who lacks the full context, they are more likely to pick wrong.

The design they want to roll out is a default to the fastest chain of models. If that fails, the UI should show the failure and give the user some control, plus a deeper analysis with larger, slower models. Naming the chain is too much information. Labenz draws the competitive implication: Lovable activity does not look like a winner-take-all contest, because queries are already subdivided. A new model, at most, takes a bite of someone else's share. Osika leaves a door open. Everything is about a team that can execute fast, and it might turn out that one model dominates on price and performance. DeepSeek being open source matters to him because it makes it easier to train their own model for the majority of fast calls, something he sees happening for them quite soon.

His cached scorecard, recorded just before o3-mini shipped, is specific. Claude 3.5 Sonnet is still the best overall: fast, strong at coding, good at reasoning, and it works most of the time. For speed and low cost, Anthropic's Haiku is actually quite expensive next to OpenAI's 4o-mini; the smallest calls have been moved to Google's fast Flash-class model. OpenAI's remaining win is reasoning models, for the moment when the AI is stuck in an uncommon situation and needs to reason from first principles. The user never needs that map. The product does.

Lovable launched on November 21. That is also when they shipped the backend functionality Osika calls a huge part of the unlock, and since then the team has been scaling in a way he describes as absolutely crazy, spending most of its time just keeping up. Back on the demo, Isaak has to log into Supabase again after hitting a cap on projects. Connecting a project automatically sends a message into the Lovable agent. They have a UI. They still need to fetch product pages. Isaak asks how to get data from an external URL, and they flip on chat mode—a Labs toggle that lets you plan with the model without letting it write code yet.

Labenz hears a Socratic step he has wanted: before Elon Musk's assistant starts coding, someone asks a few questions. Osika says superusers already get an order of magnitude more value, and the product has not gone far enough toward pulling that skill forward. What they are building toward is less a silent coder and more a chief product-and-technology officer, plus a head of design, that suggests technology choices instead of only executing them. In this session the model recommends FireCrawl, a popular way to fetch pages, then opens an input box for the API key. Lovable does not manage FireCrawl billing. The service is free at first and costs money later; the builder stays in control of the account.

The scrape request fails. Isaak has to open Supabase edge-function logs by hand and paste errors back into the chat. Programmatic log access, Osika says, is coming, and it will be a game changer for backend endpoints. He believes Lovable has been driving most of Supabase's new signups, and that Supabase is starting to build for programmatic access because the user is now an agent, not a human who will just read a dashboard. Other backend vendors are saying they will be agent-first. Labenz recognizes the job: a glorified copy-and-paster, shuttling a ChatGPT Pro plan into another coding UI one instruction at a time. Osika's diagnosis is that context management is the hard, early problem in an LLM app, and that being good at it is why people who compare tools tell him Lovable is more reliable.

Labenz flags a language trap. In domains he does not know well, he tries to stay neutral, because the word scrape still sends many models toward a Python script, the requests library, Beautiful Soup, and scraping hell. Production-grade tools already exist. Lovable's list of defaults lives at lovable.dev/integrations: Resend for email, Stripe for payments, OpenAI or Anthropic for AI, Runway for image generation, Replicate for a zoo of other models, FireCrawl for fetching. Native integrations stay current when an API changes; an arbitrary API may not. They also almost never hard-code secrets. Even a frontend-only sketch gets an input field for the key, which removes a class of mistakes for beginners and a class of leaks for everyone else. Osika admits they should be more Socratic when a user's request does not make sense. For now they rely on people who know the domain or learn fast—and when a path goes sour, his instinct is to restart from scratch.

Osika will not oversell the live app. For a pretty technical person, a simple application like this can be built end to end quite reliably. For people who are less technical, patience is enough to succeed, but they will run into problems with at least 50% probability, and with maybe 10% probability it will take a ton of time and feel like getting stuck. There is luck in it. This class of app is something you can definitely build on the current product, and he adds a line that is easy to miss: this is as bad as it is ever going to be. The company is a bit more than a year old. They went down the agent hole, saw some advantages, and then came to a UX realization that made them refocus on speed—the fastest possible way to get a result back to the user.

Labenz's working distinction is agency as delegated decision-making, versus a Zapier-style chain where every step is prescribed even if some steps are models. Osika's definition in an LLM setting is more operational: the agent does one action, looks at the result, does another, in a very open-ended loop. You can get reasoning without that loop by designing a chain of calls. The open loop is more general, and it is also unpredictable in how long it will take. Unpredictable plus not 100% reliable is, he says, a very bad experience. You want to get as far from that as possible. Once you are fast and reliable, you can let the system take more than one step.

The demo keeps proving the point. A 502 from FireCrawl is a 500-class error, meaning the failure is on FireCrawl's side; clicking Try to fix on Lovable's side cannot repair someone else's gateway. Labenz asks why the product does not just take the next debugging step on its own. Osika says they do not unleash it like that, not enough, not yet. Labenz has felt the opposite failure mode with Devin: the agent keeps working in the background, you tab away, you tab back, and it may be on iteration 87 with no shared picture of what works, what does not, and what it is doing. Limited agency—try the prompt, try the product, stop—appeals more than a runaway loop. Lovable already has an agent mode in the same selector as chat, visible only on admin accounts. Making an agent work intuitively takes a lot of iteration. Osika puts it on the top of the roadmap for the coming few weeks. The most important thing, he says, is a product that predictably works, in an intuitive way.

Eventually the headphones comparison works: sound quality, noise cancellation, battery life, then a head-to-head. Isaak asks the model what to do next, and they treat it as a product manager handing tickets to an engineer. He nudges it toward OpenAI function calling so the table is a structured response rather than a long politically correct paragraph. If everything had been logged in from scratch, Osika would expect this to take five minutes, and he is happy to see people post speedruns. Plain English is the hottest programming language, and it actually works here—but it still takes a human supervisor who knows the queue. They even feed the tool Bolt and Lovable as a situational-awareness test. The comparison AI says Bolt has built-in deployment and Lovable does not. Osika objects on the spot: they do. That is what you get with AI, Labenz laughs, and the interfaces are in fact quite similar.

They have been through 17 edits. Labenz's own practice in Cursor is to commit every working state and be willing to roll back, because once you leave the rails, models are often worse at iterative debugging than at doing the thing right the first time. They get confused, they do not break frame well, they make a mess. A trick that has worked for him: grab the error they could not fix, revert, and tell the next prompt that last time you got here and failed, so avoid that path. People get attached to code they wrote by hand. Throwing away four rounds of model output should be easier.

Isaak's picture is a search tree. You start in the middle and features have required substeps. Non-technical users usually get stuck because they did not take those steps in the right order, which is why Lovable recommends the chat-only consult. If the order was wrong, revert. Include the error as scar tissue, nudge a different direction, and even without a nudge there is some probability the model's own randomness takes another path that works. If you have gone down a spiral, get out. In this session, a revert plus FireCrawl docs might have been the right move while they were stuck on fetching.

Osika opens a clean project to see if he can do it in a handful of prompts. He skips Supabase on purpose, asks for URL fields, FireCrawl, and one OpenAI call that answers two questions: what features to consider, and how the products compare. Because keys are not hardcoded, the UI is just input fields, and the system has fewer moving parts. It lands in three edits. That, he says, is what he would expect. For an internal tool with one main feature, a dozen edits or so should do it if you are good at reverting. Many features take hundreds of edits, and the model handles large codebases less well even with the tricks they will not fully describe.

On large codebases, Osika will only sketch the secret. They do RAG, and agentic RAG is one of the reasons the product stays good as the code grows. He will not go into detail; Labenz can try to reverse-engineer it. Context management, he adds later, is a superset of smart RAG, and one of the core pieces of the system. The live app still shows the ugly edge: OpenAI cannot swallow a whole Amazon page, so the model caps input at 4,000 characters, which is a good way to keep header junk and lose the spec. FireCrawl's cleaner title-and-text extract helps. To use Lovable at full power, Osika says, you often want to paste API payloads into the thread because they are not all fed in by default.

The growth story is the one the host opened with, now in Osika's own numbers. Since launch they have just continued to grow. They are at $9 million in annual recurring revenue, in eight weeks, which from his research is faster than any other company launching from Europe. More important to him: hundreds of thousands of users, comment threads full of people blown away by what they can do, and paying customers who open the product every other day. Next they want it to be valuable for teams that collaborate—he shows something on his screen that is not a launch yet. What excites him more is reliability, the product debugging itself, and the agentic mode they already use internally.

Publish deploys the app on Cloudflare's edge, one click into production, in a setup he says scales well. Edit Code is more interesting than it sounds: VS Code opens in the browser, a human change syncs, and you can also work from Cursor or another IDE against GitHub. Branching is built in. Superusers learn to drop API documentation into the project's knowledge. On signup they ask how much coding experience you have, and the answers split evenly from none, to a bit, to a lot. The company is about empowering the 99% who do not know how to code, and the even larger set who do not know both frontend and backend. Technical users still get further, because they understand debugging and API calls. The favorite users are high-agency founders and operators—people running a business or an agency who are quick to see what the new technology makes possible.

Over 2025 he expects models to keep getting more intelligent, which means some of the clever algorithms that put Lovable ahead today will matter less, and opinionated infrastructure packaged for those models will matter more. The thing to figure out as a team is the right abstractions, on the UX and on the generated projects, so they get the most out of whatever the frontier model is. They are hiring people willing to relocate to a Stockholm office, to sit at what Osika calls the epicenter of what AI can do right now, at top-of-market pay. His closer is not subtle. If you have not tried these tools, get your hands dirty. If you are currently working without AI, he thinks you are really disappointing your employer or your clients. Get on the train. It is a huge time saver.