In Schneller als Verstehen habe ich ein Experiment beschrieben: Ich ließ einen KI-Agenten die ACPATH-Metrik implementieren, einen Algorithmus aus einer Domäne, in der ich kein Experte bin. Der Agent brauchte 15 Minuten. Ich habe anschließend Stunden damit verbracht herauszufinden, ob die Implementierung korrekt ist, und konnte es am Ende immer noch nicht mit Sicherheit sagen. Mein Fazit war, dass eine fundamentale Asymmetrie entsteht, wenn Domänenexpertise fehlt: Ein KI-Agent kann Code schneller generieren, als wir die Domäne verstehen können, zu der dieser Code gehört.
Seit der Veröffentlichung jenes Artikels bin ich auf drei Beobachtungen gestoßen. Keine davon wurde als Antwort auf meinen Artikel geschrieben, aber jede betrachtet dasselbe Phänomen aus einer anderen Richtung, und jede hat mir etwas gezeigt, das ich nicht explizit gemacht hatte.
Alberto Brandolini betrachtet die Ebene der Organisation. Eine Codebasis zu besitzen, argumentiert er, ist eine Balance aus Vertrauen und Verantwortung: Software selbst zu schreiben und zu testen gab Entwicklerinnen und Entwicklern das Vertrauen, die Verantwortung dafür zu übernehmen. KI-gestützte Entwicklung stört diese Balance, denn Codebasen wachsen jetzt schneller als das Vertrauen, während gleichzeitig manche Organisationen ihre Entwicklungsteams verkleinern und immer mehr Verantwortung in immer weniger Senior-Rollen bündeln. Sein Fazit ist deutlich: „increased accountability with lowered confidence isn't sustainable“. Wenn die Balance kippt, ist Gehen ein rationaler Karriereschritt.
Zsófia Herendi, die auf Brandolini antwortet, ergänzt die Ebene des Einzelnen. KI, so beobachtet sie, erhöht nicht nur die Verantwortung schneller als das Vertrauen. Sie erhöht auch das Gefühl von Vertrauen schneller als die tatsächliche Kompetenz. Eine Produktmanagerin kann heute mühelos beeindruckend aussehende Roadmaps und Rechercheberichte generieren, ohne das Problem dadurch besser zu verstehen. Schlimmer noch: KI beseitigt viele der Momente, in denen Urteilsvermögen bisher entstand. Annahmen infrage stellen, merken, dass die eigene Vorstellung vom Problem nicht stimmte, schwierige Gespräche führen: Diese Momente waren langsam und oft frustrierend, aber sie bauten im Stillen die Intuition auf, auf die sich Profis später verlassen haben. Sie bringt es auf den Punkt: „AI can accelerate output but it cannot shortcut experience“.
Andreas Bulling, der an einer deutschen Universität zu künstlicher Intelligenz forscht und lehrt, ergänzt die Ebene der nächsten Generation, und sie ist die ernüchterndste. In einem vielbeachteten Beitrag beschreibt er, was er eine „Welle der Inkompetenz“ nennt, die auf den Arbeitsmarkt zurollt: Übungsblätter, Programmieraufgaben, selbst ganze Abschlussarbeiten sind heute weitgehend KI-generiert. Wer diesen Studierenden eine einzige Nachfrage zu ihrem eigenen Code stellt, bekommt keine Antwort. Eine Generation betritt den Arbeitsmarkt, warnt er, deren einzige echte Fähigkeit das Bedienen einer KI ist. Seine Prognose: Die wenigen, die sich diesem Trend widersetzen, die sich Dinge wirklich erarbeiten, sie verstehen und durchdenken, werden sich bald jeden Job aussuchen können.
Die Organisation, der Einzelne, die nächste Generation: Das sind drei verschiedene Ebenen, aber ich sehe auf allen dasselbe Muster. Ich finde, dieses Muster verdient einen Namen.
Geliehenes Vertrauen
In der Softwareentwicklung gibt es zwei Arten von Vertrauen, und sie sind leicht zu verwechseln, weil sie sich von innen identisch anfühlen.
Verdientes Vertrauen ist das Produkt von Reibung. Du hast den Test zuerst geschrieben und ihn scheitern sehen. Du warst dir sicher, wo der Fehler steckt, und hast dich per Debugging zu der Stelle vorgearbeitet, an der du falsch lagst. Du hast einer Kollegin dein Design erklärt und ihre dritte Frage nicht beantworten können. Das sind genau die langsamen, frustrierenden Momente, die Zsófia Herendi beschreibt, und aus ihnen entsteht Urteilsvermögen.
Geliehenes Vertrauen ist das, was mein ACPATH-Experiment hervorgebracht hat. Der Code sieht sauber aus. Die Tests sind grün. Die Visualisierungen sind plausibel. Die Erklärung ist wortgewandt. Aber jedes einzelne dieser Signale wurde von demselben Agenten generiert, der auch die Implementierung geschrieben hat. Die Tests überprüfen den Code nicht gegen die wissenschaftliche Arbeit; sie zeigen lediglich, dass die Implementierung mit sich selbst übereinstimmt.
Ich habe angefangen, das als Vertrauenswäsche zu bezeichnen: Plausibilität geht hinein, scheinbare Gewissheit kommt heraus, und an keiner Stelle fließt ein unabhängiger Beleg in den Kreislauf ein.
Die Asymmetrie hat ein Alter
Diese drei Beobachtungen haben mir Folgendes klargemacht: Geliehenes Vertrauen wirkt sich unterschiedlich aus, je nachdem, wo du in deiner Laufbahn stehst.
Ich habe die Asymmetrie ein paar Stunden lang erlebt, und ich habe sie bemerkt. Ich habe sie bemerkt, weil ich mehr als 35 Jahre verdientes Vertrauen zum Vergleich habe. Ich weiß, wie sich fester Boden anfühlt, und deshalb konnte ich spüren, dass er unter der ACPATH-Implementierung fehlte.
Wer mitten in der Laufbahn steht, wie Brandolinis Senior-Entwickler mit wachsendem Aufgabenbereich oder Herendis Produktmanagerin unter Lieferdruck, hat noch Urteilsvermögen, aber KI beseitigt die Gelegenheiten, es auszuüben. Verdientes Vertrauen ist weniger ein Sparkonto als ein Muskel: Wird es nicht trainiert, hört es nicht einfach auf zu wachsen, es baut ab.
Und die Neulinge, die Bulling beschreibt, haben nie Vertrauen verdient. Für jemanden, dessen gesamte Ausbildung darin bestand, Prompts weiterzureichen, waren „richtig aussehen“ und „richtig sein“ nie getrennte Kategorien. Meine unangenehmen Stunden sind ihr Dauerzustand, nur ohne das Unbehagen. Die Asymmetrie tut denen nicht weh, denen sie am meisten schadet.
Brandolinis Beobachtung schließt diesen Kreis auf düstere Weise: Die Organisationen, die ihre Teams verkleinern, entfernen genau die erfahrenen Leute, die die Neulinge zu Kompetenz hätten führen können.
Vertrauen verdienen im KI-Tempo
So weit, so düster. Aber Vertrauen lässt sich auch in einer Domäne verdienen, die du nicht beherrschst. Du kannst es dir nur nicht von dem System leihen, das du überprüfen willst. Du brauchst unabhängige Belege. Seit der Veröffentlichung des ersten Artikels baue ich genau das für die ACPATH-Implementierung auf.
Die erste Quelle unabhängiger Belege ist ein Brute-Force-Orakel. Der ACPATH-Algorithmus ist clever; das macht ihn schwer zu überprüfen. Aber ein naiver Pfad-Enumerator, der buchstäblich jeden azyklischen Pfad durch einen kleinen Kontrollflussgraphen abläuft und zählt, ist die Art von Programm, die Sir Tony Hoare im Sinn hatte, als er von Software sprach, die so einfach ist, dass sie offensichtlich keine Mängel hat. Den kann ich selbst schreiben, und ich kann jede Zeile davon verstehen. Er ist viel zu langsam für echten Code, aber er muss nicht schnell sein. Er muss offensichtlich korrekt sein. Beide Implementierungen gegen Tausende kleiner, generierter Funktionen laufen zu lassen und die Ergebnisse zu vergleichen, ist Differential Testing: Die clevere Implementierung wird gegen die einfache geprüft, nicht gegen sich selbst.
Die zweite Quelle sind Eigenschaften, die aus der wissenschaftlichen Arbeit abgeleitet sind statt aus dem Code. Sequenzielle Entscheidungen multiplizieren die Pfadanzahl: Eine if-Anweisung, die an eine verzweigungsfreie Funktion angehängt wird, muss deren ACPATH-Wert verdoppeln. Einen Funktionsrumpf in eine Bedingung einzupacken, muss die Anzahl auf vorhersagbare Weise verändern. Diese metamorphen Relationen stammen aus der Spezifikation und sind damit per Konstruktion unabhängig von der Implementierung. Eine Implementierung, die Hunderte solcher Relationen über generierte Eingaben hinweg erfüllt, kann immer noch falsch sein, aber sie ist in einem viel kleineren Raum falsch.
Die dritte Quelle ist Mutation Testing. Wenn ich kleine Fehler in die KI-generierte Implementierung einbaue, bemerkt die KI-generierte Testsuite das? Wenn die Antwort Nein lautet, dann war die grüne Testsuite nie ein Beleg für irgendetwas, und das Vertrauen, das sie erzeugt hat, war von Anfang an geliehen.
Nichts davon gibt es geschenkt. Es ist langsamer, als die Ausgabe des Agenten einfach zu akzeptieren, und viel langsamer als die 15 Minuten, die der Agent gebraucht hat. Aber es verwandelt geliehenes Vertrauen in verdientes Vertrauen, und es ist dramatisch schneller, als erst Domänenexperte zu werden. Das ist, denke ich, die ehrliche Version des Produktivitätsversprechens: KI nimmt uns die intellektuelle Arbeit der Verifikation nicht ab. Sie verändert, wie diese Arbeit aussieht.
Die knappe Fähigkeit
Andreas Bulling prognostiziert, dass Menschen, die Dinge wirklich verstehen, bald händeringend gesucht werden. Für die Softwareentwicklung würde ich diese Prognose konkreter machen. Die knappe Fähigkeit wird sein, gerechtfertigtes Vertrauen in Code zu produzieren: zu wissen, was als Beleg zählt, Orakel zu konstruieren, Eigenschaften aus Spezifikationen abzuleiten und zu erkennen, wann die eigene Gewissheit aus Verstehen stammt und wann bloß aus einer sehr überzeugenden Antwort.
Das rückt eine Praxis in ein neues Licht, die viele für altmodisch halten. Testgetriebene Entwicklung war nie primär dazu da, Fehler zu finden. Den Test zuerst zu schreiben zwingt dich, das erwartete Verhalten aufzuschreiben, bevor eine Lösung existiert, die dich verführen kann. Das ist bewusstes Training für Urteilsvermögen: genau die Art von langsamem Moment, die KI-gestützte Arbeitsabläufe wegoptimieren und die wir jetzt absichtlich bewahren müssen.
Das Tippen lässt sich delegieren, vielleicht sogar der Entwurf. Die Verantwortung nicht, und Vertrauen, das Einzige, was Verantwortung tragbar macht, ist nicht übertragbar. Es muss verdient werden: von jeder Person, in jeder Domäne, jedes Mal.
