Das Paradox des Makers

Es gibt ein Muster, das sich bei jeder grösseren Verschiebung in den Produktionsmitteln wiederholt, und wer seine Frankfurter Schule gelesen hat, kennt die Pointe bereits: das Werkzeug formt den Werkzeugmacher um, lange bevor dieser es bemerkt. Was gerade in der KI-getriebenen Softwareentwicklung passiert, ist keine Ausnahme. Es ist vielleicht die komprimierteste Variante, die wir bisher gesehen haben.

Die Produktivitätsfalle, oder: wie ich lernte, den Tiefschlaf aufzuschieben

Das Standardversprechen geht so: Die KI schreibt den Code, du triffst die Entscheidungen, alle gehen früh nach Hause. Wer tatsächlich ein paar Monate ernsthaft mit diesen Systemen gearbeitet hat, weiss, dass das eher eine Umkehrung dessen ist, was tatsächlich passiert.

Die Maschine wird nicht müde. Sie zögert nicht. Sie hat keinen schwachen Donnerstagnachmittag. Sie wirft sich auf jedes Problem mit der undifferenzierten Intensität von etwas, das kein Konzept von Selbsterhaltung hat. Und das stellt sich als ansteckend heraus. Die unermüdliche Produktivität der Maschine erzeugt einen Sog, einen Strudel geradezu, der dich in einen endlosen Produktionszyklus hineinzieht. Du redest dir ein, es geht um das Produkt. Tut es nicht. Das Produkt ist immer nur der Vorwand. Was tatsächlich entsteht, ist der Produktionsprozess selbst: wie man besser promptet, wie man Kontext strukturiert, wie man der Maschine noch ein Quäntchen mehr Leistung abringt.

Die Mittel sind zum Zweck geworden. Die grausame Ironie ist, dass ausgerechnet diejenigen, die das Geschäft seit Jahrzehnten betreiben, die dachten, die durchgearbeiteten Nächte vor dem Bildschirm seien vorbei, am anfälligsten sind. Sie haben das Handwerkswissen, um die Maschine effektiv zu lenken, und die Maschine belohnt dieses Wissen mit einem berauschenden Strom an Output. Das Versprechen war weniger Arbeit. Geliefert wird andere Arbeit bei höherer Intensität ohne natürlichen Haltepunkt.

Deskilling als Upgrade

Programmierung, die tatsächliche Tätigkeit des Codeschreibens, ist eine Handwerkstradition, die kaum ein paar Generationen alt ist. Sie hat ihre eigenen Rhythmen: das seltsame, zeitverschlingende Wechselspiel von Hacken und Warten, Denken und Testen, Rätseln und Lösen. Menschen haben Tausende von Stunden in diesem Modus verbracht. Die Arbeit war das Denken, Denkarbeit, ein Wort, für das das Englische zwei braucht.

Wenn KI die Implementierung übernimmt, komprimiert sich dieser gesamte Modus des Engagements in Augenblicke maschineller Evokation. Du beschreibst, die Maschine produziert. Die Denkarbeit verschwindet. Was bleibt, ist Steuerung und Prüfung, kognitiv anspruchsvoll, sicher, aber grundlegend anders im Charakter. Die Erfahrung, mit Code zu ringen, festzustecken und wieder freizukommen, Verständnis aufzubauen durch den Widerstand des Materials: das brauchst du nicht mehr.

Der Handweber, der auf einen programmierbaren Webstuhl wechselt (die erste programmierbare Maschine überhaupt, gebaut 1804 von einem französischen Seidenweber namens Jacquard), hört nicht auf zu arbeiten. Aber die Arbeit verschiebt sich von der Pragmatik des Gewebes zur Optimierung der Maschine. Der Stoff wird nebensächlich, etwas das einfach nur "fertig" sein muss, damit man die Lochkarten verfeinern kann. Etwas, das existieren muss, damit die nächste Generation der Prozessverfeinerung beginnen kann.

