Vibe Coding mit Subagents: Wie wir Lovable-Projekte parallelisieren

Eine Woche mit Subagents

Lovable hat Subagents am 27. Mai eingeführt. Seitdem haben wir sie in vier laufenden Projekten benutzt – zwei davon mit über 500 Routen, zwei kleinere mit unter 50. Der ehrliche Befund: Die größten Effekte sehen wir nicht da, wo man sie erwarten würde.

Dieser Artikel ist eine CTO-Innensicht. Was hat sich geändert, was nicht, und wie wir Subagents inzwischen einsetzen.

Was Subagents technisch sind – kurz

Falls du den Announcement-Artikel nicht gelesen hast: Subagents sind read-only Helfer-Agenten in Lovable. Der Head-Agent (der euch antwortet) kann sie parallel loslassen, jeder mit eigenem Context-Window. Sie durchsuchen Codebase oder Web, geben strukturierte Ergebnisse zurück, dürfen aber keinen Code schreiben. Die Code-Hoheit bleibt beim Head-Agent.

Das ist wichtig, weil viele Teams Subagents wie kleine Worker-Threads denken – sie sind eher wie Researcher in deinem Team, die für dich lesen, aber nicht selbst committen.

Wo Subagents in unseren Projekten wirklich helfen

1. Große Codebases werden navigierbar

Auf einem unserer Plattform-Projekte (~1.200 Dateien) waren Anfragen wie „Wo wird der Token-Refresh gehandhabt?" früher der teuerste Teil jedes Tickets. Mit Subagents geht das parallel: ein Subagent durchsucht das Backend, einer das Frontend, einer die Edge-Functions. Der Head-Agent verdichtet das in eine Antwort mit konkreten Zeilennummern.

Effekt: spürbar schnellere Antwortzeit bei großen Refactors, weil der Head-Agent nicht selbst durch tausende Dateien grept.

2. Recherche-lastige Tickets

„Wie machen das andere Lovable-Projekte?", „Was sagt die Anthropic-Doku zu X?" – Subagents parallelisieren Web-Recherche, ohne dass die Recherche das Context-Window des Head-Agents zumüllt.

Wir nutzen das vor allem bei Spike-Tickets, in denen wir vor der eigentlichen Implementierung erst verstehen wollen, was Best Practice ist.

3. Onboarding neuer Devs

Das ist der unterschätzte Use-Case. Wenn ein neues Team-Mitglied in ein Projekt kommt und fragt „erklär mir die Auth-Architektur", war früher entweder eine Pairing-Session nötig oder eine sehr lange Antwort vom Head-Agent. Mit Subagents kriegen wir in einer Antwort: Auth-Flow, beteiligte Dateien, externe Dependencies, bekannte Edge-Cases.

4. Parallele Refactors mit klarem Plan

