Blog Post

What Lovable's New Subagents Actually Do

Lovable shipped subagents, AI helpers that run research, review, and QA in parallel inside the builder.

What Lovable's New Subagents Actually Do - Blog post featured image

Anyone who has watched an AI coding assistant work on a real project knows the failure mode. It starts strong. Then somewhere around hour two, it forgets which file it was editing, contradicts an earlier decision, or starts patching things that did not need patching. What is happening is simpler than it looks. The model's context window fills up with noise, and quality drops as a result.

Lovable, the popular AI app builder, recently shipped a feature called subagents that addresses this directly. The idea is simple. Instead of one agent juggling research, code exploration, writing, review, and testing inside a single conversation, Lovable now spins up smaller helper agents in the background. Each one handles a specific job and reports back.

What a subagent actually does

When the main agent needs to understand a section of the codebase before making a change, it can dispatch a subagent to go look. That subagent has its own fresh context window, reads what it needs, and returns a short summary. Same for research tasks, code review passes, and QA checks. The main agent stays focused on the build itself, the way a lead engineer delegates investigation to a teammate instead of reading every file personally.

Why isolated context matters

Large language models pay attention to everything in their context. Drop in a thousand lines of unrelated code while the model is trying to write a function, and the quality drops. This is called context dilution, and it is one of the main reasons long AI coding sessions deteriorate.

Subagents fix this by keeping the noisy work in separate sessions. The main agent never sees the raw research or the full file dump. It only sees the conclusion. For technical readers, this resembles how distributed systems handle complexity, isolating heavy work into specialized processes and passing back only the result.

There is also a safety property baked in. Subagents in Lovable are read-only. They can look, but they cannot edit. A research agent cannot accidentally rewrite your authentication logic while trying to understand it. Only the main agent makes changes, and it does so with the cleaned-up summary in hand.

The cost and speed angle

Running an AI assistant gets expensive when every task uses the most capable model. Subagents open the door to mixing models intelligently, with lighter work like summarization on cheaper, faster ones while the main agent stays on the top-tier model. Parallelism helps too, since three subagents working at once finish faster than one doing the same job in sequence, and the gap compounds on larger apps. Lovable surfaces all of it in the build log, so users can see what was researched, reviewed, and checked.

What this means for teams shipping with AI

Every serious AI coding tool is moving toward this pattern. Cursor, Claude Code, and Replit have variations already. Lovable adopting it signals that the no-code crowd now needs the same architecture as the developer-facing tools, because their users are building bigger things.

For founders evaluating these tools, the question worth asking is no longer whether it can write code. What matters now is how it manages its own attention as the project grows. Subagents are one answer. They will not be the last.

Tools will keep getting better at this. They still cannot decide what to build, why it matters, or how it should scale past the first working version. That part of the work has not been automated, and probably will not be for a while. If you are building something where those decisions actually matter, Axentia is the studio for it. We are at axentia.in.

Explore More Articles

Discover other insightful articles and stories from our blog.