KI ist ein Multiplikator — die Verantwortung geht nicht über

KI macht das Bauen schnell. Schnell heißt, sich selbst überlassen, Slop — Code, der läuft, sauber demonstriert und still verrottet, weil niemand ihn verstehen musste, um ihn zu produzieren. Das Gegenmittel ist nicht, langsamer zu werden. Es ist, bewusst zu sein, worauf man das Werkzeug richtet, denn das Werkzeug wird es nicht für einen sein.

Die Falle ist subtil, und sie ist ökonomisch. Was einen Engineer früher diszipliniert hat, war Aufwand: eine schlechte Idee war teuer umzusetzen, also überlegte man zweimal, bevor man sie baute. Wenn Bauen billig wird, verschwindet diese Bremse. Jede Abstraktion ist plötzlich leistbar, also wird jede Abstraktion gebaut. Nichts ersetzt die fehlende Bremse, es sei denn, man baut sie absichtlich ein — und die meisten Fehlschläge, die ich mit KI gesehen habe, sind nicht das Modell, das falschliegt, sondern die Bremse, die weg ist.

Es hilft, KI als Hebel statt als Autopilot zu denken. Ein Hebel multipliziert Kraft; er wählt keine Richtung. Auf eine solide Struktur gerichtet, verdichtet er sich zu echter Geschwindigkeit. Auf eine wackelige gerichtet, verdichtet er sich zu einem Chaos, schneller als man den Diff lesen kann. Der Multiplikator ist wahrhaft gleichgültig dagegen, welche — er wird eine gute Entscheidung und eine schlechte mit gleicher Begeisterung verstärken.

Das verschiebt, wohin die Aufmerksamkeit gehört. Die knappe Ressource ist nicht länger das Tippen — es ist Urteilsvermögen: was zu bauen, was wegzulassen, welche Struktur festzulegen, bevor billig erzeugter Code wie Beton um sie herum aushärtet. Das Modell liefert Output; der Mensch liefert Richtung. Verwechselt man die beiden, hat man Autopilot, was nur ein längeres Wort für Hoffen ist.

Ich kann den Fehlermodus zeigen, weil ich ihn gebaut habe. Mit dem Ziel, KI-gestützte Auslieferung zu steuern, begann ich ein kleines Tool und ließ es zu einem kompletten System eskalieren: ein deterministischer Kernel ohne Modellaufrufe, geschichtete architektonische Contracts, ein Agenten-Runtime, eine eigene Workflow-Sprache, sogar eine Ontologie, die meinen Build-Prozess auf Betriebssystem-Konzepte abbildete. Als ich aufhörte, waren es 479 Dateien und rund vierzehntausend Zeilen Python — mit zwanzigtausend Zeilen Dokumentation obendrauf. Mehr Prosa, die die Architektur erklärte, als es Architektur gab. Fünfundzwanzig Artefakt-Schemata. Zehn geplante Agenten-Rollen; vier tatsächlich gebaut.

Nichts davon war schwer, und genau das ist der Punkt. Jede Schicht war billig zu erzeugen, also wurde jede Schicht erzeugt. Die State-Machine wurde so verwinkelt, dass ihr eigenes Changelog festhält, States zurückgeschnitten zu haben „um Komplexität zu reduzieren" — ein System, zu komplex für sich selbst. Es gab ein ganzes Dokument, das „ist das nicht zu kompliziert?" mit „nein, es ist vollständig explizit" beantwortete — was, im Rückblick, das ist, was Over-Engineering sagt, während es sich rationalisiert. Das wahre Anzeichen war mein eigenes Verhalten: der volle Workflow kostete rund zwanzig Minuten pro Änderung, also umging ich für jede echte Charge Arbeit still mein eigenes Framework und committete direkt auf den Main-Branch. Ich hatte eine aufwendige Maschine gebaut und dann um sie herumgeroutet.

Die Lektion ist nicht, dass Frameworks schlecht sind. Sie ist, dass der teure Fehler nie zu viel Verständnis war — das ganze Problem zu verstehen ist umsonst und lohnt sich — sondern zu viel Bauen, zu früh. Das ganze Bild in Code zu committen, bevor man es braucht, ist genau dort, wo der Multiplikator sich gegen einen wendet. Die Entscheidung, die das Werkzeug mir nicht abnehmen konnte, war die einzige, die zählte: was nicht zu bauen.

