How Lovable vibecodes production software at scale

[Music starts] 【音乐开始】 [Music continues] 【音乐继续】 All right. Great to be here. Thanks for joining. I will talk to you today about Lovable and how our platform self-heals, which I think is an interesting topic. 好，非常高兴来到这里。感谢各位参加。今天我来跟大家聊聊 Lovable，以及我们的平台是如何自我修复的，我觉得这是个很有意思的话题。 But first, I want to give you a bit of background of what Lovable is and, and what we're doing. 不过在此之前，我想先给大家介绍一下 Lovable 的背景，以及我们在做什么。 So, if you haven't seen our UI or you haven't used Lovable, this is how it looks. It's, it's quite simple, the UI. To the left, you'll have a chat where you'll be able to ask Lovable for things, and to the right, you'll have a preview. 如果你还没见过我们的界面或者用过 Lovable，这就是它的样子。界面很简单：左边是对话框，你可以向 Lovable 提需求，右边是预览区。 And what this is, right, is a place for, for people to build software. And it's anything from landing pages to internal tooling to more complex websites to more complex web applications. 它是一个让人们构建软件的地方，覆盖范围很广，从落地页到内部工具，到更复杂的网站和 Web 应用，都可以做。 And so we have basically any type of persona working on this platform, right? You have kids working on it, I think it's my favorite example, and we have people up in the Fortune 500 using this tool as well. 所以我们的用户群非常多样，对吧？有孩子在用，这是我最喜欢的例子，同时财富500强的员工也在用这个工具。 So it's extremely flexible and also extremely easy to use. And I want to give a bit of background. And I think this UI is a good place to start because the UI hasn't really changed in the history of Lovable since we started. 它极其灵活，也极其易用。我想给大家一点背景介绍，这个界面其实是个不错的切入点，因为自 Lovable 创立至今，界面从来没有变过。 But the capabilities behind it and also the models powering it has, has changed drastically. So, about three years ago now, 35 months to be exact, I counted. 但它背后的能力，以及驱动它的模型，已经发生了翻天覆地的变化。大约三年前，确切说是 35 个月前，我数过。 My, my co-founder Anton, he created this GitHub repository and it was called GPT-Engineer. And it at the time it became the fastest-growing repository on GitHub, so the most stars in the shortest amount of time. 我的联合创始人 Anton 创建了一个 GitHub 仓库，叫做 GPT-Engineer。它在当时成了 GitHub 上增长最快的仓库，也就是在最短时间内获得最多 star 的项目。 And the reason that it blew up as it did was that I think it was one of the first, if not the first, kind of showcase of what you can do with models to build end-to-end software. 它能那么火，是因为我觉得它是最早的一批，甚至可能是第一个，真正展示出用模型端到端构建软件的可能性的项目。 And the tool basically was a terminal program that you went in and you asked for something, quite similar in how you could use Lovable today. 这个工具本质上是个命令行程序，你进去提需求，跟今天用 Lovable 的方式很像。 So the demo was like asking for a snake game, and it built it and it ran it for you. It like generated its own like run.sh file and ran the program and did that all end-to-end. 演示里是让它做一个贪吃蛇游戏，它直接帮你构建然后运行，自动生成了 run.sh 文件，全程端到端完成。 So people got very excited around this. At the time mostly developers were using AI within the space of code generation, and they were using it to become more efficient, which is a great application of AI, right? 当时大家对此非常兴奋。那个时候，开发者是主要的 AI 使用者，用于代码生成领域，目的是提高效率，这当然是 AI 很好的应用场景，对吧？ And there's a bunch of companies focusing on this, making developers more, more efficient in their current workflows. During this time, summer of 2023, it was mostly code complete in your IDE. 有一批公司专注于此，让开发者在现有工作流里更高效。那段时间，大约是 2023 年夏天，主流形态是在 IDE 里做代码补全。 But we wanted to do something a bit different. We wanted to create something for people who didn't necessarily know how to code, and did not have these capabilities at all really to create software. 但我们想做点不一样的事。我们想为那些不一定懂编程的人创造点什么，为那些完全没有编程能力的人提供创建软件的工具。 And, and we call that the 99%, right? The, not the 1% that can code, but the rest of the population. And we, we set out on, kind of the mission to, to build a tool for them to create software. 我们把这群人叫做那 99%，对吧？不是那 1% 会写代码的人，而是其他所有人。我们就这样踏上了为他们打造开发工具的使命之旅。 And it didn't work back then. It was a bit too early. The models weren't really at a place where you could work on this abstraction where you kind of had the chat and the preview, where you're just looking at the output of what you're creating. 当时没做起来，时机稍早了一点。那时候的模型还不足以支撑这种抽象层，只是看着自己创作的成果，通过对话和预览来工作。 But it started to get there. And today, I would say we're, we're definitely there. I think we got there about one and a half year ago where this abstraction started to, to make more sense. 但它慢慢开始成熟了。今天我敢说，我们确实做到了。我觉得大约一年半前，这套抽象开始真正说得通了。 And since then, you know, about every three months we get an improvement in the foundational models that I think make our use case make even more sense. 从那时起，大概每隔三个月，基础模型就会有一次提升，让我们的使用场景变得更有意义。 So today, right, we have 15 million projects built on the platform. We have 600 million monthly visits to the sites built on Lovable. 现在，我们平台上已经有 1500 万个项目。Lovable 上构建的网站每月有 6 亿次访问。 And I think this is an interesting statistic because it's significantly more than what Lovable has itself, which I think is a great sign that people are building things that kind of out-succeed Lovable combined, right? 我觉得这个数字很有意思，因为它远远超过了 Lovable 本身的访问量，这说明用户们构建的东西加在一起，已经超越了 Lovable，对吧？ And since I know that a lot of the audience here are engineers, I wanted to also mention that something I learned asking AI, one of our internal AI agents, about our data is that if you look at the functional segment of of what our users identify as, most of them say that they're engineers. 由于现场有很多工程师，我想分享一个有趣的发现：我问了我们的一个内部 AI agent，关于用户数据的分析，如果看功能性细分的话，大多数用户说自己是工程师。 The biggest, the biggest segment would be founders, right? But if you look on kind of functional segments, it's engineers. And it's not what we necessarily built the platform for, but it turns out that it's quite nice to work at this kind of abstraction layer and not care about the code if you don't have to. 最大的群体其实是创始人，但从功能性细分来看，工程师占比最高。这不是我们最初设想的用户，但结果证明，在这个抽象层工作，不用关心代码，其实挺好的。 And I think this, it, there happened something in December 2025, right, where, where models got to a place where I think a lot of engineers started using it more as a tool to not necessarily do autocomplete or write single files, but where you could actually take a step back and work from a specification. 2025 年 12 月发生了一件事，对吧？模型到了一个新阶段，很多工程师开始把它当工具，不仅仅是做自动补全或写单个文件，而是真正退后一步，从规格文档开始工作。 And we introduced things like, we as a community I mean, we introduced things like REPL looping and these sort of things where you really let the models do more, more of the work. 我们，也就是这个社区，引入了像 REPL 循环这样的东西，真正让模型承担更多工作。 So this is the general trend. Um, I, I want to kind of highlight two things that we do at Lovable that, that guide us, two of our principles in, in how we build. 这是大的趋势。嗯，我想重点介绍我们在 Lovable 做的两件事，这是我们的两个核心原则。 So, number one is that we really want to build production-grade software and, and really chase the frontier of what's possible. 第一，我们真正想构建的是生产级软件，持续追求可能性的边界。 And when I say that I mean we could have focused only on doing prototyping, but we choose to kind of continue to push what's possible to build in terms of complexity and, and size and ambition for, for our users. 我说这话的意思是，我们本可以只做原型，但我们选择继续突破，在复杂度、规模和雄心上不断拓展，为我们的用户创造更多可能。 And we also combine that with building for non-technical users. And I think that makes our job hard, in a sense, right? 我们同时还把面向非技术用户作为核心方向。某种程度上，这让我们的工作更难，对吧？ It's easier if you're building on an abstraction layer where an expert can be in the loop with the AI. But there's, I would say, an immense demand for this type of use case and increasingly so. 如果你在一个抽象层上构建，有专家参与和 AI 协作，会容易一些。但我说，这类需求是巨大的，而且越来越大。 So, there are a few things that make this challenging. And, and I think this quote is interesting. It, it talks about that the last 10% of code takes 90% of the time. 这件事有几个难点。有句话我觉得很有意思，它说最后 10% 的代码要花 90% 的时间。 And the other part of this quote is that the first 90% also takes 90% of the time. So you end up with 180% of the time. 而这句话的另一半是，前 90% 也要花 90% 的时间。所以加起来就是 180% 的时间。 And this is in the 1900s here, right? Late 1900s. And it's, it's also true in the age of AI. 这句话是上世纪，也就是20世纪后期说的，在 AI 时代同样成立。 And I think if you've ever used kind of a vibe coding tool or you've just kind of coded with AI and you've let the AI kind of do everything, you might have experienced that in the beginning you get to a first version really fast, right? 如果你用过氛围编程工具，或者干脆用 AI 写代码，让 AI 包揽一切，你可能体验过：刚开始跑出第一版特别快，对吧？ But then actually finishing it off and making sure that you don't have any bugs and all of these things takes even more time. 但之后真正完成它，确保没有 bug，这些事反而要花更多时间。 So I find it quite interesting that, you know, this was true when we wrote all the software by hand and the same pattern is true when we work with AI, maybe even more so. 我觉得很有意思，手写代码的时候是这个规律，用 AI 工作的时候也是同样的规律，甚至更明显。 And if you would kind of put this on a timeline like this, so you start building and you're in the green, meaning you don't have much friction, kind of everything is going along. 如果把这个过程放在一条时间线上，一开始你在绿区，没什么阻力，一切都在顺利推进。 And then at some point you reach some friction, maybe some bug that you're figuring out, and, you know, then you keep on building. 然后到某个时刻，你遇到了摩擦，也许是某个 bug 需要解决，之后继续推进。 And then you might get into the red here, and the red is kind of you're stuck, right? And you might have experienced this, like I can just think of my own experience, like when you're you're up late a bit a bit too late and you're you're stuck on this problem and you're trying to solve it. 然后你可能进入红区，就是卡住了，对吧？你可能经历过这种感觉，我自己也有过，深夜太晚了，被一个问题卡住，一直想解决它。 And maybe you don't, then you go to sleep and you solve it maybe the next day with some with some more kind of work and thinking behind it. 也许当时没解决，睡一觉，第二天再想想，多花些时间和心思，就解决了。 And then, then you get back to work, right? And I think this is quite a common thing for software engineers to do and we're we're used to it. 然后你重新开始，对吧？这对软件工程师来说相当普遍，我们早就习惯了。 But again, imagine if you're if you're non-technical, right? And and you're doing this, especially if you're working on the abstraction as you would in Lovable, right, where you're not necessarily looking at the code. 但换个角度，想象你是非技术用户，对吧？特别是在 Lovable 这种抽象层工作，你根本不用看代码。 As a developer, you know, we have a connection to GitHub and you can always jump into a deeper level if you want, but many users do not have that experience or they simply are not interested in it. 作为开发者，我们有和 GitHub 的连接，随时可以下探到更深层，但很多用户没有这种经验，或者根本不感兴趣。 And if they get stuck, it, it's a very bad experience for them, right? It's kind of the worst thing that can happen to them because it's much harder for them to get unstuck. 他们一旦卡住，体验就很糟糕，对吧？这几乎是最坏的情况，因为他们重新解锁要难得多。 They might contract someone to help them out, and they might learn how to code or they might just like try to prompt around it. 他们可能花钱找人帮忙，或者去学一点编程，或者就在提示词上反复试探。 And they might succeed, right? But if they don't, it's kind of the worst thing that can happen in the user experience and it's very important for us building this experience, right, that to help our user succeed and not get into this kind of hard stuck place. 他们可能成功，对吧？但如果没有，这是用户体验中最坏的结果，对我们来说帮助用户成功、不让他们陷入死局，是非常重要的事。 So, really our vision with Lovable on the technical side is that every app that is built on the platform should help improve the next. 我们在 Lovable 技术侧的愿景是：平台上构建的每一个应用，都应该帮助改善下一个应用。 And there's a few tactics in in how you can do this. And I will today present you two things, as examples of what we're doing. 实现这个目标有几种方法，今天我会给大家介绍两个具体案例。 But first let me define what "stuck" is. So we have this metric internally that we call is_stuck. And it will be true if you're asking for the same thing three times in a row. So if you're asking "fix it, fix it, fix it," we will assume you're stuck. 不过先来定义一下什么是「卡住」。我们有个内部指标叫 is_stuck，如果你连续三次问同样的事，它就会被标记为 true。比如你一直发「帮我修，帮我修，帮我修」，我们就认为你卡住了。 Or if you complain about the implementation that Lovable is doing. So if you're saying "oh, this didn't work" and so on, then we will also kind of mark you as stuck. 或者你开始抱怨 Lovable 的实现结果，比如说「这个没用」之类的，我们也会把你标记为卡住。 And then the the last part is if you asked for something and then you just left. 还有最后一种：你提了个需求，然后直接离开了。 So we we can identify then if if a user is stuck or not with the help of a small classification model. 借助一个小型分类模型，我们就能识别出用户是否卡住了。 And then the thing is also that there's different kinds of of being stuck. So I'll give you kind of three buckets. 卡住的情况也分不同类型，我来说说三个大类。 The first one is you're stuck in a way that would be solvable if you prompted differently. And it might even solve itself if you just said like "oh, fix it, fix it," like that type of follow-up. 第一类，是换个提示方式就能解决的卡住。甚至自己重试几次，发「帮我修，帮我修」这种跟进，就可能自己好了。 Or you might give it some more context and the problem would be solved. For us building the platform, right, that the question we have to ask ourselves is, can we fix it the problem before the user even gets stuck? 或者再补充一些上下文，问题就解决了。对我们来说，真正要问的是：能不能在用户卡住之前就把问题解决掉？ And this would be kind of the yellow stuck, so you're not hard stuck yet. 这就是所谓的「黄色卡住」，还没到完全死局。 And the the second part here is something that should be easy to to do for our agent, right? But it might not currently be supported by our platform. 第二类，是对我们的 agent 来说理论上应该很容易解决的事，但平台可能暂时还不支持。 And then the question for us building our platform is, how can we keep on improving and even self-heal at the edges of our own functionality? 这时候我们要问自己：如何在平台能力的边缘持续改进，甚至实现自愈？ And what I mean by that is that of course our platform, because people are building with LLMs, they can do so much. It's almost impossible for us to think about everything they can do. 我的意思是，用户在用 LLM 构建东西，能做的事太多了，我们几乎不可能预见到所有情况。 So we really need like a system to help us heal where where we're falling short on our platform. 所以我们真的需要一套系统，来帮我们修复平台上的不足之处。 And the last bucket is when, quite similar that it's on our side, where where our platform is falling short, but there might be kind of bigger investment for us to do something. 第三类是类似的情况，问题在我们这边，平台有所欠缺，但解决它需要更大规模的投入。 And I think a great example here is that for the longest time Lovable had like single-page applications that would be client-side rendered, which is fine for for most things. 一个很好的例子是，Lovable 很长一段时间只支持单页应用，也就是客户端渲染，这对大多数场景都够用。 But if you care a lot about SEO, it's generally best practice to have server-side rendered where you render the content on the server so that Google and other search indexers will be able to to see that without having to render it themselves. 但如果你非常重视 SEO，最佳实践是服务端渲染，内容在服务器上渲染好，这样 Google 和其他搜索引擎就能直接抓取，不需要自己去渲染。 And luckily we shipped this last week to Lovable, and but that is a bigger investment from our side, right? 好在上周我们已经把这个功能发布到 Lovable 了，但这确实是一次较大规模的投入，对吧？ And so these are all three categories in how you can get stuck and I'll I'll give now two examples on what we're doing to solve this. 这就是三类卡住的情况，接下来我会给大家两个具体的案例，说明我们是怎么解决的。 So, first off, we have what we call Lovable Overflow. And the name might remind you of something. It's inspired and it's in honor of Stack Overflow. 第一个，是我们叫做 Lovable Overflow 的东西。这个名字可能让你想到什么，没错，它正是向 Stack Overflow 致敬的。 And what it is really is a big collection of description of issues, just like people would go in on Stack Overflow and kind of describe the issue they're having, and then also the solution to that issue. 它本质上是一个大型的问题描述库，就像人们去 Stack Overflow 描述自己遇到的问题一样，同时也包含对应的解决方案。 And if we if we take an example in how you would get stuck in in the first bucket where you could maybe prompt around it, right? 举个例子，在第一类卡住里，用户可能通过换一种提示方式就能绕过去，对吧？ So imagine you're building something and you try your app out and you find out the scrolling is laggy. So you prompt Lovable, "Hey, scrolling is super laggy." At this point you're not stuck, right? 假设你在构建东西，测试应用时发现滚动很卡。于是你告诉 Lovable：「嘿，滚动好卡。」这时候你还没卡住，对吧？ But the agent comes back and it says, "Hey, I fixed it, I removed the animations." But in reality the agent failed somehow. 但 agent 回来说：「嘿，我修好了，把动画去掉了。」可实际上 agent 失败了。 It thought it succeeded, but it didn't. So you as a user you tried it out and you're saying "Hey, it's still laggy and it looks broken." 它以为自己成功了，但没有。你试了一下，然后说：「嘿，还是卡，而且还坏掉了。」 So at this point we would say, okay, the user is stuck here in some sense. And the worst part about this is that it will potentially repeat, right? You might be in this back and forth with the agent. 这时候我们就说，好，用户在某种程度上卡住了。更糟的是，这种情况可能反复出现，对吧？你和 agent 来回来去。 And then hopefully at some point the agent would would solve the issue. And then when it is resolved, you're then no longer stuck after after you tried it. 然后希望在某个节点，agent 能把问题解决掉。解决之后，你验证了一下，就不再卡住了。 And often, you know, a user would move on to implementing the next thing or they give us explicit feedback. Regardless, we'll try to identify that "Hey, okay, you're no longer stuck." 通常，用户要么继续做下一件事，要么给我们一些明确的反馈。无论如何，我们会尝试识别「好，你不再卡住了」。 So in this case we kind of solved it for the user, right? But there was some friction here. 这个案例里，我们最终帮用户解决了，但中间有些摩擦。 And if we the question for us now really is like, "Hey, what if we can just skip to the final solution?" And that is what Lovable Overflow allows us to do. 于是我们开始想：如果能直接跳到最终解决方案呢？这正是 Lovable Overflow 给我们带来的能力。 So if we take this same example but with Lovable Overflow, you would start with the same prompt, "Hey, scrolling is laggy." 拿同样的例子，但加上 Lovable Overflow，你还是从那条提示开始：「嘿，滚动好卡。」 And what we do on the platform is that we build out this big corpus, right, of descriptions of problems and and the solution to them. 我们在平台上做的事，是构建了一个大型知识库，收录了各类问题的描述以及对应的解决方案。 So we will search through those descriptions of the problems and see, "Hey, have other people also had the same type of laggy experience?" 我们会在这些问题描述里搜索，看看有没有其他人也遇到过类似的卡顿体验。 And, you know, we'll have a lot of context here around kind of the tech stack you're using and the libraries you're using and this knowledge can be from kind of broad recommendation to like specific issues with a specific package version. 我们会结合很多上下文，比如你用的技术栈、引入的库，这些知识可以是宽泛的通用建议，也可以精细到某个特定包的特定版本问题。 And so we'll search for that. And then we'll have a lightweight model actually add that context into the main agent when we deem that it is relevant. 我们会搜索匹配的内容，然后用一个轻量级模型，把相关上下文在认为有用时注入到主 agent 里。 And something something that is happening here, right, is that we're kind of modifying the context of our main agent and we'll actually do that in a way that is we're not just kind of dumping the raw context from our knowledge, but we're modifying it a bit to make sense in the particular situation that that you're in as well to make the job as easy as possible for our main agent. 在这个过程中，我们不仅仅是把知识库里的原始内容直接塞进去，而是会适当处理，让它在当前的具体情境中更合理，从而让主 agent 的工作尽可能轻松。 And then sometimes we choose to withhold actually adding this knowledge. Because the knowledge, as you can imagine, can become stale. 有时候我们也会选择不注入这些知识，因为知识是会过时的。 So imagine you had an issue with a JavaScript package that has since been updated. Actually including that knowledge could worsen the experience. 比如你遇到了某个 JavaScript 包的问题，但这个包后来已经更新了，再把这段知识注进去，反而会让体验变差。 So for every knowledge file we'll track its success ratio and we'll actually just remove it and prune it from the knowledge if it is if it is outdated. 所以我们会追踪每一条知识的成功率，一旦发现它过时了，就直接把它从知识库里清理掉。 So we'll continuously review every piece of knowledge in our system and make sure that it's pruned when it's no longer helpful. And at the same time we'll kind of refill with new knowledge. 我们会持续审查系统里的每一条知识，确保不再有用的都被清理掉，同时不断补充新知识。 And this is actually an extremely important part of of making this work, kind of tuning this system of when you should deprecate knowledge and when you should add in new knowledge. 这其实是让整个系统跑通的极其关键的一环，就是如何调优，什么时候该废弃知识，什么时候该加入新知识。 And we have a lot of metrics to help us track this. So that's Lovable Overflow, and how it helps with the first bucket of when you're stuck and it can actually improve the improve the experience of of a user by a lot by kind of not having to do those back and forth, it will be faster, it will be cheaper, and it's much better for the experience. 我们有大量指标来帮助追踪这些。这就是 Lovable Overflow，它解决了第一类卡住的问题，能大幅提升用户体验，省去来回折腾，更快、成本更低，体验也更好。 The second thing I want to talk about is "venting," we call it internally. And I'll get to a bit what we mean by this. 第二个我想聊的，是我们内部叫「吐槽」的东西，我来解释一下什么意思。 And it's for the second bucket that I described, which is when things are easy in theory, but somehow you still get stuck. 这解决的是第二类卡住：理论上很简单的事，却仍然卡住了。 So you can imagine that if you have something that seems easy, you can imagine your own problems, right, but it it still doesn't work. That leads to frustration. 你可以想象，遇到一个看起来很容易的问题，但就是搞不定，这会让人非常沮丧。 And normally if you're working as a developer, for example, you'd either be able to fix this yourself, like you'd be able to update the tooling you're using, switch it out, or you might have a developer experience team that you can go and, you know, complain and give hopefully constructive feedback to and they will help you out. 平时如果你是开发者，你要么自己能修掉，更新一下工具、换一个，要么可能找到开发者体验团队去反馈，他们会帮你解决。 But for the longest time Lovable has not had that. The Lovable agent I mean, right? 但 Lovable 长期以来没有这样的机制，指的是 Lovable agent，对吧？ So you can imagine like you just have people, millions of people every day asking you like, "Hey, can you do this for me? Can you do this for me?" 想象一下，每天有数百万人向你提需求：「嘿，帮我做这个？帮我做这个？」 And you get stuck, right? And it's not your fault. And you don't have anyone to talk to. So you need to vent. 然后你卡住了，又不是你的错，也没有人可以倾诉。所以你需要吐槽。 And it turns out that this is actually a very good idea, in in our experience. And I like to really think of it analogous to just letting our kind of normal coworkers vent their experience. 实践证明，这个想法确实很有用。我喜欢把它类比成让普通同事吐槽他们的经历。 You know, there might be something wrong in the office or the codebase and so on, and you really want to take take note of what's being said. 办公室或代码库里有什么问题，你就想认真听他们说了什么。 So, of course we've been observing Lovable and we've been looking at "Hey, when are things going wrong?" and so on, and we've been fixing things. 我们一直在观察 Lovable，研究哪些地方会出错，也一直在修问题。 But if if you give the agent a tool to tell you when it's feeling frustrated, that's another way to do it. 但如果给 agent 一个工具，让它在感到沮丧时主动告诉你，这是另一种方式。