Zwei Jahre KI im selben Projekt: was sich an unserer Art, Software zu entwickeln, wirklich geändert hat

Erfahrungsberichte über „die KI, die programmiert“ sind selten arm an Begeisterung und oft arm an Zahlen. Wir haben ein Projekt, an dem wir es umgekehrt machen können: BuyStep, ein B2B-Marktplatz für Energie, dessen Plattform wir seit Sommer 2024 entwickeln. Das Git-Repository hält alles fest, was dort passiert ist, auch wie die KI-Unterstützung in das Projekt kam. Das erzählen diese Spuren, ohne Hype.

Das Projekt: 1.706 Commits, drei Stacks, zwei Datenbanken #

Zwischen dem 23. Juli 2024 und dem 5. September 2026 verzeichnet das Repository 1.706 Commits und 140 Merges in den Produktionszweig. Die Plattform hat dreimal ihre Basis gewechselt: ein Blazor-Server-Monolith auf MySQL und .NET 8, dann .NET 9, dann ein Monorepo mit einer .NET-10-API, einem Next.js-16-Portal und PostgreSQL. Die Datenbankmigrationen wurden viermal zurückgesetzt. Mit anderen Worten: Das ist kein Demoprojekt, sondern eine Geschäftsanwendung mit bewegter Geschichte.

Eine einfache Kennzahl fasst den Verlauf zusammen: die Zahl der Commits pro Monat. Im ersten Jahr schwankt sie zwischen 25 und 70. Im Oktober 2025 steigt sie auf 274, dann im April 2026 auf 341. Diese beiden Spitzen sind kein Zufall: Jede entspricht einem Methodenwechsel.

Paradigma 1: der Assistent, der vervollständigt (2024 → Mitte 2025) #

