How Lovable self-improves every hour

Why does an agent need the same mistake explained over and over again? A correction helps the current conversation, but the next attempt—or the next user—can encounter the same failure. Continuous learning requires turning that correction into a change that survives the session. Benjamin Verbeek, a member of technical staff at Lovable with a background in satellites, particle physics and fusion reactors, introduces two approaches toward that goal: learning better ways to use the existing product, and repairing the product itself.

Lovable’s interface puts a chat beside a sandbox preview. Describe the software you want, inspect the result, test it and ship it. Verbeek tentatively credits Lovable with coining “vibe coding,” although Lovable’s own introduction to the term credits Andrej Karpathy. The relevant product idea is software creation without having to inspect the code between an instruction and its visible result.

That interface produces an unusually useful learning environment. Users can spend a long time in one conversation, working toward an artifact they care about shipping. Compared with short, unrelated chat sessions, this gives the agent more context about both the project and the person building it.

Verbeek frames the audience as the 99 percent who cannot code: an expression of Lovable’s ambition to make software creation broadly accessible, rather than a measured population estimate. He compares these users to startups adopting new technology. They pursue an outcome without being constrained by older implementation habits, and keep trying until it works. The product has to make that persistence productive.

When Verbeek joined roughly a year before the talk, Lovable had a few thousand users. Verbeek reports that Lovable was creating more than 200,000 projects per day at the time of the talk. That is project creation, not a count of published websites; his accompanying claim about Lovable’s share of new websites comes without a denominator. Scale creates both a large supply of learning examples and operational pressure. He recalls GitHub banning Lovable on his first day because it created too many repositories, and says the company overwhelmed several cloud providers along the way.

For a technical user, AI-assisted development can alternate between rapid progress and recoverable friction. Verbeek illustrates the good stretches as tenfold or hundredfold acceleration, not as a measured benchmark. A yellow friction point might yield to a more precise prompt. A red blocker might require editing configuration, changing a setting, supplying an environment variable or adding an API key. A developer can intervene and resume.

A nontechnical user may prompt past the yellow section but leave at the first red one. They can abandon the project before experiencing a successful end-to-end result. The important reliability target is whether the user can finish, not just whether the agent usually makes progress. As models improve, more of these users’ requirements become achievable; Lovable’s focus over the preceding year was removing the blockers that still prevent them from getting there.

A session can reveal that a user is stuck without requiring them to diagnose the cause. Repeated requests suggest that the first attempt did not work. Complaints about an implementation, explicit failure reports and apparent premature abandonment provide other signals. An LLM judge can inspect sessions for these patterns and flag likely failures. A first request to improve something is not, by itself, evidence that the user is stuck.

The next question is whether the current product can solve the task at all.

The first class includes tasks that persistent users can already complete. The second includes things that should work but do not. The third may require weeks of AI-assisted engineering. Verbeek’s immediate targets are the first two: if a task is solvable, it should work for more than the users willing to struggle; if a fix is straightforward, the team should ship it.

For tasks the product can already solve, Lovable builds what Verbeek calls a Stack Overflow for Lovable: a collection of problems and solutions that the agent can use. Consider a user complaining that a website becomes laggy while scrolling. Initially, that is simply a new task. The agent attempts a performance fix by quantizing animations, but the user reports that the site is now jumpy as well as laggy. The repeated request and complaint about the attempted fix make this a clearer stuck session.

The conversation may continue through several attempts. Some users leave; others persist long enough for the agent to find the cause. In this example, individual gradients on overlay text were making the animation slow. Once the agent reaches a successful solution, the session’s isStuck state returns to false. The useful event is the transition from stuck to resolved, with care to distinguish resolution from a user simply giving up.

That recovery supplies a concrete extraction question: What information could have been injected at the initial request to reach the successful solution directly? The goal is to spare the next user the failed intermediate attempts, rather than merely archive the conversation.

Lovable then clusters similar issues to identify the reusable information. Without this step, the knowledge bank could fill with near-duplicate entries that effectively say to perform one exact action for one exact prompt. Clustering aims to capture the common problem and solution without overfitting to an individual session.

In the workflow described in the talk, an external reviewer—usually another agent, sometimes a human when there is uncertainty—generates and runs a quick evaluation against the examples in the cluster. The question is whether the proposed guidance resolves those cases. Accepted entries become part of a continually updated problem-and-solution bank.

While the main agent works, a lightweight model watches for issues that have an answer in the knowledge bank. When it finds a relevant answer, it injects that context into the main agent. For a small sample of eligible cases, however, the system sends a blank instead. These projects could have received the guidance but did not, providing a comparison group for the projects that received it.

The production loop asks whether the guidance helps the whole project succeed:

1. Identify projects eligible for a particular knowledge injection.
2. Compare projects that received it with eligible projects that received nothing.
3. Increase use of guidance associated with better project outcomes.
4. Reduce use of guidance associated with worse outcomes.

The evaluation target is overall project success, rather than whether the injected text sounds helpful. The talk does not specify the holdout allocation method or experiment size.

Knowledge retirement is part of learning. A new model may no longer need advice that helped its predecessor. A product change can make an old workaround obsolete. Lovable therefore rebalances usage and discards entries as the surrounding system changes. Keeping every previously useful answer would accumulate stale context that can interfere with the agent’s work.

Verbeek reports fewer fix-intent or stuck messages and more deployments in early production data, without supplying numerical effect sizes in the talk. He says subsequent results were better. Deployment matters because it indicates that a user completed the project instead of encountering a blocker severe enough to abandon it.

