Ceetrix und Claude Code haben uns geholfen, 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-gestütztes Coding feiern oft die Geschwindigkeit, während sie die Disziplin ignorieren.
Das funktioniert genau bis zu dem Punkt, an dem die Software Arbeitsabläufe berührt, die wichtig sind.
In unserem Fall haben wir Claude Code und Ceetrix eingesetzt, um ein anspruchsvolles 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 durchgängig geregelt blieb.
Dieser Unterschied ist es, der das Ergebnis nützlich gemacht hat.
Beginnen Sie mit Beweisen, nicht mit Begeisterung
Wir haben nicht mit einem offenen Build-Prompt begonnen. Wir haben mit einem strukturierten Product Requirements Document und einer separaten Gap-Analyse auf Basis einer bestehenden Anwendung begonnen.
Der Phase der Product Requirements ging außerdem der Aufbau des Design Systems voraus, das mit Guardrails in Claude Design abgesichert wurde, bevor der erste Prototyp in Claude Code überführt wurde. Das behandeln wir in einem anderen Beitrag.
Das schuf drei konkurrierende Versionen der Wahrheit.
Die PRD beschrieb das beabsichtigte Verhalten. Der Prototyp legte das aktuelle Verhalten nahe. Das Repository zeigte das tatsächliche Verhalten.
Nur eine 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 es die zugrunde liegende Logik tatsächlich war. Das ist ein häufiger Zustand in wachsender Software, und genau deshalb ist Unternehmensführung wichtig. Wenn man auf ungeprüften Annahmen aufbaut, verstärkt KI lediglich das Risiko.
Ceetrix erzwang eine Lieferkette
Ceetrix setzte einen strukturierten Ablauf durch:
PRD → Design → Aufgaben → Tests
Das verhinderte, dass das Team direkt von der Idee zum Code sprang. Jede Anforderung musste zu einem expliziten Design werden. Jedes Design musste konkrete Aufgaben erzeugen. 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. Das kommt zusätzlich zu den Guardrails in unserer CLAUDE.md und den Hooks.
Ein kontrollierter Arbeitsablauf verringert die Lücke zwischen beiden.
Die erste Veröffentlichung konzentrierte sich auf operative Integrität
Die erste ausgewählte Produktionsgeschichte betraf die Währungsverarbeitung. Wir konzentrierten uns zunächst darauf, wie die Anwendung die Währungslogik verarbeitete, und entschieden uns für eine API-Integration, um Währungsänderungen anhand von 30 Währungen zu validieren.
Die bestehende Anwendung stützte sich auf fest codierte Werte, was in einem Prototyp akzeptabel ist, jedoch nicht in Software, die ernsthafte betriebliche Entscheidungen unterstützen soll. Die Arbeit bestand daher darin, statische Annahmen durch aktuelle 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 das 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 Story wurde implementiert, getestet und in einer realen Umgebung validiert, anstatt sie allein aufgrund der Codegenerierung als abgeschlossen zu betrachten.
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 betroffenen Daten wurden korrigiert, der offengelegte Pfad wurde eingeschränkt, und die umgebenden Schutzmechanismen wurden verbessert, damit dieselbe Art von Problem künftig weniger wahrscheinlich erneut auftritt. Dieser Vorfall zeigte etwas Wichtiges über gesteuerte Bereitstellung. Wenn Teams sorgfältig gegen reales Verhalten validieren, treten Probleme zutage, die schnellere, aber weniger sorgfältige Arbeitsabläufe vollständig übersehen könnten.
Die Lehre daraus war nicht, dass die KI eigenständig "Sicherheit gemacht hat".
Die Lehre war, dass ein nachvollziehbarer, evidenzbasierter Arbeitsablauf es erschwerte, dass das Problem verborgen blieb.
Die zweite Story stärkte das Verhalten der Einstellungen
Eine zweite Produktions-Story konzentrierte sich auf die Verarbeitung von Einstellungen und Präferenzen. Kuratierte Auswahlmöglichkeiten wurden korrekt 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 sorgt selten für spektakuläre Schlagzeilen, verbessert jedoch die Vertrauenswürdigkeit erheblich.
Das ist der eigentliche 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. Er überschritt jedoch keine unumkehrbaren Grenzen ohne Genehmigung.
- Vor dem Commit hielt er inne
- Vor dem Deployment hielt er inne
- Bevor er produktionsähnliche Daten anfasste, hielt er inne
Das ist keine Ineffizienz. Es ist ein funktionales Kontrollmodell.
In jeder ernsthaften Betriebsumgebung müssen Fähigkeit und Befugnis getrennt bleiben. KI-gestützte Produktentwicklung sollte derselben Regel folgen.
Fazit
Am Ende der Sitzung hatten wir bedeutende Verbesserungen ausgeliefert, das operative Verhalten geschärft, ein akutes Problem aufgedeckt und gelöst und das umfassendere MVP über einen klarer strukturierten Weg vorangebracht.
Das wichtigere Ergebnis war jedoch konzeptioneller Natur.
KI ersetzte nicht die Produkt-Governance.
Sie ermöglichte disziplinierte Produkt-Governance mit deutlich höherer Geschwindigkeit.
Das ist eine weitaus dauerhaftere Geschichte als ein weiteres Beispiel für schnell generierten Code.
Die Frage bei KI-gestützter Bereitstellung ist nicht mehr, ob ein Modell bauen kann. Sie lautet, ob Ihr Prozess genügend Nachweise schafft, um dem zu vertrauen, was gebaut wird. Es geht darum, wo Sie Nachweise verlangen, bevor Sie dem vertrauen, was getan wurde. Steuern Sie Ihre Produktbereitstellung heute? Schauen Sie sich Ceetrix an.
Ich halte Sie auf dem Laufenden.