Was dieses System ersetzte, ist fast peinlich klein. Dieselben Ziele — Inferenz kontrollierbar halten, Reasoning ehrlich halten, die Arbeit auditierbar halten — leben jetzt in Konfiguration und einer Handvoll Marktkomponenten statt in einem maßgeschneiderten System. Ein einziger lokaler Proxy ist der eine Endpoint, mit dem jedes Tool spricht; das Modell zu wechseln ist eine Ein-Zeilen-Änderung; die Teile, die mir tatsächlich gehören, sind eine Config-Datei und ein achtunddreißig Zeilen langer Cost-Guard. „Integrieren, nicht bauen" war die ganze Korrektur.

Ein paar Patterns leisten die eigentliche Kontrollarbeit, und sie sind auf jedes Setup übertragbar. Der rote Faden durch alle ist derselbe: das zuverlässigste Signal ist nie die Zuversicht des Modells in sich selbst — es ist etwas außerhalb des Modells. Struktur schlägt Disziplin hier, denn an Disziplin muss man sich erinnern, und Struktur ist etwas, das man nicht vergessen kann.

Man sollte ehrlich sein darüber, was der Multiplikator kostet, denn er kostet. Die schärfste Lektion, die ich auf die harte Tour lernte: grüne Tests sind kein verifiziertes Ergebnis. Auf einer Strecke hatte ich ein paar Dutzend Commits, ein paar hundert bestehende Tests und einen Stapel als erledigt markierter Stories — und der gerenderte Output war sichtbar kaputt. Die Hälfte der Charts war nie eingebettet, die Skalen unbrauchbar, das Escaping doppelt. Die Tests waren die ganze Zeit grün. Der menschliche Reviewer fand jeden einzelnen dieser Bugs; die Suite fand keinen. Die Verantwortung war nicht auf das Tooling übergegangen, so zuversichtlich es auch aussah.

Ein paar mehr, die mich überraschten. Mehr Geld und ein größeres Token-Budget kaufen keine Reasoning-Tiefe — ich habe es gemessen: das Limit war nicht einmal bindend, das Modell hörte schlicht ab einem Punkt auf zu denken, und nur ein stärkeres Modell verschob diese Linie. Ein hoher Benchmark-Score überträgt sich nicht auf das eigene Setup — ein Modell, das ein Coding-Leaderboard anführt, blieb in meinem Loop stecken, weil es nach einem Tool griff, das es nicht durfte, statt nach dem, das es durfte. Und zwei Modelle, die sich gegenseitig prüfen, ist schwächer, als es klingt: zwei flache Urteile bestätigen sich flach. Was tatsächlich Fehler fängt, ist hartes, externes Feedback — ein Test, ein Type-Checker, ein Mensch, der auf die gerenderte Seite schaut — nicht die Agenten, die sich selbst benoten.

All das zeigt in dieselbe Richtung. Der Multiplikator skaliert Output, und die Zuversicht, die damit kommt; er skaliert nicht das Urteil, das einem sagt, dass der Output falsch ist. Dieses Urteil bleibt beim Menschen, und in dem Moment, in dem man es vergisst, arbeitet die Geschwindigkeit gegen einen.

Das kopierenswerte Setup ist also vor allem ein Satz Entscheidungen, kein Stack. Minimal bauen, das ganze Bild im Kopf halten, und jedem Teil, den man aufschiebt, einen expliziten Trigger dafür geben, wann er sich seinen Platz verdient. Wie viel man vorab entwirft, knüpft man daran, wie reversibel die Entscheidung ist: ein Schema, ein Interface, ein Name ist später teuer zu ändern, also denkt man ihn jetzt durch; fast alles andere kann ein dünner vertikaler Slice sein, den man wachsen lässt. Das ist es, was die Geschwindigkeit des Multiplikators erlaubt, ohne dass er einem davonläuft.

Konkret die Entscheidungen, die das Gewicht tragen:

KI ist der größte Hebel, den ich je auf meine eigene Arbeit hatte, und ich nutze ihn auf alles. Aber ein Hebel bewegt die Last; er entscheidet nicht, wohin die Last soll. Das Modell kann entwerfen, refactoren, erklären und mit mir um drei Uhr morgens streiten — und nichts davon überträgt die Verantwortung dafür, ob das Ergebnis korrekt, solide und erlaubt ist zu existieren. Die bleibt meine.

Das ist die ganze Haltung, und es ist der Unterschied zwischen einem Engineer, der KI nutzt, und einem Vibe-Coder, der von ihr genutzt wird. Nimm den Multiplikator — voll und ganz. Behalte nur die Hand an der Richtung.