Ceetrix und Claude Code halfen uns, schnell voranzukommen. Die eigentliche Leistung bestand darin, diese Geschwindigkeit vertrauenswürdig zu machen.
Offenlegung: Ceetrix ist eine Plattform, die von einem engen Freund von mir entwickelt wurde, einem ehemaligen Googler, erfahrenen Chief Product Officer und Experten für agentische KI.
Geschichten über KI-Programmierung feiern oft die Geschwindigkeit und ignorieren dabei die Disziplin.
Das funktioniert so lange, bis die Software beginnt, Arbeitsabläufe zu berühren, die wirklich zählen.
In unserem Fall haben wir Claude Code und Ceetrix genutzt, um ein ernsthaftes B2B-Produkt an einem einzigen Abend voranzubringen. Das wichtige Ergebnis war jedoch nicht einfach, dass Code schnell generiert wurde. Es war, dass die Arbeit von den Anforderungen bis zur Produktionsvalidierung durchgehend gesteuert blieb.
Dieser Unterschied war es, der das Ergebnis nützlich machte.
Beginnen Sie mit Evidenz, nicht mit Begeisterung
Wir haben nicht mit einem offenen Build-Prompt begonnen. Wir begannen mit einem strukturierten Product Requirements Document und einer separaten Gap-Analyse auf Basis einer bestehenden Anwendung.
Der Product-Requirements-Phase ging außerdem der Aufbau des Design Systems voraus, das mit Guardrails in Claude Design abgesichert wurde, bevor der erste Prototyp in Claude Code übertragen wurde. Das behandeln wir in einem weiteren Beitrag.
Das schuf drei konkurrierende Versionen der Wahrheit.
Das PRD beschrieb das beabsichtigte Verhalten. Der Prototyp deutete auf das aktuelle Verhalten hin. Das Repository offenbarte das tatsächliche Verhalten.
Nur eines davon konnte als maßgeblich behandelt werden.
Der erste Schritt war also nicht die Umsetzung. Es war der Abgleich.
Mehrere Bereiche des Produkts waren stärker als erwartet. Andere wirkten in der Benutzeroberfläche vollständiger, als sie es in der zugrunde liegenden Logik waren. Das ist ein häufiger Zustand in wachsender Software, und genau deshalb ist Unternehmensführung wichtig. Wenn man auf ungetesteten Annahmen aufbaut, beschleunigt KI nur das Risiko.
Ceetrix erzwang eine Lieferkette
Ceetrix erzwang einen strukturierten Ablauf:
PRD → Design → Aufgaben → Tests
Dies verhinderte, dass das Team direkt von der Idee zum Code sprang. Jede Anforderung musste zu einem expliziten Design werden. Jedes Design musste konkrete Aufgaben hervorbringen. Jede Aufgabe musste durch Tests und Validierung abgesichert sein.
Das veränderte die Rolle des KI-Agenten.
Statt als schneller Improvisator zu agieren, wurde er zu einem Mitwirkenden, der innerhalb eines nachvollziehbaren Systems arbeitet. Das ist wichtig, weil große Sprachmodelle hervorragend darin sind, plausible Antworten zu erzeugen. Plausibilität ist nützlich, aber sie ist kein Beweis. Dies kommt zusätzlich zu den Schutzmechanismen in unserer CLAUDE.md und den Hooks hinzu.
Ein geregelter Arbeitsablauf verringert die Lücke zwischen beiden.
Die erste Version konzentrierte sich auf operative Integrität
Die erste ausgewählte Produktionsgeschichte war die Währungsverarbeitung. Wir konzentrierten uns zunächst auf die Art und Weise, wie die Anwendung die Währungslogik handhabte, und wählten eine API-Integration, um Währungsänderungen gegen 30 Währungen zu validieren.
Die bestehende Anwendung verließ sich auf fest codierte Werte, was bei einem Prototyp akzeptabel ist, nicht jedoch bei Software, die ernsthafte operative Entscheidungen unterstützen soll. Die Arbeit bestand daher darin, statische Annahmen durch Live-Referenzdaten, sichtbare Anmerkungen und sicherere Fallback-Logik zu ersetzen.
Dabei ging es um mehr als technische Korrektheit.
Wenn ein System eine Zahl umrechnet, sollte es dies sichtbar machen. Wenn es einen Referenzkurs verwendet, sollte es das kenntlich machen. Wenn es auf einen Fallback zurückgreift, sollte dieses Verhalten explizit sein. Gute Unternehmensführung bedeutet, dass das System ehrlich über seine eigene Logik ist.
Die Geschichte wurde implementiert, getestet und in einer realen Umgebung validiert, anstatt allein aufgrund der Codegenerierung als abgeschlossen betrachtet zu werden.
Die Validierung deckte ein akutes Sicherheitsproblem auf
Während der Release-Validierung stellten wir fest, dass ein öffentlich zugänglicher Einstellungspfad mehr Informationen preisgab als beabsichtigt. Bei genauerer Prüfung schien das Problem ein sensibles Wertmuster zu betreffen und erforderte daher eine sofortige Eindämmung.
Die betreffenden Daten wurden korrigiert, der offengelegte Pfad wurde eingeschränkt, und die umgebenden Schutzmechanismen wurden verbessert, damit dieselbe Art von Problem seltener erneut auftritt. Diese Episode zeigte etwas Wichtiges über geregelte Bereitstellung. Wenn Teams sorgfältig gegen reales Verhalten validieren, treten Probleme zutage, die schnellere, aber weniger strukturierte Arbeitsabläufe möglicherweise vollständig übersehen würden.
Die Lehre daraus war nicht, dass die KI eigenständig „Sicherheit gemacht“ hat.
Die Lehre war, dass ein nachvollziehbarer, evidenzbasierter Arbeitsablauf es schwierig machte, dass das Problem verborgen blieb.
Die zweite Geschichte stärkte das Verhalten der Einstellungen
Eine zweite Produktionsgeschichte konzentrierte sich auf die Verarbeitung von Einstellungen und Präferenzen. Kuratierte Auswahlmöglichkeiten wurden ordnungsgemäß durchgesetzt, Präferenzen wurden zuverlässiger gespeichert, und wichtige Änderungen wurden nachvollziehbar. Im Rahmen der End-to-End-Validierung wurden auch kleinere Verhaltensprobleme korrigiert.
Diese Art von Arbeit erzeugt selten spektakuläre Schlagzeilen, verbessert jedoch die Vertrauenswürdigkeit erheblich.
Das ist der übergeordnete Punkt. Ernsthafte Softwarequalität verbessert sich oft durch kumulative Integritätsgewinne und nicht durch spektakuläre Funktionen.
Die Kontrollgrenze war ebenso wichtig wie der Code
Während der gesamten Sitzung konnte der KI-Agent analysieren, entwerfen, implementieren, testen und erklären. Aber er überschritt keine unumkehrbaren Grenzen ohne Genehmigung.
- Vor dem Commit hielt er inne
- Vor der Bereitstellung hielt er inne
- Bevor er produktionsähnliche Daten berührte, hielt er inne
Das ist keine Ineffizienz. Es ist ein funktionales Kontrollmodell.
In jeder ernsthaften Betriebsumgebung müssen Fähigkeit und Befugnis getrennt bleiben. Die KI-unterstützte Produktentwicklung sollte derselben Regel folgen.
Fazit
Am Ende der Sitzung hatten wir bedeutende Verbesserungen ausgeliefert, das betriebliche Verhalten verschärft, ein aktives Problem aufgedeckt und gelöst und das umfassendere MVP über einen klareren, strukturierten Weg vorangebracht.
Aber das wichtigere Ergebnis war konzeptioneller Natur.
KI hat die Produkt-Unternehmensführung nicht ersetzt.
Es machte eine disziplinierte Produkt-Unternehmensführung mit viel höherer Geschwindigkeit möglich.
Das ist eine weitaus dauerhaftere Geschichte als ein weiteres Beispiel für schnell generierten Code.
Die Frage für die KI-unterstützte Lieferung lautet nicht mehr, ob ein Modell bauen kann. Es geht darum, ob Ihr Prozess genug Nachweise schafft, um dem zu vertrauen, was gebaut wird. Es geht darum, wo Sie Nachweise verlangen, bevor Sie dem vertrauen, was sie getan haben. Steuern Sie Ihre Produktlieferung heute? Schauen Sie sich Ceetrix an.
Ich werde Sie auf dem Laufenden halten, während wir fortfahren.