Heute habe ich eine Stunde an einer Spezifikation gearbeitet. Nicht am Code. An der Spezifikation.

Eine Stunde für einen Text, den am Ende niemand sieht außer mir und dem Modell. Kein Feature, keine Zeile, die läuft. Und trotzdem war es die wichtigste Stunde des Tages.

Das Modell rät, und sagt es nicht

Ein Modell erzeugt zu jeder Unklarheit sofort eine plausible Variante. Es fragt nicht nach. Wenn etwas offen ist, trifft es eine Annahme und formuliert sie als Tatsache. Ohne Markierung, ohne Hinweis, dass hier gerade geraten wurde.

Genau daran sehe ich, wo meine Vorgabe zu unscharf war. Die Annahme steht vor mir, ich lese sie, und der Fehler springt mich an. Das ist dieselbe Mechanik, die ich in „KI hat das Problem nicht erfunden, sie hat es sichtbar gemacht“ beschrieben habe. Das Modell erfindet die Lücke nicht. Es zeigt sie mir, weil es sie füllt, statt sie zu überspielen.

Gefährlich beim Bauen, nützlich beim Klären

Beim Implementieren ist das ein Problem. Plausibel ist nicht korrekt. Der Unterschied fällt oft erst auf, wenn der Code schon läuft und ich das falsche Verhalten im Betrieb sehe. Das ist schnell geschehen, wenn das Modell einen Plan macht und nach Bestätigung sofort mit der Implementierung loslegt.

Beim Spezifizieren ist es genau das, was ich brauche. Vor einem leeren Dokument sehe ich meine eigenen Lücken nicht. Ich halte sie für Klarheit, weil ich sie im Kopf schon gefüllt habe. Erst der konkrete Vorschlag zwingt die Lücke nach außen. 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.

Der verbreitete Umkehrschluss

Ich höre oft das Gegenteil. Je komplexer die Aufgabe, desto mehr solle die KI übernehmen, weil der Entwickler nicht mehr durchsteigt.

Das ist falsch herum.

Ein Modell füllt jede Lücke. Es fragt nicht nach, es entscheidet. Bei einer einfachen Aufgabe fällt eine falsche Annahme schnell auf. Bei einer komplexen Aufgabe stapeln sich die Annahmen, und ich sehe sie nur, wenn ich die Sache selbst verstanden habe. Ich kann nicht prüfen, was ich nicht verstehe. Wer bei Komplexität abgibt, gibt genau dort ab, wo die stillen Annahmen am teuersten werden.

Verstehen ist nicht bauen lassen

Verstehen und bauen lassen sind zwei verschiedene Dinge. Das Bauen nimmt mir das Modell ab. Das Verstehen nicht. Es täuscht es nur vor, wenn ich es lasse.

Ein plausibler Vorschlag fühlt sich an wie Verständnis. Er ist keins. Diesen Unterschied zu halten ist meine Aufgabe, und sie wird größer, nicht kleiner, je mehr das Modell kann.

Die Denkarbeit wandert nach vorn

Je komplexer die Aufgabe, desto weiter muss die Denkarbeit nach vorn. Nicht mehr Dokument, sondern mehr Klärung. Der Umfang der Spezifikation bleibt klein. Was sich verschiebt, ist der Zeitpunkt, an dem ich nachdenke.

Ich habe schon beschrieben, dass der Engpass nicht mehr der Code ist, sondern die Klarheit darüber, was ich eigentlich will. Diese Klarheit organisiert sich nicht von selbst. Sie ist Arbeit, und diese Arbeit findet vorne statt oder gar nicht.

Ist die Spezifikation sauber, ist die Implementierung der einfache Teil. Das Modell baut, was dasteht. Nicht mehr, nicht weniger. Die Geschwindigkeit, die alle an der KI schätzen, entsteht hier, nach der Klärung, nicht davor.

Was das Abgeben wirklich tut

Der Reflex, bei Komplexität abzugeben, klingt vernünftig. Er ist es nicht. Er verschiebt die Denkarbeit nicht auf das Modell. Er lässt sie weg. Das Modell liefert dann trotzdem etwas. Es sieht sogar gut aus. Nur weiß niemand mehr, ob es das Richtige ist.

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