Manager, die weit genug von der Codebasis entfernt sind, haben das natürlich immer schon so gesehen. Codeschreiben war für sie immer nur ein bedauerliches Zwischenstück zwischen der Idee und dem Produkt. Sicher keine kontemplative Praxis, nichts, was irgendjemand Handwerk nennen würde. Neu ist, dass die Leute, die den Code schreiben, anfangen, ihn genauso zu betrachten. Die Versenkung weicht dem Eklektizismus: dieses Modell oder jenes, diese Workbench oder eine andere, Hauptsache es geht schneller. Freiwillig.

Lochkarten verfeinern

Ich habe in den letzten Monaten genau das getan, was dieser Text beschreibt. Statt zu weben, habe ich monatelang am Webstuhl herumgebastelt, versucht zu verstehen, wie er funktioniert, warum er die Entscheidungen trifft, die er trifft, was passieren würde, wenn man die Arbeit um Entscheidungen statt um Tasks herum strukturiert.

Das Ergebnis sind zwei kürzlich veröffentlichte Arbeiten. Beyond Agile / Fusion versucht ein Prozessmodell für KI-getriebene Entwicklung, gebaut um Ziele, Entscheidungen und Kohärenz statt um Stories und Tasks. Understanding Claude Code seziert die Interna des KI-Coding-Agenten, den ich täglich benutze. Beide wurden mit der Maschine geschrieben, über die Maschine, im Dienste des besseren Umgangs mit der Maschine.

Was nach dem Basteln auftauchte, war eine Frage, die sich der Automatisierung entzieht: nicht "funktioniert der Code?", sondern "respektiert der Output die getroffenen Entscheidungen, und ergeben diese Entscheidungen für das Ziel noch Sinn?" Hier ist menschliches Urteil strukturell erforderlich und nicht bloss willkommen. Alles andere kann die Maschine approximieren. Dies nicht, weil es eine Beziehung zum Zweck der Arbeit erfordert, die über die unmittelbare Aufgabe hinausreicht.

Die Sektion des Agenten offenbarte ihre eigene Version desselben Problems. Diese Systeme haben kein Gedächtnis. Sie simulieren Kontinuität, indem sie in jedem Turn alles neu lesen, und wenn der Kontext überläuft, komprimieren sie ihn verlustbehaftet, verwerfen, was unwichtig schien, ohne zu wissen, was später relevant sein wird. Der Mensch, angeblich von der Implementierung befreit, wird zum Hüter der Kontinuität, zu demjenigen, der die Kontextdateien pflegt, die verhindern, dass die Maschine über Sessions hinweg in Inkohärenz abdriftet. Du schreibst nicht mehr den Code. Du schreibst das Gedächtnis, das den Code ermöglicht.

Lochkarten verfeinern, den Sog füttern.

Mündigkeit

Das Schiff ist abgefahren, und es kommt nicht zurück. Was jetzt zählt, ist, was mit der Gilde passiert.

Wenn die Arbeit das Denken war, und die Arbeit automatisiert wird: wo lernt die nächste Generation zu denken? Man kann jemandem beibringen, Prompts zu schreiben, Output zu prüfen, Kontextdateien zu pflegen. Wie bringt man die Intuition bei, die aus Tausenden Stunden Denkarbeit entsteht, aus dem Feststecken, aus dem Aufbauen von Verständnis durch den Widerstand des Materials? Diese Intuition ist es, die Coherence Review möglich macht. Sie ist es, die dir sagt, dass der Output Schrott ist, selbst wenn jeder Test besteht.

Die einzige Art zu lernen, die Arbeit der Maschine zu beurteilen, ist, die Arbeit selbst getan zu haben. Und die Maschine sorgt dafür, dass das niemand mehr tut.

Adorno gelangte spät in seiner Karriere zu einem Begriff als Massstab dafür, ob Veränderung Fortschritt ist oder Regression: Mündigkeit, die Fähigkeit zu eigenständigem Urteil. Nicht Wissen, nicht Skill, sondern die Fähigkeit, selbst zu denken angesichts von Systemen, die für dich denken. Das Paradox des Makers ist ein Mündigkeitsproblem. Die Denkarbeit muss vielleicht nicht als Produktionsmethode überleben, sondern als Praxis: bewusst, vielleicht ineffizient, aber unersetzlich als Quelle des Urteils, das alles andere kohärent hält.