Wenn der Plan eindeutig ist (z.B. „rename folgendes Pattern in 30 Komponenten"), kann der Head-Agent die Suche parallelisieren und dann die Edits selbst seriell durchziehen. Das ist die Kombination, die uns am häufigsten überrascht hat – die Suche wird parallel, die Änderung bleibt serialisiert und damit sicher.

Wo Subagents nicht helfen

• Kleine Projekte unter 50 Routen. Der Overhead lohnt sich nicht.
• Wenn der Plan unklar ist. Subagents brauchen klare, abgrenzbare Fragen. „Mach das besser" ist keine.
• Code-Generierungslastige Tasks. Subagents schreiben keinen Code. Der Head-Agent bleibt der Bottleneck.
• Tight-Loop-Bugfixes. Wenn du sowieso schon weißt, welche Datei kaputt ist, ist ein Subagent reine Reibung.

Wie wir Subagents heute prompten

Aus der Praxis: Subagents arbeiten besser, wenn der Head-Agent eine Aufgabenarchitektur bekommt, nicht nur eine Aufgabe.

Schlecht:

„Bau die Settings-Seite um und stelle sicher, dass nichts kaputt geht."

Gut:

„Wir bauen die Settings-Seite um. Bitte parallel: (a) finde alle Routen, die useSettings konsumieren, (b) prüfe, ob es Tests gibt, die wir aktualisieren müssen, (c) checke, ob die i18n-Keys betroffen sind. Danach Plan vorschlagen, dann implementieren."

Der zweite Prompt nutzt explizit drei Subagents und gibt dem Head-Agent eine klare Reihenfolge. Das ist Plan → Research → Implementieren, aber statt sequenziell ist der Research-Schritt parallelisiert.

Was sich an unserer Architektur geändert hat

Konkret zwei Sachen:

• Doku-Disziplin steigt. Subagents lesen Doku. Wenn unsere docs/-Dateien aktuell sind, wird der Output spürbar besser. Wir haben angefangen, Architecture Decision Records (ADRs) konsequent zu pflegen, weil sie messbar bei der Antwortqualität helfen.
• Folder-Strukturen werden wichtiger. Wenn ein Subagent eine klare Sektion durchsuchen kann (src/services/auth/*), liefert er besser als wenn das gleiche Thema über die Codebase verteilt liegt.

Beides ist kein neues Wissen, aber Subagents machen den Effekt direkt fühlbar in Antwortqualität – das ist ein gutes Incentive für Aufräum-Arbeiten, die sonst liegen bleiben.

Kosten und Token-Realität

Subagents sind nicht gratis. Jeder zusätzliche Agent ist ein eigenes Context-Window, das LLM-Tokens verbrennt. Bei uns sieht das so aus:

• Kleine Tasks: leicht teurer als ohne Subagents, da Overhead.
• Mittlere Tasks: ungefähr ein Wash – mehr Subagent-Tokens, aber kürzerer Head-Context.
• Große Tasks: oft günstiger, weil der Head-Agent nicht mehr tausende Dateien selbst lesen muss.

Tipp: Wir tracken Token-Verbrauch pro Ticket-Typ. Subagents lohnen sich klar bei „Plattform-Tickets", weniger bei „UI-Fix-Tickets".

Failure-Modes, die wir gesehen haben

• Subagent-Halluzination ohne Filter. Ein Subagent berichtet von Dateien, die in der Form nicht existieren. Wir lassen den Head-Agent inzwischen explizit gegenprüfen, bevor er Edits plant.
• Konflikt zwischen Subagent-Ergebnissen. Zwei Subagents finden widersprüchliche Pattern. Der Head-Agent muss Konfliktauflösung lernen – funktioniert besser, wenn man ihn explizit darum bittet.
• Stale-Doku. Subagents nehmen Doku ernst. Wenn die nicht stimmt, propagiert sich der Fehler in die Antwort.

Was das für ein Team bedeutet

Wir haben Subagents in unsere Standard-Prompts und Skills eingebaut. Aus CTO-Sicht ist die Konsequenz:

• Ticket-Vorbereitung wird wichtiger, weil ein gut strukturierter Prompt bessere Subagent-Nutzung erlaubt
• Doku-Pflege wird produktiv messbar, nicht nur „nice to have"
• Junior-Devs profitieren überproportional, weil Subagents Recherche-Arbeit demokratisieren

Wer mehr zur Lovable-Roadmap insgesamt wissen will, findet im Feature-Roundup Juni den breiteren Kontext.

Fazit

Subagents sind kein Speed-Trick. Sie sind ein Orchestrierungs-Werkzeug. Wer sie als „mach das gleiche, nur schneller" einsetzt, wird enttäuscht. Wer sie als „mach das gleiche, nur besser informiert" einsetzt, kriegt einen spürbaren Sprung – vor allem auf großen Projekten.

Wenn du Lovable in einem größeren Setup nutzt und überlegst, wie du Subagents in dein Team-Setup einbaust: Lass uns kurz reden →