CIV-Methode: Wie wir mit KI Software entwickeln, ohne die Kontrolle zu verlieren

Seit zwei Jahren entwickeln wir ShephERP mit künstlicher Intelligenz, wobei die KI den größten Teil des Codes schreibt. Auf diesem Weg haben wir gelernt, dass der Engpass nie das Modell war. Es war alles andere. Dieser Arbeitsweise haben wir einen Namen gegeben: CIV-Methode.

Das Problem, das niemand erzählt

Das Versprechen der KI in der Softwareentwicklung ist real: Ein Agent schreibt in zwanzig Minuten, wofür früher zwei Tage nötig waren. Was fast niemand erzählt, ist, was in Woche sechs passiert.

Ein Sprachmodell ist ein erstaunlich schneller und erstaunlich wörtlich arbeitender Ausführender. Ohne Kontext erfindet es: Wenn du ihm nicht gesagt hast, dass Mitglieder mit überfälligem Beitrag den Rabatt verlieren, wird es den Rabatt trotzdem anwenden, weil das das Vernünftigste scheint. Und ohne Grenzen bricht es etwas: Es behebt den Fehler, um den du gebeten hast, und fasst dabei gleich vier weitere Dinge an, um die niemand gebeten hat.

Das Ergebnis ist ein Projekt, das mit beeindruckender Geschwindigkeit startet und nach zwei Monaten stecken bleibt, mit Tausenden von Zeilen, die niemand geprüft hat, und einem Team, das sich nicht mehr traut, irgendetwas anzufassen. Die Geschwindigkeit des Codeschreibens zu vervielfachen, ohne die Fähigkeit zu vervielfachen, ihn zu prüfen, ist keine Produktivität: Es ist Schuld mit Maschinengeschwindigkeit.

Man entwickelt nicht schneller mit besseren Prompts, sondern mit besserem Kontext und besseren Grenzen.

Drei Säulen: Kontext, Iteration, Verifikation

CIV sind die drei Dinge, die man um den Agenten herum aufbauen muss. Es sind keine Phasen, die man nacheinander durchläuft: Sie funktionieren immer gleichzeitig, und wenn man eine davon entfernt, bricht das System zusammen.

C — Kontext: Die Dokumentation ist der Quellcode

In einem CIV-Projekt existiert der Ordner docs/ vor dem Code. Darin steht alles: das Geschäft des Kunden, sein genauer Wortschatz, die Regeln, einzeln nummeriert, die technischen Entscheidungen mit Datum und verworfenen Alternativen und das Protokoll jedes Treffens, am selben Tag geschrieben.

Wir dokumentieren nicht, um zu prüfen oder um gut dazustehen. Wir dokumentieren, weil es buchstäblich die Eingabe des Ausführenden ist. Ein Besprechungsprotokoll ist das wertvollste Gut, das es für eine KI gibt, denn es enthält das Einzige, was kein Repository ableiten kann: die Absicht. Der Code sagt, was das System tut; nur das Protokoll sagt, warum es so gebaut wurde und was kaputtgeht, wenn man es ändert.

Daraus folgt unser erstes Prinzip, das zugleich das unbequemste ist: Was nicht geschrieben steht, existiert nicht. Eine Entscheidung, die nur in einem Gespräch lebt, ist keine Entscheidung, sondern ein Gerücht, das der Agent nicht respektieren kann.

I — Iteration: Ein Ticket ist ein Prompt

Die Arbeit verteilt sich auf drei Ebenen — episch (ein Quartal), Meilenstein (was man in zwei Wochen zeigen kann) und Aufgabe (was in eine Sitzung passt) — und mündet in Tickets, die für jemanden geschrieben sind, der nicht beim Gespräch dabei war, sich an nichts erinnert und nicht nachfragen wird.

Das verändert vollständig, wie man ein Ticket schreibt. Nichts von „den Filter reparieren“. Schritte mit echten Daten, die genaue URL, ein kommentierter Screenshot mit einem Pfeil auf das, was falsch ist, die eingefügte Anfrage und Antwort, das erwartete Ergebnis, die Akzeptanzkriterien als Checkliste und — die Zeile, die am meisten Geld spart — was NICHT angefasst werden darf.

Wir nennen das Definition of Ready für KI, und sie hat eine goldene Regel: Wenn der Agent etwas nachfragen muss, um anzufangen, war das Ticket schlecht geschrieben, und es geht zurück an die Person, die es verfasst hat. Das ist keine Bürokratie. Ein unvollständiges Ticket bleibt nicht stehen: Es vervollständigt sich von selbst, mit der wahrscheinlichsten Annahme des Modells. Und die wahrscheinlichste Annahme ist fast nie die Geschäftsregel deines Kunden.

