Lovable founder's retrospective: from GPT Engineer to 70 million projects, the architecture was rebuilt several times
Sharing from @antonosika: Lovable's product goal set in 2023 has barely changed: let people who can't code build and deploy software through chat, and see results immediately. What changed is the implementation. It has been rebuilt several times: narrowing the scope of the problem, reducing the Agent's freedom, replacing fine-tuning with knowledge files, shortening the check-and-fix loop, and finally branching and merging a whole running machine. To date Lovable has merged over 100,000 PRs into its codebase, and users have created over 70 million projects on the platform.
Starting point: narrowing the problem first
In the spring of 2023, Osika open-sourced GPT Engineer on GitHub: you describe the software you want, it asks a few clarifying questions, then writes the entire codebase. Lovable initially only did new projects, meaning users arrive with an idea, Lovable generates the code and hosts it with one click. This avoided having to deal with all kinds of existing codebases and runtime environments. The team also removed the early option that let users choose a frontend tech stack, standardizing on one fixed stack. The principles were three things: limit the scope of the problem, control the environment in which code runs, and learn from runtime results. Every improvement to this fixed environment benefits a large number of projects.
The Agent's freedom should match the model's capability
Osika originally expected models to improve quickly, so he pushed the team toward autonomous Agents. Engineer Mårten Wiman built a complex asynchronous design in which the Agent could create tasks itself and dispatch them to sub-Agents. The result: Agents with more freedom easily got stuck in technical details and couldn't get out, made frequent errors, and their completion times were unpredictable, so the product became unreliable.
So the team deleted almost all the Agent code and went back to one user request corresponding to a predictable chain of tool calls, with the output being a chat reply plus a live preview. By the end of 2024, the main editing flow was a single reply containing all the files that needed changes. At the time, native tool calling wasn't stable enough, so they had the model wrap code in tags like <lov-write>, then parsed out the changes after the model finished output. The system had retries and error handling, but no open loop where the model itself calls tools, checks results, and decides the next step; instead, the user looks at the preview to decide how to change things next. For context, they used several small fine-tuned models to pick out the code relevant to each change, including files that don't need modification but depend on the change.
The planned model training gave way to knowledge files plus retrieval, which worked better
The 2023 plan was to fine-tune models on product data. In 2024 they found a simpler approach first: engineers went through the chat logs of apps that had errors, and wrote the recurring mistakes and ways to avoid them into short notes called "knowledge files." For example: "only use icons that exist in lucide-react; don't invent icon names." At retrieval time the system selects the relevant notes and adds them to the model's context, with no fine-tuning needed. Osika believes this was crucial to Lovable taking off at the end of 2024, and at one point even called it a kind of "scaling law": each additional knowledge file makes the Agent a bit more reliable. The article also notes this is the same idea as today's agent skills. The later Lovable Stack Overflow lets the Agent retrieve similar questions and solutions; in an early version, it reduced the rate at which users got stuck by 5%.
Shortening the check-and-fix loop
If every change required a full rebuild, even small edits would be slow. They gave each project a persistent sandbox that keeps project files and keeps the dev server running, so changes update the live preview directly. They also run incremental TypeScript checks, reusing earlier results, and when errors appear, hand them to the Agent to fix while the project is running. Osika's judgment is that the speed of a coding Agent depends on how quickly it can check and correct its own work.
Branching and merging a whole running machine
Later they went further: saving only source code isn't enough, they also need to save the running processes. A stateful sandbox can snapshot the machine's memory, CPU state, and disk, restore them when needed, and the Agent can return to the same working environment within seconds even after days. This framework is called Camille. It can now branch an entire application together with its runtime environment and database, letting the Agent try different approaches from the same starting point, and it has become the foundation for many of Lovable's features.
Three challenges ahead
· Handing tedious operations to the system: once real users and real money depend on an application, the system must handle testing, deployment, scaling, availability, security, and catching bugs before they happen. Osika thinks the hardest part is trust: if a user's one sentence is misunderstood, it could delete data or cause irreversible damage.
· Covering every type of software: desktop, mobile, complex workflows, real-time data processing, and globally deployed business systems, each with different environments, constraints, and failure modes.
· Building better software infrastructure: including observability, branching and merging of machine snapshots, a new sync engine, durable execution, and verifiable guarantees for security and privacy.
His goal is not to build an "AI software engineer" but a platform on which people can run their entire business: users are already connecting Slack, importing data, handling payments, doing growth and analytics, and even having Lovable help register their companies.