How Lovable vibecodes production software at scale

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. 如果你没见过我们的界面，或者没用过 Lovable，这就是它的样子。 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 提需求；右边是预览区。 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. 我的联合创始人 Anton 创建了一个 GitHub 仓库，叫做 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. 那个仓库当时成为 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. 当时的 demo 就是让它做一个贪吃蛇游戏，它构建出来并直接运行给你看。 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? 我们称之为「99%」的那群人，对吧？ The, not the 1% that can code, but the rest of the population. 不是那 1% 会写代码的人，而是其余的大多数。 And we, we set out on, kind of the mission to, to build a tool for them to create software. 我们踏上了一段旅程，使命就是为他们打造一款能创建软件的工具。 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. 所以今天，我们平台上已经有 1500 万个项目。 We have 600 million monthly visits to the sites built on Lovable. 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. 如果在一个抽象层面上有专家参与协同 AI 就会容易很多。 But there's, I would say, an immense demand for this type of use case and increasingly so. 但这类场景的需求是巨大的，而且还在持续增长。 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. 这句话还有下半句：前 90% 的代码同样占用了 90% 的时间。 So you end up with 180% of the time. 所以加起来你有 180% 的时间。 And this is in the 1900s here, right? 这是上世纪的说法，对吧？ Late 1900s. 20 世纪末。 And it's, it's also true in the age of AI. 在 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 全权接管写代码，你可能有过这种体验：一开始能非常快地做出第一版，对吧？ 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. 我们内部有一个指标叫做 is_stuck。 And it will be true if you're asking for the same thing three times in a row. 如果你连续三次提了同样的要求，这个值就会为 true。 So if you're asking "fix it, fix it, fix it," we will assume you're stuck. 比如你一直在说「修一下，修一下，修一下」，我们就会认为你卡住了。 Or if you complain about the implementation that Lovable is doing. 或者你在抱怨 Lovable 的实现方式。 So if you're saying "oh, this didn't work" and so on, then we will also kind of mark you as stuck. 比如你说「哦，这个没有生效」之类的，我们也会把你标记为卡住了。 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. 这就是「黄色卡住」，还没有完全陷入困境。