Skalierung agentischen Programmierens auf 150+ PRs/Woche: Lehren aus 85.000 $ Tokens bei Lovable

Alexander Lebedev kam im Januar 2026 zu Lovable, kurz nach dem Boom der KI-Coding-Agenten. Bis Juni hatte er von einem einzelnen Entwickler mit ein paar Agenten, die 20–30 gemergte PRs pro Woche erstellten, auf einen Menschen skaliert, der 6–7 Agenten (jeder mit eigenem Subagenten-Schwarm) beaufsichtigt und über 150 gemergte PRs pro Woche liefert. Die Kosten: ~25.000 $/Monat im Mai, insgesamt ~85.000 $ für Tokens seit Januar. So hat er es gemacht – und was dabei schiefging.

Von 30 auf über 150 PRs/Woche: Die Architektur

Im Januar war der Prozess traditionell: Plan-Modus, Genehmigungsanfragen, klassisches menschliches Code-Review. Bis Juni hatte Lebedev einen eigenen Agenten entwickelt, der Aufgaben für andere Agenten schreibt, mit mehreren Ebenen von Implementierungs- und Review-Agenten. Große Änderungen werden nun als 10-PR-Stapel statt als einzelne PR ausgeliefert. Menschliche Reviews betreffen nur wichtige Entscheidungen, selten den Code selbst.

Wohin die Tokens fließen: 75% Implementierung, 25% Automatisierung

Der Großteil der 85.000 $ – etwa 75% – fließt direkt in die Implementierung (Code-Erstellung). Die restlichen 25% (und wachsend) finanzieren Automatisierung: KI-Reviews außerhalb der Entwicklungsumgebung, Post-Merge-KI-Reviews und routinemäßige automatisierte Aufgaben. Lebedev sagt voraus, dass der Anteil der Automatisierung weiter steigen wird, da mehr Arbeit aus dem Code-Erstellungs-PR-Zyklus ausgelagert wird.

Menschliches Review: Ausnahme, nicht Regel

Lebedev argumentiert, dass zeilenweise Reviews von KI-generiertem Code genauso unpraktisch sind wie das Reviewen von Compiler-Output nach dem Wechsel von Assembler zu höheren Sprachen. Stattdessen bleiben menschliche Reviews den wichtigsten Änderungen vorbehalten – meist nicht bei PRs, sondern auf RFC/ADR-Ebene: Systemdesign-Diskussionen, Whiteboard-Sessions, Infrastrukturentscheidungen. Eine einzige Designentscheidung kann größere Auswirkungen haben als 50 Implementierungs-PRs.

Der Nachteil: Code-Review war ein Lernwerkzeug und ein Mechanismus zur Wissensweitergabe. Die Engineering-Abteilung braucht jetzt neue Wege, um diese sekundären Effekte zu erhalten. Lebedev gibt zu: „Ich sehe noch keine guten Lösungen, nur Raum für neue Experimente.“

Änderungsrisikoklassifizierung: Das Sicherheitsnetz

Menschliche Reviews naiv zu umgehen, funktioniert im großen Maßstab nicht – besonders für Neueinsteiger, die nicht wissen, was sie nicht wissen. Lebedev baute einen KI-Workflow, der jede PR nach Risikostufe klassifiziert und bei hohem Risiko ein menschliches Review erzwingt. Der Klassifizierer verwendet:

• Eine einzelne Markdown-Richtliniendatei, die vom Agenten gelesen wird und den PR-Diff sowie Metadaten inspiziert.
• Klassifizierungsdimensionen: Größe, Risikostufe, Code-Besitz (gehört die Mehrheit des geänderten Codes zum Team des Autors?).
• Hochrisikokategorien: Infrastruktur, Authentifizierung, große Diffs, Produktionsfunktionen.
• Niedrigrisikobeispiel: Veröffentlichung eines Blogbeitrags.

Das Klassifizierungsergebnis wird an ein deterministisches Tool weitergegeben, das die Richtlinie über GitHub-Aktionen und Branch-Regelsets anwendet, um Merging zu erlauben oder zu verweigern.

Wichtige Erkenntnis

Agentisches Coding zu skalieren erfordert nicht nur mehr Agenten, sondern strukturelle Veränderungen: Aufgaben-generierende Agenten, PR-Stapelung, automatisierte Risikoklassifizierung und eine bewusste Verlagerung der menschlichen Aufmerksamkeit von zeilenweisen Reviews hin zu Entscheidungen auf Architekturebene. Die Token-Rechnung von 85.000 $ ist eine Investition, um zu beweisen, dass das Modell funktioniert – aber die schwierigen Probleme (Wissensaustausch, Onboarding) bleiben ungelöst.