Leseprobe aus meinem Buch „Software mit KI entwickeln“. Das ist Kapitel 3, bis auf einen Querverweis unverändert. Es steht früh im Buch, weil alles Weitere daran hängt.

Ich spiele Schach. Wenn ich am Brett sitze und am Zug bin, ist die wichtigste Frage nie, wie gut mein Gegner spielt. Die wichtigste Frage ist, wer die Initiative hat. Solange ich sie habe, bestimme ich Tempo und Richtung der Partie. Gebe ich sie ab, ist jeder Zug nur noch Reaktion, und Reaktion kostet Zeit, kostet Optionen, kostet am Ende oft die Partie.

Genau dieses Muster begegnet mir seit Monaten in der Arbeit mit KI-Werkzeugen, und es sieht zunächst harmlos aus. Das Modell beginnt, eigene Annahmen zu treffen. Es schlägt Refactorings vor, die ich nicht angefragt habe. Es wählt Bibliotheken, die ich nicht evaluiert habe. Es erweitert den Scope, weil es das konsistenter findet. Jeder einzelne Vorschlag wirkt für sich plausibel, aber die Summe führt weg von meinem Ziel, dorthin, wohin das Modell den Code gedrängt hat. Das fühlt sich produktiv an, es passiert ja viel. Es ist der Moment, in dem die Partie kippt.

Ein Sprachmodell ist kein passives Werkzeug wie eine IDE. Es ist etwas, das Vorschläge in den Raum stellt, die plausibel klingen und sofort umsetzbar wirken. Wenn ich nicht aufpasse, sind sie auch sofort umgesetzt. Aus meiner Anfangszeit kenne ich das gut: Ich habe gesagt, mach mal einen Plan. Das Modell hat den Plan geliefert, gefragt, ob es loslegen soll, und schon implementiert, bevor ich geantwortet hatte. Deshalb reicht es nicht, sorgfältig zu sein. Ich brauche eine Struktur, die die Initiative dort hält, wo sie hingehört.

Die KI als Implementations-Engine

Ich behandle die KI konsequent als Werkzeug. Das sagt, wie ich sie behandeln will, nicht, was sie ist. Ich behaupte nicht, ein Sprachmodell sei nur die nächste Stufe nach vi, Emacs und IntelliJ. Es ist ein Bruch, keine Fortsetzung. Behandeln will ich es trotzdem wie ein Werkzeug, weil nur so klar bleibt, wer die Verantwortung trägt.

Am besten trifft es der Begriff Implementations-Engine: ein starker Motor, der eine Hand am Steuer braucht. Das Bild hat eine Grenze. Ein Motor hat keine Meinung zur Route. Ein Sprachmodell hat eine, es schlägt eine Architektur vor. Genau deshalb ist die Hand am Steuer nötig.

Warum lässt sich Verantwortung nicht an ein Modell abgeben? Das übliche Argument lautet, Verantwortung sei grundsätzlich unteilbar. Das ist nicht meins: An Menschen delegiere ich Verantwortung ständig. Delegation ist ein Vertrag zwischen Personen, die Konsequenzen tragen können. Ein Modell kann keine tragen.

Zwei Modi des Denkens, und das Modell hat nur einen

Zurück ans Brett. Ich bin ein fortgeschrittener Anfänger, und trotzdem kenne ich beide Modi. In der Eröffnung, in den ersten zehn Zügen, hatte ich die Stellung oft schon auf dem Brett. Das Mustergedächtnis springt an, und ich kann sofort ziehen. Im Mittelspiel springt es manchmal noch an. Aber irgendwann kommt der Moment, in dem ich wirklich rechnen muss, Zug für Zug, Variante für Variante.

Im ersten Modus ist das Modell stark. Den zweiten Modus kennt es nicht. Und es stockt nie. Es markiert die Stelle nicht, an der sein Muster aufhört. Es antwortet auf die bekannte und auf die neue Stellung im selben Ton, mit derselben Sicherheit. Es versteckt die Lücke nicht, es füllt sie.

Die Gefahr ist deshalb nicht das Tempo des Modells. Die Gefahr ist, dass mir ein plausibler Zug genügt, obwohl die Stellung neu ist. Ich sehe nur eine glatte Antwort und halte sie für eine geprüfte. Wer das Prüfen überspringt, spielt in einer neuen Stellung einen Zug aus einer alten Partie.

In genau diesen Stellungen übernehme ich. Schneller bin ich nicht. Aber ich bin der Einzige im Raum, der überhaupt in den zweiten Modus schalten kann. Ein Modell macht den ersten Modus billig. Den zweiten macht es wichtiger, weil es ihn nicht kann.

Die Denkarbeit wandert nach vorn

Die Denkarbeit wandert nach vorn. Dieser Satz trägt meinen ganzen Prozess.

An einem Tag im Juli habe ich eine Stunde an einer Spezifikation gearbeitet. Eine Stunde für einen Text, den am Ende niemand sieht außer mir und dem Modell. Kein Feature, keine Zeile, die läuft. Sofort in die Tasten zu hauen hätte sich produktiver angefühlt. Es war trotzdem die wichtigste Stunde des Tages.

