What Lovable Learned From Spending $85,000 on Agentic Coding

Summary

Lovable engineer Alexander Lebedev has published a detailed account of scaling his AI-assisted development workflow from a few agents and 20--30 merged pull requests in a productive week to a system involving multiple layers of agents and more than 150 merged PRs per productive week.

Lebedev says his individual token spending reached roughly $25,000 per month in May and approximately $85,000 in total since January. Around 75% of his tokens were being used for implementation, with the remaining share going toward automation such as AI reviews and post-merge tasks.

A central lesson is that human attention moves upward as agent throughput increases. Instead of reviewing every line of AI-generated code, Lebedev describes reserving human involvement for higher-impact decisions such as system design, RFCs, architecture, and high-risk changes.

To support this, he built an AI workflow that classifies pull requests by risk. High-risk changes require human review, medium-risk changes can receive slower and more expensive AI review, and low-risk work can take a faster automated path. He also argues for small PRs because both human and AI review quality can deteriorate on very large changes.

Other practices include using multiple specialized subagents for code review, maintaining skills and written knowledge for agents, using fresh context for new tasks, keeping durable task tracking outside an agent's temporary context, and continuously reviewing past work to improve the development system.

The article describes one engineer's experimental workflow inside Lovable. It should not be interpreted as a recommendation that ordinary users spend comparable amounts on tokens or maximize output volume for its own sake.

Original Source

Read the original announcement

What This Means for Lovable Users

Most Lovable users will not need anything close to this engineering setup, but several principles translate well to normal projects.

First, large tasks benefit from decomposition. Asking an agent to make one enormous change can make implementation and review harder. Smaller, clearly scoped steps are easier to understand, test, and reverse.

Second, review effort should match risk. A copy change and an authentication change should not receive the same level of scrutiny. Even non-developers can use this principle by explicitly telling Lovable to slow down and explain high-risk changes involving authentication, payments, permissions, infrastructure, or sensitive data.

Third, reusable instructions matter. The article describes skills, knowledge files, and style guidance as important context for agents. When an AI repeatedly makes the same mistake, improving the instructions may be more useful than correcting the output every time.

What This Means for Lovable and the Broader Community

The article illustrates how software engineering may change when code generation is no longer the primary bottleneck. Attention, verification, context management, and risk classification become more important as agents can produce more changes than a person could realistically inspect line by line.

It also challenges the idea that higher agent output automatically equals higher productivity. Lebedev explicitly warns against token spending for its own sake and argues that outcomes matter more than activity.

For engineering organizations, one unresolved issue is knowledge sharing. Traditional code review helped engineers learn from each other and spread architectural conventions. If AI handles more review, teams need other mechanisms for preserving those organizational benefits.

Ways You Could Use This

Break Large Features Into Smaller Changes

Reduce the amount of context and risk carried by one implementation step.

Before implementing this feature, split it into small independently testable changes. Explain the dependency order and define a validation step after each change.

Classify Changes by Risk

Apply stronger review to authentication, infrastructure, permissions, and other sensitive areas.

Classify the proposed changes as low, medium, or high risk. Treat authentication, authorization, payments, secrets, database permissions, and infrastructure as high risk unless there is a strong reason not to. Explain the review required for each.

Use Subagents for Focused Review

Different agents can inspect correctness, security, performance, and reuse separately.

Use subagents to review this change independently for correctness, security, performance, accessibility, and unnecessary duplication. Aggregate and deduplicate the findings before proposing fixes.

Turn Repeated Workflows Into Skills

Reusable agent instructions can reduce repeated prompting.

Review the workflows we have repeated in this project and identify which would make good focused Lovable Skills. Draft only the highest-value skill first and give it clear activation boundaries.

If you need help implementing, reviewing, troubleshooting, or planning a production Lovable project related to this update, expert Lovable assistance is available through PromptSites.com.

Should Existing Lovable Users Do Anything?

There is nothing users need to enable based on this article.

For complex projects, consider adopting three ideas immediately: break large changes into smaller units, explicitly increase review depth for high-risk work, and turn repeated instructions into reusable project knowledge or Skills. Do not optimize for token consumption or number of changes shipped; optimize for useful, verified outcomes.

Key Takeaway

The $85,000 figure is attention-grabbing, but the article's useful lesson is about managing abundant AI output. As agents produce more code, the scarce resources become human judgment, good context, verification, and risk management. The workflow described is an advanced internal experiment, not a spending target for Lovable users.