Danach durchläuft jede Aufgabe sechs immer gleiche Schritte: lesen, planen, abstecken, ausführen, verifizieren und übergeben. Der wichtigste ist der zweite: Der Plan wird genehmigt, bevor die erste Zeile Code entsteht. Einen Plan zu korrigieren kostet eine Minute; einen Nachmittag zu korrigieren kostet einen Nachmittag.

V — Verifikation: Zuerst der Zaun, dann wird er gelockert

Hier sollte man eine sehr verbreitete Verwechslung auflösen, denn alles Weitere hängt davon ab. Viele Leute sprechen von „Unit-Tests, E2E und Cypress“, als wären das drei Dinge derselben Art. Sind sie nicht: Man vermischt zwei verschiedene Achsen. Die eine ist die Ebene — wie viel reales System man testet —, die andere ist das Werkzeug, mit dem man es testet. Cypress ist keine Ebene: Es ist ein Werkzeug für die Ende-zu-Ende-Ebene der Oberfläche. Und „Ende-zu-Ende“ ist ebenfalls nicht eines: Die vollständige API zu testen und die Anwendung in einem Browser zu testen sind verschiedene Dinge, mit unterschiedlichem Aufwand und unterschiedlichem Nutzen.

In CIV gibt es sechs Ebenen, von der günstigsten zur teuersten: Typen und Stil, Unit-Tests, Integration, API-Ende-zu-Ende, Oberflächen-Ende-zu-Ende und Rauchtest in Produktion. Die Frage, die immer entscheidet, wo ein Test hingehört, lautet: Welches ist das kleinste Stück, in dem dieser Fehler erkannt werden kann? Ein falsch berechneter Rabatt ist ein Unit-Test, auch wenn man ihn erst beim Einkaufen im Shop bemerken würde.

Darüber steht die Abdeckung von über 95 % und die Regel, die sie trägt: die Ratsche. Die Schwellenwerte steigen nur. Sie sinken nie, auch nicht „vorübergehend“. Die bereits bestehende Schuld wird mit einer Basislinie eingefroren und Stufe für Stufe abgetragen; neue Schuld wird noch am selben Tag blockiert. Und kein Fehler wird geschlossen, bevor er den Test hinterlassen hat, der ihn erkannt hätte: Kein Fehler stirbt ohne Zeugen.

Warum sich das von selbst bezahlt macht

Ein normales Projekt verschlechtert sich: Jeden Monat kostet es mehr, es anzufassen. Ein CIV-Projekt tendiert in die Gegenrichtung, und der Grund ist konkret. Der Kontext wächst, also kommt jede neue Aufgabe mit mehr bereits gelöstem Gelände an. Der Zaun wächst, also ist jede Änderung weniger riskant als die vorherige. Und die Kosten, jemanden — oder einen anderen Agenten — einzuarbeiten, sinken, denn Einarbeiten heißt, einen Ordner der Reihe nach zu lesen.

Wir messen sieben Dinge, aber eines, das fast niemand misst, sagt alles: die Quote sauberer Tickets, also der Prozentsatz der Tickets, die der Agent löst, ohne nachfragen zu müssen. Sinkt diese Zahl, liegt das Problem nicht am Modell, das du verwendest. Es liegt an deinem Kontext und daran, wie du Tickets schreibst.

Was CIV nicht ist

Es ist kein Vibe Coding. Es ist keine Schaufenster-Abdeckung — Tests, die viel ausführen und nichts prüfen. Es sind keine zeremoniellen Dokumente, die niemand aktualisiert; mit KI sind sie schlimmer als gar keine, weil der Agent sie tatsächlich liest und ihnen glaubt. Es sind keine Abkürzungen, die seit sechs Monaten dauerhaft sind. Und vor allem ist es nicht, einen Agenten ohne Leine loszulassen und das Autonomie zu nennen.

CIV ist nicht auf einem Whiteboard entstanden: Es ist aus dem Bau eines vollständigen ERP mit KI hervorgegangen, aus Fehlern, die wir gemacht und mit ihrem Grund notiert haben. Das tun wir jeden Tag.

Kontext. Iteration. Verifikation. Nimmt man eines der drei weg, ist es kein CIV: Es ist Glück.