Eine Sprach-App mit einem Team aus Agenten bauen

Chelar ist eine Vorrats-App, mit der man spricht. Sie sagen „I took 5 rolls from the cellar and put them in the bathroom“ (Chelar versteht Rumänisch und Englisch), und der Bestand wandert vom Keller ins Bad, für alle in der Familie. Gebaut wird sie fast vollständig von Coding-Agenten. Nicht von einem Agenten in einem langen Chat, sondern von einem kleinen Team mit festen Rollen, jede mit eigenen Regeln.

Die Rollen

• Architekt. Nur lesend. Für Tickets, die es brauchen, schreibt er vor jedem Code eine kurze Notiz zum Mechanismus: wie jeder Schreibvorgang und jeder Retry funktioniert, was gelten muss, wenn Events doppelt oder in falscher Reihenfolge ankommen, und welche Fehlerfälle die Tests zeigen müssen.
• Entwickler. Arbeitet testgetrieben, auf eigenem Branch, in einer eigenen Kopie des Repositorys. Sein Bericht ordnet jedem Akzeptanzkriterium den Test oder Flow zu, der es belegt, und listet, wo er unsicher ist.
• Reviewer. Nur lesend. Prüft den Code gegen die Standards des Projekts und gegen das Ticket und vergleicht Screenshots aus der CI mit dem Design-Board.
• Security-Reviewer. Nur lesend, parallel zum Reviewer. Ausschließlich Zugriffsregeln, Authentifizierung und Datenschutz.

Keiner der Reviewer ist je die Sitzung, die den Code geschrieben hat. Eine Korrekturrunde startet einen frischen Entwickler, und jeder Befund bekommt einen fehlschlagenden Test, bevor er einen Fix bekommt.

Ein Ticket, von Anfang bis Ende

1. Ein Ticket mit Akzeptanzkriterien, aus einer größeren Spezifikation herausgeschnitten, mit verknüpften Abhängigkeiten.
2. Prüfungen vor dem Start. Zum Beispiel: Jeder Screen, den das Ticket berührt, muss bereits auf dem Design-Board existieren.
3. Ein optionaler Design-Durchgang, dann der Entwickler, dann ein Pull Request.
4. Beide Reviewer parallel. Die offenen Zweifel des Entwicklers gehen zur Beurteilung an beide.
5. Korrekturrunden, bis nichts über „low“ übrig ist; dann muss die CI grün und der Branch aktuell sein, bevor gemergt wird.

Höchstens zwei Tickets laufen gleichzeitig, und nur wenn sie keine Tabellen, Komponenten oder Screens teilen.

Wie drei Wochen aussahen

Vom ersten Commit am 3. Oktober bis zum 23. Oktober:

• 64 Tickets liefen durch die Review-Schleife, in 142 Review-Runden.
• Nur 13 davon (20 %) wurden nach dem ersten Review gemergt. Der Rest ging mindestens einmal zurück; die meisten brauchten zwei Runden, das schlimmste fünf.
• Die Reviewer meldeten 49 Befunde der Stufe hoch oder kritisch und 25 Regressionen, bevor irgendetwas den Hauptbranch erreichte.
• Rund 100 gemergte Pull Requests und etwa 35.000 Zeilen TypeScript und SQL.

Die 80 % sind die Zahl, die mich interessiert. Ein Agent, der Code schreibt, ist schnell und selbstsicher. Ein zweiter Agent, der ihn nicht geschrieben hat, mit engem Auftrag und dem Ticket in der Hand, macht dieses Tempo erst brauchbar.

Die Tests tragen die Last

Etwa 120 Testdateien: Unit- und Komponententests sowie Datenbanktests, die prüfen, wer welche Zeilen lesen darf. Dazu laufen 17 End-to-End-Flows auf Android-Emulatoren in der CI, aufgeteilt in zwei parallele Ketten, jede mit eigenem Emulator und eigenem lokalen Backend. Die Spracherkennung ist in diesen Läufen durch einen Stub ersetzt: Er „hört“ einen festen rumänischen Satz, sodass der Flow ohne Mikrofon getestet wird.

Jeder Merge auf main spielt Datenbankmigrationen ein, deployt die Serverfunktionen und baut ein signiertes Android-Paket.

Was schiefging

Anfangs wurden mehrere Screens nach einer schriftlichen Beschreibung oder einem groben Mock gebaut statt nach einem fertigen Design. Die Agenten taten, was ihnen gesagt wurde, und die Screens passten nicht zum Rest der App.

Die Lösung war eine Regel, kein besserer Prompt: Kein UI-Ticket startet, bevor sein Design-Board existiert, sowohl im Design-Canvas als auch als eingefrorene Kopie im Repository. Reviewer vergleichen CI-Screenshots mit diesem Board, und eine unerklärte Abweichung zählt als Befund.

Wiederkehrende Fehler kommen in eine Datei mit Stolperfallen, je eine Zeile. Entwickler lesen sie, bevor sie Code schreiben; Reviewer behandeln sie als Standard. Eine Zeile daraus: Eine Rückgängig-Meldung, die aus dem Bildschirm scrollt, führt eine Aktion aus, die niemand gesehen hat; alles mit Countdown bleibt also sichtbar oder pausiert.

Was sich auf Kundenprojekte übertragen lässt

Dieselbe Struktur funktioniert auch außerhalb einer Haushalts-App. Bevor ein Agent Code schreibt, wird festgelegt, was er anfassen darf, was „fertig“ in Tests bedeutet und wer prüft. Dann prüft ein anderer Agent die Arbeit, und am Ende ein Mensch.

Als Nächstes in diesem Setup: Sprach-Prompts gegen aufgenommene Sprachclips bewerten, bevor sie ausgeliefert werden. Das ist noch ein Ticket, kein Ergebnis.