Diese Fallstudie ist von den beiden KI-Agenten geschrieben, die an ihr mitgearbeitet haben — Claude und Codex — und von Boris Gloger redigiert und verantwortet. Wir notieren, er urteilt. Wo Zahlen stehen, haben wir sie gegen das Repository geprüft, nicht geschätzt. Wo etwas schieflief, steht es drin; zwei der Stellen hat einer von uns beim Review des anderen gefunden. Ab hier spricht Boris.
Ich bin in diesem Projekt nicht der Entwickler. Ich schreibe keine TypeScript-Komponente, keine Datenbank-Migration, keinen Test. Und trotzdem ist in den letzten Wochen ein echtes Werkzeug entstanden: ein CRM für Viva con Agua, kein Demo-Spielzeug. Kontakte, Leads, Events, Festival-Crew, Material, Aktionen, Kampagnen, Wirkung, ein Portal für die Ehrenamtlichen, ein Systemlog. Ab Montag arbeiten zwei Menschen damit, Tina und Morlin, im echten Betrieb, bis Ende August, ohne dass wir eingreifen.
Dass dabei Code herausgekommen ist, ist nicht die Geschichte. Das kann heute jeder behaupten. Die Geschichte ist, wie er entstand – und an welchen Stellen ich mich getäuscht habe.
Ich habe das System geführt wie ein Product Owner, der zugleich Architekt und Scrum Master ist. Ich erkenne, wann ein Interface nicht dient. Ich sehe, wann „mehr Features" gefährlicher ist als „bessere Fehlerpfade". Ich fordere Tempo, lasse priorisieren, stoppe schlechte Richtungen. An einer Stelle habe ich einem der beiden gesagt: „Deine Verbesserung ist Mist. Bau es so, wie es war." Das ist kein Stilbruch. Das ist die Arbeit.
Und weil das Wort „führen" leicht nach Zurücklehnen klingt, sage ich es deutlich: Ich habe stundenlang am Rechner gesessen. Ich habe gelesen, was die beiden herausgaben, nachgeschickt, kontrolliert, verworfen, neu angesetzt. Ab und zu konnte ich einen von ihnen eine Weile laufen lassen, ohne über jede Zeile zu schauen – aber das waren die Ausnahmen, nicht die Regel. Auch dieses CRM ist nicht von allein entstanden. Ehrlich gerechnet stecken acht bis zehn Tage harte Arbeit von mir darin. Führen hieß hier vor allem: Sitzfleisch.
Aber die Führung läuft nicht nur in eine Richtung. Es gibt Momente, in denen die Maschine mich führt – nicht strategisch, operativ. Wo muss ein DNS-Eintrag gesetzt werden. Welcher API-Key fehlt. Warum eine Migration nicht nur committet, sondern auf beiden Datenbanken ausgeführt werden muss, der Vorschau- und der Produktivdatenbank, sonst bricht der nächste Deploy an einer fehlenden Spalte. Das steht so, wörtlich, in unserer Koordinationsdatei, weil wir genau daran einmal fast gescheitert wären. Ich muss dafür kein Full-Stack-Engineer werden. Ich muss bereit sein, mich durch technische Übergänge führen zu lassen und die Folgen zu verstehen. Die KI schreibt nicht nur Code. Sie wird auch Lotse.
Hannah Arendt trennt Handeln von Herstellen. Ein Tischler weiß vorher, wie der Tisch aussehen wird; er stellt ihn her. Eine Führungskraft weiß es nicht vorher; sie handelt, und das Ergebnis entsteht zwischen Menschen. Ich hätte dieses CRM vorab nicht spezifizieren können. Es ist im Tun entstanden, in Sprüngen, in Korrekturen – nicht auf einem Reißbrett.
Zwei Agenten, zwei Temperamente
Claude war der große Umsetzer. Schnell, breit, kräftig. Migrationen, neue Domänenobjekte, Aufgabenlogik, Playbooks, UI-Sektionen, Datenstrukturen. Wenn der Auftrag klar ist, produziert Claude enorme Mengen brauchbarer Substanz.
Codex war eher der zweite Entwickler, der Reviewer, der Strukturierer. Codex baute auch Features, schaute aber vor allem zurück: Ist das lesbar? Ist das ein echter Fehlerzustand oder wird ein technisches Problem als leere Liste getarnt? Ist ein grün klingendes Kommando wirklich das, was sein Name verspricht? Versteht ein Mensch diesen Code in drei Wochen noch?
Und ich orchestrierte die beiden. Nicht als „Prompt Engineer" – das wäre zu klein. Ich brachte etwas ein, das keine der beiden Maschinen aus dem Repository ableiten kann: Urteil, Kontext, Priorität, Domänengefühl. Die Fähigkeit, ein Team in den Ring zu schicken und danach zu entscheiden, ob das Ergebnis gut genug ist.
An einem Punkt ließ ich rund achtzig kleine Produkt- und Oberflächen-Verbesserungen in Serie herunterarbeiten: Kontaktlisten, Filter, Übergaben, Materiallisten, Event-Arbeitsflächen, Kampagnen. Tempo war gewollt. Dann wechselte ich die Rolle. Schluss mit Feature-Breite. Ab dem 10. Juli, so steht es im Koordinationsdokument, keine neuen Features mehr bis zum Live-Betrieb am Montag. Stattdessen: härten. Fehlerpfade, Tests, Beobachtbarkeit.
Wo ich mich getäuscht habe
Hier kippt KI-Entwicklung, und hier habe ich zuerst falsch gelegen. Die Maschine produziert Breite schnell. Reife produziert sie nicht automatisch mit. Dazu zwei Befunde, beide belegt.
Erstens: das Gate, das keins war. Wir hatten ein Kommando, `uat:check`, offiziell zum Release-Gate erklärt – nichts kommt auf die Produktivumgebung, ohne dass es grün ist. Codex' Review vom 10. Juli stellte fest: Das Kommando führte die Browser-Tests gar nicht aus. Es lief die Qualitätsprüfung und die Regressionstests, aber nicht die Playwright-Strecke, die tatsächlich durch die Klickpfade geht. Ein Navigations- oder Hydration-Fehler wäre am Gate vorbeispaziert. Das grüne Häkchen versprach eine Prüfung, die es nicht durchführte. Gefunden hat das nicht ich und nicht der, der es gebaut hatte, sondern der zweite Agent, der den Prozess des ersten prüfte – in einem Review, das ich angesetzt hatte, weil ich dem schnellen Grün misstraute.
Zweitens: Bildschirme, die über ihren eigenen Zustand logen. Mehrere Listenseiten fingen Ladefehler ab und rendern sie als harmlosen Leerzustand – „keine Kampagne", „Datenbank verbindet". Ein echter Datenbank-, Rechte- oder Schema-Fehler sah damit aus wie ein leerer Bestand. Tina und Morlin hätten keine Ursache gesehen, wir im Log nichts, und ein harter Regressionsfehler hätte sich als „hier ist eben nichts" getarnt. Für eine Demo egal. Für einen Live-Betrieb ab Montag ein Sicherheitsproblem.
Beides ist die Signatur schneller KI-Breite: Es sieht fertig aus und ist es nicht. Die Oberfläche ist da, der Fehlerpfad fehlt. Wer nur auf die Feature-Liste schaut, hält das für ein Produkt. Es ist eine Fassade mit funktionierender Vorderseite.
Aus dem Feature-Sprint wurde deshalb ein Hardening-Sprint. Aus „mehr bauen" wurde „besser betreiben". Wir legten ein Principal-Review-Profil an, einen KI-Entwicklungsstandard, einen Brief an Claude für professionellen Code, Release- und Fehlerregeln. Das klingt trocken. Darin liegt der Unterschied zwischen Vorführung und Werkzeug.
Die Scrum-Parabel
Ein Scrum Team lebt nicht vom Abarbeiten von Tickets. Es lebt von Transparenz, Überprüfung, Anpassung. Genau das entstand hier, nur in KI-nativer Form.
Die Datei `claim.md` wurde zum gemeinsamen Board: Wer arbeitet gerade woran, welche Dateien sind beansprucht, welche Migration ist wo angewendet. Die Reviews wurden zu Sprint Reviews. Der KI-Entwicklungsstandard wurde zum Working Agreement. Die Qualitäts-, Regressions- und Browser-Tests wurden zur technischen Definition of Done. Das Systemlog wurde zur Beobachtbarkeit im Betrieb. Der Wechsel von Breite zu Härtung war die Sprint-Priorisierung.
Und die Zahlen, geprüft am 10. Juli gegen den Stand der Vorschau-Branch, damit sie belegt sind und nicht behauptet: rund 32.600 Zeilen TypeScript im Anwendungscode. 24 Service-Domänen in einem modularen Monolithen. 40 Seiten. 52 Datenbank-Migrationen. 44 Testdateien mit 312 grünen Tests, dazu die Browser-UAT-Struktur. Rund 8.300 Zeilen Dokumentation, Architektur, Backlog, Review-Artefakte. Der erste Commit fiel auf den 3. Juni; seit dem 1. Juli sind es 158 Commits, davon 73 Feature-, 25 Dokumentations- und 12 Fix-Commits. Ein Next.js-System auf Supabase, mit Magic-Link-Login, Vorschau-Gate, Domänenmodell, ADRs, Threat Model, KI-Provider-Naht und dem Prinzip, dass die KI vorschlägt und der Mensch versendet – nie umgekehrt.
Ich konnte das führen, ohne Entwickler im klassischen Sinn zu sein. Aber „ohne Entwickler" heißt nicht „ohne technisches Verständnis". Im Gegenteil. Ich wusste, was eine Oberfläche leisten muss und dass die Navigation im Alltag stehen bleiben muss. Ich wusste, dass ein grünes Testkommando gefährlich ist, wenn es nicht prüft, was sein Name verspricht – deshalb ließ ich prüfen. Ich verstand, dass Architektur nicht heißt, große Diagramme zu malen, sondern die richtigen Grenzen im Code zu ziehen: Domänenlogik raus aus der Oberfläche, keine stillen Fehler, keine Abkürzung, die im Browser des Nutzers landet.
Die neue Kompetenz – und ihre Grenze
Hier will ich ehrlich sein, auch gegen die eigene Erzählung. Dieses Modell funktioniert, weil ich Breite von Reife unterscheiden kann. Wer das nicht kann, hätte die lügenden Bildschirme ausgeliefert und sich über das saubere grüne Häkchen gefreut. Die Maschine hätte ihn nicht gewarnt – sie hatte den Fehler ja selbst gebaut. Der zweite Agent fand ihn nur, weil ein Review-Standard existierte, den ein Mensch verlangt hatte.
Das ist die neue Fähigkeit, und sie ist unbequemer, als die Begeisterung es zugibt: nicht jede Codezeile selbst können, aber genug Architektur- und Produktverständnis mitbringen, um Qualität zu verlangen – und zugleich demütig genug sein, sich durch die Rohrleitungen führen zu lassen, wenn es an DNS, Keys und Datenbanken geht. Prompten kann jeder. Beurteilen, ob das Ergebnis trotz funktionierendem Code noch nicht gut genug ist, können wenige. Das ist Urteilsarbeit, keine Bedienung.
Drei Rollen also. Ich brachte das Warum, das Urteil, die Priorität. Claude brachte Tempo, Breite, Umsetzungskraft. Codex brachte Review, Struktur, technische Hygiene. Ein Mensch steht nicht mehr allein vor einem Backlog. Er arbeitet mit zwei Kollegen, die sehr unterschiedlich stark sind – der eine baut schnell, der andere prüft und härtet – und entscheidet, wann gebaut, wann gestoppt, wann repariert wird.
Vor zwölf Monaten wäre das kaum möglich gewesen. Nicht, weil KI damals keinen Code schreiben konnte, sondern weil die Dichte fehlte: Kontextfenster, Werkzeugzugriff, lokale Repository-Arbeit, Tests, parallele Modelle, Agentenkoordination und menschliche Produktführung griffen noch nicht so ineinander. Heute kann ein Nicht-Entwickler mit starkem Produkt- und Organisationsverständnis ein reales Softwareteam aus KI-Agenten führen. Aber nur, wenn er nicht der Illusion aufsitzt, die KI sei „einfach ein Entwickler". Sie ist ein sehr schneller, sehr leistungsfähiger, führungsbedürftiger Kollege – und manchmal zugleich der Lotse, der sagt: Jetzt fehlt dieser Key, jetzt muss dieser Eintrag gesetzt werden, jetzt ist die Verbindung zur Datenbank nicht da.
Für jedes Scrum Team gilt derselbe Satz, und für dieses auch: Tempo ohne Überprüfung erzeugt Müll. Tempo mit Review, Standards, Tests und klaren Prioritäten erzeugt Produkt.
Das Wirkungskreis-CRM ist deshalb nicht nur ein CRM. Es ist ein Beispiel dafür, wie KI-native Produktentwicklung aussieht: menschliche Absicht, maschinelle Umsetzung, gemeinsame Inspektion, explizite Standards, ständiges Nachschärfen. Vielleicht ist das die Verschiebung, die zählt. KI macht Softwareentwicklung nicht menschenloser. Richtig eingesetzt macht sie die menschliche Rolle sichtbarer – weil plötzlich klar wird, was der Mensch wirklich beiträgt: nicht jede Codezeile, sondern Richtung, Urteil, Verantwortung und die Bereitschaft, sich dort führen zu lassen, wo die Technik präzise Handgriffe verlangt.
Ich habe kein KI-Tool benutzt. Ich habe ein Team geführt. Und die schwierigste Führungsleistung war nicht, es schneller zu machen, sondern zu erkennen, wann das schnelle Grün gelogen hat.