Im ersten Jahr ist die KI eine Tipphilfe. Sie schlägt Zeilen vor, manchmal Methoden, nie eine Architektur. Im Repository hinterlässt sie keine Spur: keine Anweisungen, kein generierter Bericht, von Hand geschriebene Commit-Nachrichten auf Französisch, oft unter Zeitdruck („Problème d'update de folder résolu“, also „Problem beim Ordner-Update gelöst“, oder „Changement de PC pour continuer à bosser“, also „PC gewechselt, um weiterzuarbeiten“).

Das Tempo ist das eines einzelnen Entwicklers an einem Produkt, das seine Form noch sucht. Im Juni 2025 streicht ein Commit „nicht gepflegte“ Tests: das klassische Zeichen eines Teams, das schneller ist als seine Schutzmechanismen. Wir halten das fest, ohne es zu bewerten, denn genau das hat das nächste Paradigma korrigiert.

Paradigma 2: Das Repository wird zum gemeinsamen Kontext (Oktober 2025) #

Im Oktober 2025 tauchen in derselben Woche drei Dinge im Repository auf: eine Anweisungsdatei für den Assistenten (CLAUDE.md), ein Konfigurationsordner für ihn und eine Reihe von Analyseberichten, die er geschrieben hat (API-Dienste, clientseitige Migration, Produkttests). Im selben Monat wird die Konfiguration vollständig auf Umgebungsvariablen umgestellt, die Anwendung dockerisiert, die Migrationen werden neu aufgesetzt und ein Seed-Datensatz wird geschrieben.

Das Volumen steigt von 66 Commits im September auf 274 im Oktober. Die wichtige Änderung ist aber nicht das Volumen, sondern dass Dokumentation für die KI zugleich Dokumentation für das Team ist. Konventionen, Build-Befehle und die erwartete Architektur sind jetzt aufgeschrieben, versioniert und werden in jeder Sitzung gelesen. Das Projekt ist für jemanden lesbar geworden, der es nicht geschrieben hat, ob Mensch oder nicht.

Paradigma 3: die Spezifikation vor dem Code (März 2026) #

Im Frühjahr 2026 wird die Umsetzung billig. Ein Ordner mit versionierten Spezifikationen (Lieferantenaudit, Scoring, Abläufe für Käufer und Lieferanten) geht dem Code voraus. Ein Plan zur Umstrukturierung des Repositorys wird am 26. März geschrieben und noch am selben Tag umgesetzt: Die gemeinsamen Bibliotheken kommen nach libs/, die Anwendungen nach apps/, der alte Monolith nach legacy/. Zwei Tage später wechselt die Datenbank von MySQL zu PostgreSQL und das Framework von .NET 9 zu .NET 10. Am Tag darauf verzichten die Integrationstests auf die In-Memory-Datenbank zugunsten eines echten, kurzlebigen PostgreSQL, und Architekturtests prüfen, dass die Schichten nicht übersprungen werden.

Das Next.js-Portal entstand am 18. März mit einem Commit namens „Add base react homepage rebuild“. Einen Monat später stellte es den Katalog, die Lieferantenprofile, die Authentifizierung und die Zahlungsabwicklung bereit.

Wenn Code zu schreiben weniger kostet, verlagert sich der Wert auf zwei Dinge: die Absicht (was genau wollen wir?) und die ausführbaren Schutzmechanismen (woran merken wir, dass es falsch ist?). Die Tests gegen eine echte Datenbank und die Architekturtests kamen nicht zufällig in dem Moment, in dem die Menge an generiertem Code explodierte: Sie sind die Voraussetzung dafür, diese Menge zu akzeptieren.

Paradigma 4: der Durchsatz und was er verlangt (April 2026) #

April 2026: 341 Commits, fast tägliche Merges in die Produktion, konventionelle Commit-Nachrichten auf Englisch, eine ganze Funktion entfernt, „weil sie nicht mehr genutzt wird“, die AutoMapper-Mappings durch zur Kompilierzeit generierten Code ersetzt, die Blazor-Administration durch eine Next.js-Anwendung ersetzt und der Altcode am 12. April gelöscht. Ein Monat Arbeit, der zwei Jahre zuvor vier oder fünf Monate gebraucht hätte.

Das Risiko dieses Durchsatzes ist bekannt: Das Review kommt nicht mehr hinterher. Unsere Antwort war mechanisch statt heldenhaft: kurze Pull Requests, Unit-Tests, die in zwei Sekunden laufen, Integrationstests in dreißig, eine fünfstufige Pipeline, die alles blockiert, was etwas kaputt macht. Und eine Verhaltensregel für den Assistenten: wahrheitsgetreu berichten. Schlägt ein Test fehl, das mit der Ausgabe sagen; wurde ein Schritt übersprungen, auch das sagen.

Paradigma 5: Agenten, die Agenten orchestrieren (September 2026) #

Für diesen Artikel haben wir ein Werkzeug gebaut, das alte BuyStep-Commits in Docker-Containern nachbaut (.NET SDK 8, 9 oder 10 je nach Zeitraum, MariaDB oder PostgreSQL), die damaligen Migrationen anwendet, Daten einspielt, die Anwendung startet und ihre Seiten fotografiert. Geschrieben hat es ein Team von Agenten in einer Sitzung: fünf für die parallele Umsetzung, pro Modul ein Reviewer mit dem Auftrag zu widersprechen, ein Integrator, der das Ganze tatsächlich ausgeführt hat. Elftausend Zeilen in einer Stunde.

Dann haben wir es auf echte Commits angesetzt. Vier Fehler tauchten auf, die kein Review gesehen hatte: eine Seite, die in einem inneren Container scrollte und abgeschnitten herauskam, eine Migration, die eine EF-Factory verlangte, die es in diesem Zeitraum nicht gab, ein Indexierungsdienst, der die Anwendung anhielt, wenn Elasticsearch fehlte, ein Port, den schon ein anderes Projekt belegte. Jeder Fehler war in wenigen Minuten behoben, weil die Diagnose an einer laufenden Anwendung stattfand. Die Prüfung durch Ausführung bleibt die einzige, die zählt, und sie bleibt Menschenarbeit mit Unterstützung, keine Arbeit für einen Agenten allein.

Was wir daraus mitnehmen #

• Der Vertrag vor dem Code. Ein Dokument, das Schnittstellen, Datenformate und Verhaltensregeln festlegt, bringt mehr für die Qualität als jeder Prompt.
• Schutzmechanismen müssen ausgeführt werden. Tests gegen eine echte Datenbank, Architekturtests, eine blockierende Pipeline: Was nicht automatisiert ist, gibt unter der Menge irgendwann nach.
• Für die KI dokumentieren heißt für das Team dokumentieren. Beide Zielgruppen brauchen dasselbe: explizite Konventionen, reproduzierbare Befehle, datierte Entscheidungen.
• Durchsatz bezahlt man mit Review und Tokens. Modelle nach Aufgabe zu verteilen und Pull Requests kurz zu halten, ist nicht optional.
• Nichts ersetzt die Ausführung. Ein Agent kann schreiben und prüfen; was fehlt, findet man, indem man das System startet.

Wir wenden diese Methode in unseren Projekten an, mit .NET wie mit Next.js. Wenn Sie sich fragen, was KI Ihrem Team bringen kann, ohne zur Blackbox zu werden: Unser Ansatz ist hier beschrieben, und wir sagen Ihnen ehrlich, wann sie nichts bringt.