The collected problems also support internal model rankings. Verbeek says all models at the top of Lovable’s internal ranking used the Stack Overflow information. Some entries were undisclosed, so the result describes Lovable’s internal problem set and evaluation rather than a reproducible public leaderboard.

A knowledge entry cannot fix a capability the product does not have. For bugs and unsupported tasks that should be straightforward, Lovable uses a second feedback loop. The analogy is an employee who cannot complete an assignment with the available tools: they would complain to a manager or explain the problem in Slack. Lovable gives its agent a similar outlet to report problems directly to its creators.

An external reviewer asked what could be improved after every iteration is under pressure to produce an answer even when the iteration went well. Verbeek argues that this creates noise and encourages overfitting to it. Instead, the working agent is prompted to report only substantial frustration. That threshold can be tuned to increase the proportion of useful reports.

The vent/send feedback tool asks the agent to report tooling, documentation or platform behavior that materially slows or degrades its work. Its triggers include:

• Missing capabilities: absent or unsuitable tools.
• Unclear contracts: confusing tool names, unexpected parameters or mismatched schemas.
• Conflicting guidance: documentation or instructions that disagree.
• Platform failures: broken behavior or repeated attempts blocked by environment limitations.

These are problems the team hopes are absent, but can act on if the agent identifies them.

The working agent also has diagnostic context that the user may lack. It has already attempted the task, observed the tool behavior and perhaps spent several turns investigating. Asking it to report the obstacle preserves that context at the point where the problem is encountered.

One complaint sent directly to Slack concerned Framer Motion’s TypeScript types. The agent wanted to provide four numbers for what Verbeek thought was a cubic Bézier curve, and objected to the casting required by its attempted implementation. Verbeek questions whether that particular complaint was relevant, while suggesting that the use case could have been simplified. This is a specific historical interaction, not evidence that four-number curves are generally unsupported: current Motion documentation supports them, and the talk does not establish the library version or exact type error.

The complaint’s conversational form is useful in its own right. Engineers recognize the experience of fighting a tool to express something simple. That makes the report easy to interpret and gives them a starting point for deciding whether to simplify the workflow, clarify the interface or dismiss an irrelevant complaint.

A more concrete report concerned a copy tool that could not move certain uploaded files into another document store. Engineers checked the tool and found that it worked, but the agent identified a condition their checks had missed: filenames containing raw spaces failed. Verbeek recalls roughly twenty complaints about the copy failure in the first hour after launching the feedback tool.

The first repair replaced spaces with underscores. Reports continued. The team then identified non-breaking spaces in screenshot filenames associated with WhatsApp or Mac, which their regular expression had not replaced. The distinction can be illustrated in TypeScript with two filenames that look almost identical:

const filenames = [
  "Screenshot 1.png",
  "Screenshot\u00A01.png",
];

const replaceOrdinarySpaces = (name: string): string =>
  name.replace(/ /g, "_");

const results = filenames.map((name) => ({
  before: JSON.stringify(name),
  after: JSON.stringify(replaceOrdinarySpaces(name)),
  containsNonBreakingSpace: name.includes("\u00A0"),
}));

console.table(results);

The ordinary space becomes _; the example’s U+00A0 remains unchanged. These teaching filenames illustrate why matching one space character is narrower than handling the filenames users actually supply. The talk does not identify the original regex or exact Unicode code point.

Further reports identified other special characters, and the team continued repairing the tool until, Verbeek says, the issue stopped occurring. He does not supply the final implementation or a follow-up duration. The useful mechanism is the repeated feedback: each incomplete repair left a remaining class of failures that the agent could describe.

Tool-failure telemetry could show that something failed. The complaints explained the circumstances of failure closely enough for engineers to act. That is the additional value here: not an absence of logs, but a report that connects a symptom to a likely cause.

The initial route was direct: the agent encountered an issue, called the vent tool and sent a report to Slack. Verbeek started with a restricted channel because he was unsure whether the volume would become spam. Lovable’s head of product was enthusiastic enough to read every message. As the workflow developed, a monitoring agent took on deduplication, investigation and pull-request creation. Developers still reviewed the changes and, in many cases, merged them into production.

The stream also became an incident signal. When Verbeek asks what explains spikes in vent counts, the exchange identifies outages and other platform incidents. Broken sandboxes are one example: many agents encounter the same failing capability and complain at once. The reports can therefore indicate both that an incident is happening and which functionality is affected.

There is an economic advantage to collecting feedback inline. The working agent has already processed the context with a strong model. Asking it to identify a material obstacle uses that existing understanding, whereas an equally capable external reviewer would need to read a large context again. Verbeek describes inline feedback as much cheaper comparatively, without providing a measured cost comparison.

The agent eventually supplied feedback about the feedback tool itself: it was too easy to send a report, and there was no way to retract it. Verbeek jokingly describes the agent as embarrassed by what it had sent to Slack. Underneath the anthropomorphism is another tool-design problem: the reporting interface made an action easy without giving the agent a way to correct it afterward.

By the end of the talk, Verbeek is receiving review requests on his phone for pull requests produced by the automation. He inspects them before they can be merged. Automated investigation and patch creation do not yet mean autonomous production approval.

The unfinished work is to connect detection, merged fixes and continuing review and evaluation into a complete improvement loop. Finding a shortcoming and proposing a patch are only part of that system; the resulting change must also be assessed as the product continues to evolve. Verbeek closes by inviting others to help build that loop toward fully automated continual improvement, with human review still part of the workflow he has demonstrated.