Praktische Lehren aus dem Aufbau eines 350.000-Zeilen-Codebases allein mit KI-Agenten

Engineering-Umgebung als Kontext

Das 52-Tage-Projekt des Entwicklers (600 Commits, ~965.000 Codezeilen Durchsatz, 356.000 Zeilen Produktionscode) zeigte, dass die Qualität der Agentenausgabe entscheidend von der Engineering-Umgebung abhängt, nicht nur vom Modell. Die Codebasis selbst dient als Kontextsystem des Agenten, wodurch separate RAG- oder Speicherdateien überflüssig werden.

Klare architektonische Grenzen erwiesen sich als unerlässlich. Die Codebasis folgt einer strikten DDD-Schichtung: Domänenschicht für Datenstrukturen, Serviceschicht für Geschäftslogik, Handlerschicht für HTTP-Formatkonvertierung, mit 22 Domänenmodulen mit klaren Grenzen. Dies sagt den Agenten, wo sie Änderungen vornehmen sollen.

Die Verzeichnisstruktur fungiert als Dokumentation mit abgestimmten Namenskonventionen über alle Stapel hinweg. Für ein Feature wie "Loop": backend/internal/domain/loop/ für Datenstrukturen, backend/internal/service/loop/ für Logik, web/src/components/loops/ für das Frontend. Diese direkte Zuordnung von Produktkonzept zu Codepfad macht es unnötig, dass Agenten die gesamte Codebasis erkunden.

Technische Schuldenverstärkung

Technische Schulden verbreiten sich exponentiell mit KI-Agenten. Wenn Entwickler temporäre Kompromisse eingehen – etwa die Serviceschicht umgehen, um direkt auf die DB zuzugreifen, oder hartcodierte magische Zahlen verwenden – übernehmen Agenten diese Muster systematisch als legitime Ansätze. Im Gegensatz zu menschlichen Ingenieuren, die schlechten Code als Minenfelder erkennen, behandeln Agenten bestehende Muster als gültige Präzedenzfälle.

Die praktische Erkenntnis: Regelmäßiges Refactoring wird unerlässlich, nicht aus ästhetischen Gründen, sondern um die Reinheit des Engineering-Signals zu erhalten. Wenn gute Praktiken dominieren, verstärken Agenten gute Praktiken; wenn Abkürzungen dominieren, verstärken Agenten Abkürzungen. Dies stellt eine einzigartige Wartungskostenkomponente in der agentenkollaborativen Entwicklung dar.

Starke Typisierung als Qualitätssicherung

Die Verwendung von Go + TypeScript + Proto bietet eine Fehlererkennung zur Kompilierzeit, die Agentenfehler von der Laufzeit in die Entwicklungszeit verschiebt. Von Agenten generierte Funktionen mit nicht übereinstimmenden Signaturen führen zu Build-Fehlern. TypeScript erkennt API-Formatinkonsistenzen sofort. Protobuf-generierter Code lässt sich nicht kompilieren, wenn sich Nachrichtenformate ohne Backend-Synchronisation ändern. Diese Fehler würden in schwach typisierten Sprachen in die Laufzeit durchrutschen.

Vier-Schichten-Feedbacksystem

Agenten benötigen vier Feedback-Schichten für effiziente Iteration:

• Kompilierung – Hot-Reload, Go-Neustarts innerhalb von 1 Sekunde, TypeScript-Typfehler in Echtzeit markiert. Beseitigt Syntax- und Typfehler.
• Unit-Tests – 700+ Tests, die Domänen- und Serviceschichten abdecken. Agenten wissen innerhalb von 5 Minuten, ob sie Regressionen eingeführt haben, insbesondere bei Grenzfällen wie Multi-Tenant-Isolation.
• E2E-Tests – End-to-End-Validierung realer Funktionspfade. Fängt Integrationsprobleme auf, die Unit-Tests nicht erreichen.
• CI-Pipeline – Jeder PR führt den vollständigen Test-Suite, Linting, Type-Checking und Multi-Plattform-Build aus. Das letzte Sicherheitsnetz vor dem Merge.

Die vier Schichten bieten zunehmende Latenz und erweiterte Abdeckung: Schicht eins bestätigt Einzelzeilenänderungen, während Schicht vier modulübergreifendes Refactoring validiert.