# Lovable's founder recounts rebuilding its coding agent architecture several times

> Original title: Lovable 创始人复盘：从 GPT Engineer 到 7000 万个项目，架构推倒重来了好几次

- Source: meng shao
- Published: 2026-11-05T02:33:21.000Z
- Bad Influence: https://badinfluence.news/items/kq2um1bm4e9i4tasfmg4oqlps
- Original: https://x.com/shao__meng/status/2118169771049111671

## Summary

Lovable founder Anton Osika says the product goal has stayed the same since 2023 while the implementation was rebuilt several times. Lovable narrowed the problem to new projects, cut agent autonomy, and replaced fine-tuning with knowledge files. It later moved to branching and merging whole running machines, and says it has built over 70 million projects and merged over 100,000 PRs.

## Why it matters

The post traces Lovable's rebuilds of its coding agent, showing which design choices were dropped and why, useful for teams building similar agents.

## Post

Lovable 创始人复盘：从 GPT Engineer 到 7000 万个项目，架构推倒重来了好几次

来自 @antonosika 的分享，Lovable 在 2023 年定下的产品目标几乎没变：让不会写代码的人通过聊天来做软件、部署软件，并且马上看到结果。变的是实现方式，先后几次重做：收窄问题范围，削减 Agent 的自由度，用知识文件代替微调，缩短检查和修正的循环，最后做到对整台运行中的机器做分支和合并。Lovable 至今已在代码库里合并超过 10 万个 PR，用户在平台上创建了超过 7000 万个项目。

起点：先把问题收窄

2023 年春天，Osika 在 GitHub 上开源了 GPT Engineer：你描述想要的软件，它先问几个澄清问题，再写出整个代码库。Lovable 一开始只做新项目，也就是用户带着想法来，Lovable 生成代码并一键托管。这样不用应付各种已有代码库和运行环境。团队还去掉了早期让用户选前端技术栈的选项，统一使用一套固定的技术栈。原则是三件事：限制问题范围、控制代码在什么环境里运行、从运行结果中学习。对这一套固定环境的每次改进，都能惠及大量项目。

Agent 的自由度要和模型能力相当

Osika 原本预期模型会进步很快，所以一直推动团队做自主 Agent。工程师 Mårten Wiman 做过一套复杂的异步设计，Agent 可以自己创建任务、派给子 Agent。结果自由度更高的 Agent 容易钻进技术细节里出不来，频繁出错，完成时间也没法预测，产品反而变得不可靠。

于是团队删掉了几乎所有 Agent 代码，改回一条用户请求对应一串可预测的工具调用，输出就是聊天回复加实时预览。到 2024 年底，主要的编辑流程是一次回复里包含所有需要修改的文件。当时原生工具调用还不够稳定，他们让模型把代码包在 <lov-write> 这类标签里，等模型输出完再解析出改动。系统有重试和错误处理，但没有那种由模型自己调用工具、查看结果、再决定下一步的开放循环，由用户看预览来决定下一步怎么改。上下文方面，他们用几个微调过的小模型挑出每次改动涉及的代码，包括不用修改、但改动依赖它的文件。

原计划训练模型，实际是知识文件加检索更管用

2023 年的计划是用产品数据微调模型。2024 年他们先找到一个更简单的办法：工程师翻看出错应用的聊天记录，把反复出现的错误和避免方法写成简短说明，叫作「知识文件」。例如「只使用 lucide-react 里存在的图标，不要编造图标名」。系统在检索时选出相关的说明，加进模型的上下文，不需要做微调。Osika 认为这对 Lovable 在 2024 年底起飞至关重要，当时甚至称之为一种「扩展定律」：每多写一份知识文件，Agent 就更可靠一些。文中也提到，这和现在的 agent skills 是同一个思路。后来推出的 Lovable Stack Overflow 让 Agent 检索类似问题和解决办法，早期版本让用户卡住的比例降低了 5%。

缩短检查和修正的循环

如果每次修改都要完整构建一遍，再小的改动也会很慢。他们给每个项目准备了常驻的沙箱，保留项目文件，开发服务器一直运行，改动可以直接更新到实时预览。另外跑增量的 TypeScript 检查，复用之前的检查结果，发现错误后交给 Agent 在项目运行时修复。Osika 的判断是，编程 Agent 的速度取决于它多快能检查和改正自己的工作。

对整台运行中的机器做分支和合并

后来他们更进一步：只保存源代码不够，还要保存正在运行的进程。有状态的沙箱可以给机器的内存、CPU 状态和磁盘打快照，需要时恢复，Agent 过几天回来也能在几秒内回到同一个工作环境。这套框架叫 Camille。它现在可以对整个应用连同运行环境和数据库做分支，让 Agent 从同一个起点尝试不同方案，也成为 Lovable 许多功能的基础。

接下来的三个难题

· 把繁琐的运维交给系统：在真实用户和真金白银都依赖应用之后，负责测试、部署、扩容、可用性、安全和提前修复 bug。Osika 认为最难的是信任：用户一句话被误解，就可能删掉数据或造成无法挽回的破坏。
· 覆盖所有类型的软件：桌面、移动端、复杂工作流、实时数据处理和全球化业务系统，每一类都有不同的环境、限制和出错方式。
· 做出更好的软件基础设施：包括可观测性、机器快照的分支与合并、新的同步引擎、持久化执行，以及可验证的安全和隐私保障。

他的目标不是做一个「AI 软件工程师」，是做一个人们可以在上面经营整个生意的平台：用户已经在里面接入 Slack、导入数据、处理支付、做增长和分析，甚至让 Lovable 帮忙注册公司。

## AI translation

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.

![](https://badinfluence.news/api/img-proxy?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHWVAKCLbUAIe7ss.jpg&mode=thumb&exp=1794096000&sig=340491c54acee2d8)

## Quoted post @antonosika

> In 2023, I wrote down an idea for a world where anyone could build software just by describing it.
> 
> Today, more than 70 million projects have been built with @Lovable.
> 
> 100,000 PRs later, we're at a point where we fork entire computers, including their memory, running processes, environment and data to give the best customer experience.
> 
> I love reading about the history of how technology is built, so I wrote down what I got right & what I got wrong back in 2023 and the journey so far.
> 
> The team will continue sharing what we're learning as we build the software of the future. Here's our inaugural post:

https://x.com/antonosika/status/2117977646940450920