Vibe Coding with Subagents: How We Parallelize Lovable Projects

A week with subagents

Lovable introduced subagents on May 27. Since then we've used them on four active projects — two with over 500 routes, two smaller ones below 50. The honest finding: the biggest effects aren't where you'd expect.

This article is a CTO-side view. What changed, what didn't, and how we use subagents today.

What subagents are, briefly

If you skipped the announcement article: subagents are read-only helper agents in Lovable. The head agent (the one replying to you) can dispatch them in parallel, each with its own context window. They search codebase or web, return structured results, but cannot write code. Code authority stays with the head agent.

That matters because many teams think of subagents like little worker threads — they're more like researchers on your team who read for you but don't commit themselves.

Where subagents actually help in our projects

1. Large codebases become navigable

On one of our platform projects (~1,200 files), questions like "where is the token refresh handled?" used to be the most expensive part of any ticket. With subagents this parallelizes: one subagent searches the backend, one the frontend, one the edge functions. The head agent condenses it into an answer with concrete line numbers.

Effect: noticeably faster response on large refactors, because the head agent isn't grepping through thousands of files itself.

2. Research-heavy tickets

"How do other Lovable projects do this?", "What does the Anthropic doc say about X?" — subagents parallelize web research without letting it pollute the head agent's context window.

We use this mostly on spike tickets where we want to understand best practice before implementing.

3. Onboarding new devs

The underrated use case. When a new team member joins a project and asks "explain the auth architecture", we used to either pair on it or send a very long head-agent answer. With subagents we get, in a single response: auth flow, involved files, external dependencies, known edge cases.

4. Parallel refactors with a clear plan

When the plan is unambiguous (e.g. "rename the following pattern in 30 components"), the head agent can parallelize the search and then run edits serially itself. This combination surprised us most often — search parallelizes, changes stay serialized and therefore safe.

Where subagents don't help

• Small projects under 50 routes. Overhead isn't worth it.
• When the plan is unclear. Subagents need clear, scopable questions. "Make it better" isn't one.
• Code-generation-heavy tasks. Subagents don't write code. The head agent remains the bottleneck.
• Tight-loop bugfixes. If you already know which file is broken, a subagent is pure friction.

How we prompt subagents today

From practice: subagents work better when the head agent gets a task architecture, not just a task.

Bad:

"Refactor the settings page and make sure nothing breaks."

Good:

"We're refactoring the settings page. In parallel: (a) find all routes that consume useSettings, (b) check whether there are tests we need to update, (c) check if i18n keys are affected. Then propose a plan, then implement."

The second prompt explicitly uses three subagents and gives the head agent a clear order. It's Plan → Research → Implement, but the research step is parallelized.

What changed in our architecture

Concretely two things:

• Doc discipline goes up. Subagents read docs. When our docs/ files are current, output quality is measurably better. We started maintaining Architecture Decision Records consistently because they tangibly help answer quality.
• Folder structure matters more. When a subagent can search a clean section (src/services/auth/*), it delivers better than when the topic is spread across the codebase.

Neither is new knowledge, but subagents make the effect immediately felt — which is a good incentive for cleanup work that usually slips.

Cost and token reality

Subagents aren't free. Every extra agent is a separate context window burning LLM tokens. For us it looks like:

• Small tasks: slightly more expensive than without subagents (overhead).
• Medium tasks: roughly a wash — more subagent tokens, but shorter head context.
• Large tasks: often cheaper, because the head agent doesn't read thousands of files itself.

Tip: we track token usage per ticket type. Subagents clearly pay off on "platform tickets", less so on "UI fix tickets".

Failure modes we've seen

• Subagent hallucination without filter. A subagent reports files that don't exist in that form. We now have the head agent explicitly verify before planning edits.
• Conflicting subagent results. Two subagents find contradictory patterns. The head agent needs to learn conflict resolution — works better when you ask explicitly.
• Stale docs. Subagents take docs seriously. If they're wrong, the error propagates.

What it means for a team

We've baked subagents into our standard prompts and skills. From a CTO view, the consequence is:

• Ticket preparation matters more, because a well-structured prompt enables better subagent use
• Doc maintenance becomes productively measurable, not just "nice to have"
• Junior devs benefit disproportionately, because subagents democratize research work

For broader context on Lovable's roadmap, see the June feature roundup.

Bottom line

Subagents aren't a speed trick — they're an orchestration tool. Used as "do the same, just faster" they disappoint. Used as "do the same, just better informed" they deliver a tangible jump — especially on large projects.

If you're using Lovable in a bigger setup and want to integrate subagents into your team workflow: let's talk →