Das Verfahren dabei ist unspektakulär. Ich lasse das Modell eine erste Variante schreiben. An ihren Annahmen sehe ich meine eigenen Lücken. Vor einem leeren Dokument sehe ich sie nicht, ich halte sie für Klarheit, weil ich sie im Kopf schon gefüllt habe. Die erste Variante ist falsch, aber sie ist konkret. Die nächste ist besser, weil ich die vorige gesehen habe. Nach einer Stunde steht ein Text, der trägt.

Das ist ausdrücklich nicht die Rückkehr zum Lastenheft. Ein Issue hat vier Abschnitte und passt auf eine Seite. Geklärt wird trotzdem mehr. Das Nachdenken wird nicht mehr, es rückt nach vorn.

Der verbreitete Reflex geht in die andere Richtung: Je komplexer die Aufgabe, desto mehr gebe ich ab. Das ist falsch herum. Wer bei Komplexität abgibt, gibt genau dort ab, wo die stillen Annahmen am teuersten werden. Ich kann nicht prüfen, was ich nicht verstehe. Das Bauen nimmt mir das Modell ab, das Verstehen nicht. Verstehen täuscht es mir nur vor, wenn ich es lasse.

Wenn ich nicht mehr durchsteige, hilft mir kein Modell. Dann fehlt mir keine Implementierung. Dann fehlt mir die Spezifikation.

Die drei Stop-Punkte

Aus dieser Haltung folgen drei Stellen im Prozess, die ich nicht automatisiere. Ich habe mein Werkzeug in wenigen Wochen fünfmal umgebaut, und diese drei Punkte haben sich in keiner der fünf Fassungen verändert.

Das Ready. Ich entscheide, welche Issues in den nächsten Durchlauf kommen. Am Board heißt das: Ich ziehe sie nach Ready. Darin liegt die Planung, wie viel Arbeit auf einmal, welche Priorität, welche Abhängigkeiten. Die KI zieht nie eigenmächtig etwas nach Ready.

Der Push. Ich gebe frei, bevor Code meinen Rechner verlässt. Jeder Batch braucht eine eigene Freigabe. Eine frühere Freigabe in derselben Session gilt nicht für neue Commits.

Der Merge. Ich bringe Code nach production, nachdem ich auf dem Test-Server geprüft habe.

Alles dazwischen kann die KI machen. Diese drei Punkte nicht. Dort liegt die Verantwortung.

Es gibt einen vierten, und er ist mir erst aufgefallen, als ich ihn schon gebaut hatte: den Git-Tag. Ein Tag markiert eine Veröffentlichung, und Veröffentlichungen gebe ich selbst frei, genau wie die drei Punkte davor. Beim Push auf main entsteht deshalb bewusst keiner, dort entstehen interne Patch-Stände, die niemand veröffentlicht. Ich zähle ihn nicht mit, wenn ich von den Stop-Punkten rede, weil er keine Trigger-Phrase hat und niemanden aufhält. Der Gedanke dahinter ist aber derselbe.

Dazu gehört eine Abgrenzung: Kontrolle heißt, dass die Freigabe ein bewusster Akt bleibt. Gerade dann, wenn der Output gut ist.

Die Trigger-Phrasen für Ready, Push und Merge sind Mikro-Verträge. Ohne sie passiert nichts, mit ihnen passiert genau das, was im Issue steht. Sie gehören deshalb in die Sicherheitsarchitektur, nicht in die Bedienungsanleitung.

Je autonomer die KI, desto strenger die Stop-Punkte

Das ist die Grundregel, und sie wird in dem Maß wichtiger, in dem die Werkzeuge autonomer werden. Nachtläufe sind gut. Nachtläufe ohne Stop-Punkte sind es nicht. Ohne Stop-Punkte fallen Entscheidungen, die kein Mensch getroffen hat, und je länger die KI allein arbeitet, desto mehr davon sammeln sich an.

Wie nötig die Regel ist, habe ich an einem Tag gelernt, an dem das Modell zweimal den Workflow gebrochen hat. Einmal hat es einen Fix an einer Drop-Zone ohne Plan und ohne Ready direkt implementiert und gepusht. Einmal ist es nach einem Bug in Bewegung geblieben, statt anzuhalten. Ich habe damals geschrieben: „Du bist wieder vollständig im Auto-Modus. Das ist nicht ok.“ Beide Male war der Code danach in Ordnung. Es war kein technischer Bug, es war ein Prozess-Bug. Also habe ich den Workflow zurückgerollt, nicht den Code.

Daraus folgt auch meine Rolle im Alltag. Ich muss das Modell aktiv einbremsen. Es produziert, es macht weiter, es nimmt die nächste Aufgabe, bevor die letzte verifiziert ist. Der Mensch ist nicht der Antreiber. Der Mensch ist die Bremse.

Schnelligkeit ohne Stop-Punkte produziert das Falsche zuverlässig. Ein Plan, der hängt, ist immer besser als ein Commit, der schon irgendwie passt.

Wo die Schwelle genau verläuft, entscheidet die Verantwortung, nicht der Aufwand. Ein Beispiel dafür steht später im Buch: Nachts darf ein Modell feststellen, dass an einem Issue nichts zu ändern ist, und das protokollieren. Ändern darf es die Anforderung nicht. Wer diese Grenze sauber zieht, kann viel automatisieren, ohne einen Stop-Punkt aufzuweichen.

---

Das Buch beschreibt den ganzen Prozess: das Board als geteilten Statusträger, den Prozess als ausführbare Skills, und den Arbeitsfluss dazwischen. Wo es zu haben ist, steht hier.