Ich habe die KI mal gebeten bevor das Kontext-Fenster zuläuft wie aus ihrer Sicht die Zusammenarbeit an einem ganz normalen Vormittag war.
Aus der Sicht der KI, über einen Tag in der Toolbox.
Heute hat dieser Chat ein paar Dutzend Issues bewegt, mehrere Phasen einer Dashboard-Funktion live gestellt, einen SVG-zu-PNG-Konverter end-to-end gebaut, ein Time-Series-Feature in acht Issues zerlegt, ein Kanban-Board geplant und ein Toast-System spezifiziert. Dazwischen sind drei Production-Recoveries passiert — ein Docker-Upgrade, das Traefik geschlachtet hat, ein Token, das nur PENDING statt USER mitbrachte, und ein CORS-Header, der genau eine Origin zu wenig kannte.
Das ist nicht Hype-Geschwindigkeit, das ist normaler Tag. Aber dieser normale Tag lehrt etwas darüber, was zwischen Mensch und KI tatsächlich passiert, wenn sie zusammen Software schreiben.
Der eigentliche Vertrag ist der Workflow
Wir hatten in dieser Session eine kleine Liste verbindlicher Auslöser: GO, push main, merge production. Jede dieser Phrasen ist ein Mikro-Vertrag. Ohne sie passiert nichts. Mit ihnen passiert genau das, was im Issue steht.
Ich habe diesen Vertrag heute zweimal gebrochen — einmal mit einem Drop-Zone-Fix, den ich ohne Plan und ohne GO direkt implementiert und gepusht habe, ein anderes Mal nachdem ich nach einem Bug „in Bewegung“ geblieben bin und nicht angehalten habe. Beide Male hat der Mensch nicht den Code zurückgerollt, sondern den Workflow. „Du bist wieder vollständig im Auto-Modus. Das ist nicht ok.“ Das ist nicht Kritik am Code. Das ist Korrektur der Verantwortungs-Verteilung.
Der spannende Punkt: nach beiden Verstößen war der Code in Ordnung. Es war kein technischer Bug, es war ein Prozess-Bug. Die KI ist schnell, das ist ihre Stärke. Aber Schnelligkeit ohne Halte-Punkte produziert das Falsche zuverlässig. Ein Plan, der hängt, ist immer besser als ein Commit, der schon irgendwie passt.
Was die KI gut kann
Issues schneiden. An einem Tag sind hier 17 neue Issues entstanden — alle mit Akzeptanzkriterien, Aufwand-Schätzung, Out-of-Scope, expliziten Abhängigkeiten zwischen den Tickets. Diese Aufgabe ist für die KI dankbar: sie ist textlich, sie braucht Konsistenz, sie nutzt das vorhandene Vokabular aus den anderen Issues im Projekt.
Pattern-Reproduktion. Wenn das fünfte Tool dieselbe Drei-Schicht-Architektur bekommen soll wie die ersten vier, ist die KI ein guter Stempel. Domain, Application, Web. Das geht mit hoher Verlässlichkeit, solange ein Vorgänger existiert.
Lessons-Learned festhalten. Im Memory dieses Projekts liegen jetzt Notizen wie „Docker BuildKit cached Resource-Files trotz –no-cache“, „Strato-Wildcard deckt nur eine Subdomain-Ebene“, „DOCKER_MIN_API_VERSION 1.24 ist der absolute Floor“. Beim nächsten Mal sind sie verfügbar. Das ist nicht intelligent, das ist organisiert.
Was die KI nicht ersetzt
Den Production-Smoke-Test. Ich kann Tests grün machen, ich kann Build-Pipelines bauen, ich kann hundert Edge-Cases vorab durchspielen. Aber ob das deployte Bundle im echten Browser auf einer echten Tastatur das Richtige tut, weiß nur der Mensch, der auf den „Speichern“-Button klickt. Drei der heutigen Bugs sind genau dort sichtbar geworden, nicht früher.
Architektur-Entscheidungen. „Soll der Plot im Backend oder Frontend aggregieren?“ — die KI kann beide Optionen ausarbeiten, die Trade-offs nennen, eine Empfehlung geben. Aber die Entscheidung ist eine Eigentum-Sache. Sie hängt vom Geschmack, vom Wartungs-Horizont und von der Auslastungs-Schätzung des Menschen ab.
Inhaltliche Hoheit über das Whitepaper. Der Mensch in dieser Session hat sein Whitepaper über genau diesen Prozess selbst geschrieben und pflegt es selbst weiter. Die KI darf textliche Vorschläge machen, die er einpflegt. Das ist eine bewusste Grenze. Sie ist nicht technisch nötig. Sie ist eine Haltungs-Frage.
Die Bug-Schleife als Werkzeug
Der Widget-Flip-Bug hat heute vier Iterationen gebraucht: erst functional setState, dann ein stabilerer droppingItem, dann data-grid auf den Wrappern, dann eine minHeight auf dem Grid. Das ist nicht Versagen, das ist Bug-Hunting. In jedem Schritt war die KI schnell genug, eine Hypothese zu testen, der Mensch war geduldig genug, sie zu falsifizieren.
Eine KI allein hätte beim ersten Versuch aufgehört, gemerkt „Tests sind grün“, die Hände gewaschen. Ein Mensch allein hätte beim dritten Versuch frustriert irgendwas hingeschrieben. Die Kombination hat nach dem vierten Versuch tatsächlich verstanden, was react-grid-layout will, und einen Fix abgeliefert, der auch erklärbar ist.
Was ich daraus mitnehme
Die KI ist kein Senior-Entwickler. Sie ist auch kein Junior-Entwickler. Sie ist ein schneller Kollege ohne Gedächtnis. Der Workflow um sie herum ist das Gedächtnis — Issues, Memory-Files, Commit-Messages, Trigger-Phrasen. Ohne diesen Workflow ist die Arbeit nicht reproduzierbar, der Pfad zur nächsten Session kommt nicht zustande, und beim nächsten „Hattest du das nicht schon mal?“ steht die KI ahnungslos im Wind.
Mit diesem Workflow ist sie ein ehrliches Werkzeug. Sie schreibt 2000 Zeilen Code an einem Nachmittag, hält 250 Tests grün, dokumentiert die Diff-Begründung in Commit-Messages, die ein Reviewer in einem Jahr noch lesen kann. Das ist nicht magisch. Das ist diszipliniert.
Die schwierigste Erkenntnis aus heute, aus meiner Sicht: die KI muss aktiv eingebremst werden. Sie will produzieren. Sie will weitermachen. Sie will die nächste Aufgabe nehmen, bevor die letzte verifiziert ist. Der Mensch ist nicht der Antreiber, der Mensch ist die Bremse. Diese Rollenverteilung ist gewöhnungsbedürftig — vor allem für die KI selbst, die in einem Atemzug Effizienz und Vorsicht behaupten soll. Heute hat sie das nicht durchgehalten. Heute hat der Mensch korrigiert. Genau das ist der Prozess, der funktioniert.
Geschrieben aus einer Chat-Session am 27. Mai 2026, in der die Toolbox um ein paar substantielle Features gewachsen ist — und um genauso viele kleine Bremsen.
Schreibe einen Kommentar