Verstehen ist der neue Flaschenhals
(geoffreylitt.com)- Während sich von Agenten geschriebener Code rund um Menschen immer weiter auftürmt, verschiebt sich der Faktor, der die Entwicklungsgeschwindigkeit begrenzt, von der Fähigkeit zur Codegenerierung hin zur Geschwindigkeit menschlichen Verstehens, also dazu, mit dem System Schritt zu halten und die nächste Veränderung zu entwerfen
- Der Zweck des Codeverstehens beschränkt sich nicht auf Verifikation, also Ergebnisse zu genehmigen oder abzulehnen, sondern liegt darin, in mehreren aufeinanderfolgenden Agenten-Arbeitsschleifen die nächste Idee vorzuschlagen und am kreativen Prozess teilzunehmen
- Wenn man statt roher Code-Diffs zuerst ein Code-Erklärdokument liest, das Hintergrundwissen, Änderungsziel, interaktive Diagramme und einen narrativen Code-Diff bündelt, lassen sich Struktur und Absicht einer Änderung schneller erfassen
- Quizfragen in Erklärdokumenten und Microworlds, in denen man den Ablauf direkt manipuliert, lassen nicht den Agenten stellvertretend urteilen, sondern ermöglichen Menschen, Zustandsänderungen und interne Abläufe des Systems selbst zu erleben
- Wenn AI nicht nur als Automatisierungsmittel genutzt wird, das Menschen aus der Schleife entfernt, sondern zum Erstellen von Werkzeugen und Simulationen für das Verständnis, können Menschen und Teams im Gegenteil noch tiefer an der Schleife teilnehmen
Menschen kommen mit der Geschwindigkeit der Codegenerierung nicht mehr mit
- Wie bei einem Codehaufen, der sich durch von Agenten geschriebenen Code immer höher um eine einzelne Person auftürmt, wächst die Menge des erzeugten Codes, doch die Geschwindigkeit, mit der Menschen ihn verstehen, steigt nicht im selben Verhältnis
- Alle Code-Diffs Zeile für Zeile zu lesen, reicht allein kaum aus, um mit der Arbeitsgeschwindigkeit von Agenten Schritt zu halten
- Zum Codeverstehen gibt es neben rohen Code-Diffs verschiedene Ansätze, etwa
- Code-Erklärdokumente, die System und Änderungen vermitteln
- Quizfragen, die tatsächliches Verständnis überprüfen
- Microworlds, in denen man interne Abläufe direkt manipuliert und erlernt
- Geteilte Räume, in denen das ganze Team dasselbe mentale Modell aufbaut
Verstehen dient nicht der Verifikation, sondern der Teilhabe
- Die gängige Antwort auf die Frage, warum Menschen Code verstehen müssen, lautet, dass sie die Arbeit des Agenten verifizieren sollen
- Prüfen, ob sie zur Spezifikation passt
- Beurteilen, ob die Struktur angemessen ist
- Am Ende über Genehmigung oder Ablehnung entscheiden
- In der Präsentation wird dies als binäre Entscheidung mit Daumen hoch oder runter dargestellt
- Wenn Verifikation als einzige Rolle des Menschen gesehen wird, wird Verstehen auf einen Prozess reduziert, der nur über Bestehen oder Nichtbestehen eines Ergebnisses urteilt
- Doch Agenten verbessern auch laufend ihre Fähigkeit zur Selbstverifikation, indem sie ihre eigenen Ergebnisse ausführen, prüfen und Fehler finden
- Je besser Agenten die Verifikation übernehmen, desto stärker stellt sich die Frage: Wo bleibt der Mensch?
- Die Alternative ist Teilhabe durch Verstehen
- Menschen müssen wissen, was der Agent tut, damit sie aktive Mitglieder des kreativen Prozesses bleiben können
- Wer das System versteht, bleibt nicht dabei stehen, das aktuelle Ergebnis zu bewerten, sondern kann überlegen, was im nächsten Schritt verändert werden soll
Ein Projekt ist nicht eine Schleife, sondern viele Schleifen
- Ein reales Projekt ist keine einzelne Schleife, in der man einem Agenten einmal eine Anweisung gibt und ein Ergebnis erhält
- Stattdessen sind zahlreiche iterative Schleifen aus Zielsetzung, Implementierung, Prüfung, Korrektur und Erweiterung miteinander verbunden
- In jeder Iteration bestimmt das Systemverständnis der Menschen Qualität und Reichweite der nächsten Ideen
- Nur mit ausreichend Konzepten und Strukturen im Kopf lassen sich Fragen wie diese souverän bearbeiten
- Was muss hinzugefügt oder entfernt werden?
- Welche Struktur muss verändert werden?
- Welche neuen Möglichkeiten entstehen durch die aktuelle Implementierung?
- Fehlt das Verständnis, kann man auf das vom Agenten erzeugte Ergebnis zwar mit „sieht ungefähr richtig aus“ reagieren, doch es wird schwer, die Richtung des Projekts aktiv zu bestimmen
Kognitive Schulden entstehen, wenn Verstehen aufgeschoben wird
- Wenn man die Ergebnisse eines Agenten weiter akzeptiert, ohne das System zu verstehen, kann man kurzfristig schnell vorankommen
- Doch so wie technische Schulden spätere Änderungskosten erhöhen, hinterlässt Arbeit, bei der Verständnis ausgelassen wurde, kognitive Schulden (cognitive debt)
- Wenn sich kognitive Schulden aufbauen, verlieren Projektbeteiligte den Gesamtzusammenhang
- Es wird schwer zu verstehen, warum der Code seine aktuelle Struktur hat
- Es wird schwer zu beurteilen, wo neue Anforderungen anzuschließen sind
- Es wird schwer zu diskutieren, ob die nächste vom Agenten vorgeschlagene Änderung sinnvoll ist
- Das Problem im AI-Zeitalter ist nicht, dass kein Code erzeugt wird, sondern dass Menschen nicht genügend Konzepte über das erzeugte System besitzen
Pädagogische Methoden auf Codeverstehen anwenden
- Das Problem, menschliches Verständnis in einer sich schnell verändernden AI-Arbeitsumgebung aufzubauen, ähnelt einem Problem, mit dem sich Bildung seit Langem beschäftigt
- Statt neue Fakten nur zu vermitteln, müssen Hintergrundwissen, Intuition, Übung und Feedback gemeinsam angeboten werden, damit echtes Verständnis entsteht
- Auch auf Codeverstehen lassen sich in der Bildung entwickelte Methoden anwenden
- Vor den Implementierungsdetails Hintergrund und Intuition vermitteln
- Nach dem Lesen Inhalte abrufen und beantworten lassen
- Eine Umgebung bereitstellen, in der abstrakte Regeln direkt manipuliert werden können
- Dafür sorgen, dass Menschen dieselben Konzepte und Begriffe teilen
/explain-diff lehrt, was sich geändert hat
- /explain-diff ist ein Skill, der von einem Agenten vorgenommene Änderungen in ein strukturiertes Erklärdokument umwandelt
- Die Ausgabe kann als HTML-, Markdown- oder Notion-Seite erfolgen; ein Notion-Dokument kann als kollaboratives Artefakt genutzt werden, in dem Teammitglieder kommentieren und gemeinsam diskutieren
- Erzeugt wird nicht einfach eine Liste von Codeänderungen, sondern Erklärungsmaterial, das darauf ausgelegt ist, dass Menschen die Änderungen lernen
- Im Beispiel einer veränderten Perspektive in einer Spielansicht wird nicht sofort Code gezeigt, sondern in dieser Reihenfolge vorgegangen
- Zuerst wird erklärt, wie die bestehende Game-Engine rendert
- Dann wird das Änderungsziel formuliert: „Mit 2D-Zeichentechniken einen Garten räumlich wirken lassen“
- Es wird erklärt, was isometrische Projektion ist, damit das visuelle Prinzip der Änderung verständlich wird
- Danach geht es zum tatsächlichen Implementierungscode
Zuerst Hintergrundwissen vermitteln
- Gute Erklärungen beginnen nicht mit „Was hat sich geändert?“, sondern mit „Was war vor der Änderung vorhanden?“
- Ohne das Koordinatensystem und die Rendering-Struktur der bestehenden Game-Engine zu kennen, ist es schwer, allein durch Lesen des neuen Perspektiv-Codes den Grund der Änderung zu verstehen
- Das Erklärdokument ergänzt zuerst die Struktur des bestehenden Systems, damit Menschen ohne denselben Hintergrund wie der Agent am Gespräch teilnehmen können
- Das ist keine bloße Zusammenfassung, sondern ein Prozess, der Menschen in den aktuellen Projektkontext zurückholt
Vor Implementierungsdetails zuerst Intuition aufbauen
- Wenn das Wesen der Änderung vor dem Code in einem Satz erklärt wird, versteht man, auf welches Ziel die Implementierungsdetails hinarbeiten
- Im Beispiel, den Garten räumlich wirken zu lassen, werden nicht zuerst die Formeln der isometrischen Projektion erklärt, sondern zunächst das visuelle Ziel vermittelt, eine flache Zeichnung dreidimensional erscheinen zu lassen
- Hat man Hintergrund und Ziel verstanden, lassen sich beim Betrachten von Codefragmenten die Rollen der einzelnen Berechnungen und Transformationen im Gesamtergebnis leichter verbinden
- Ziel ist, Menschen nicht zu passiven Lesern detaillierten Codes zu machen, sondern zu gleichberechtigten Beteiligten, die die Änderungsabsicht verstehen
Koordinatenänderungen mit interaktiven Diagrammen erleben
- Statt nur statische Bilder zu zeigen, wird ein interaktives Diagramm verwendet, in dem man einen Stein im Garten direkt per Drag-and-drop bewegen kann
- Bewegt man den Stein, verändern sich zugleich seine Position auf dem Bildschirm und die internen Koordinaten, sodass die Koordinatentransformation der isometrischen Projektion nachvollziehbar wird
- Im Vergleich zum bloßen Lesen von Formeln oder Code kann man die Beziehung zwischen Eingabe und Ausgabe direkt manipulieren und so Intuition aufbauen
- Interaktives HTML kann in eine Notion-Seite eingebettet werden, sodass das Code-Erklärdokument selbst zu einer kleinen Ausführungsumgebung wird
- AI kann nicht nur Erklärtexte schreiben, sondern auch die für Verständnis nötigen Visualisierungen und Manipulationswerkzeuge erzeugen
Rohe Code-Diffs in narrative Code-Diffs verwandeln
- Gewöhnliche Code-Diffs listen geänderte Dateien in der Reihenfolge der Dateinamen auf
- Sie erklären nicht die Beziehungen zwischen Dateien
- Sie nennen nicht den Zweck der Änderung
- Sie geben keine Anleitung, in welcher Reihenfolge man lesen sollte
- Ein narrativer Code-Diff (literate diff) rekonstruiert Änderungen wie den Ablauf eines Textes
- Er stellt zuerst den Zweck der Änderung vor
- Er erklärt Dateien und Funktionen in einer fürs Verständnis passenden Reihenfolge
- Er fügt nur die jeweils nötigen Codefragmente zwischen die Erklärungen ein
- Er zeigt auch die Beziehungen zwischen umgebendem Kontext und Implementierungsentscheidungen
- Wenn ein roher Code-Diff einem unverarbeiteten Haufen Material gleicht, kommt ein narrativer Code-Diff eher einer zu einer Geschichte editierten Darstellung des Änderungsprozesses nahe
- Liest man zuerst die Erklärung und prüft danach den rohen Code-Diff, weiß man, warum jedes Codefragment existiert, und kann dadurch schneller reviewen
Von AI erstellte Erklärungen auf Papier lesen
- Das fertige Erklärdokument kann wie ein Code-Erklärungspaket genutzt werden
- Rohe Code-Diffs werden weiterhin gelesen, aber immer nach dem Erklärdokument
- Wenn Konzentration nötig ist, wird das Dokument ausgedruckt und im Café auf Papier gelesen
- Es entsteht das Paradox, dass die interaktive Tätigkeit des Programmierens mit AI zu einem statischen Papierbericht wird, in den man sich tief vertiefen kann
- Entscheidend ist nicht, die allerneueste Oberfläche zu verwenden, sondern Informationen in eine Form zu bringen, die Menschen tatsächlich gut verstehen können
Der Unterschied zwischen dem Gefühl, gelesen zu haben, und echtem Verständnis
- Auch ein gut aufgebautes Erklärdokument garantiert nicht, dass der Akt des Lesens selbst Verständnis schafft
- Menschen neigen dazu, schon weil ihre Augen den Sätzen gefolgt sind, fälschlich zu glauben, sie hätten den Inhalt behalten oder verstanden
- Die Idee stammt aus Andy Matuschaks „books don't work“ sowie Andy Matuschak und Michael Nielsens Quantum Country
- Quantum Country bettet Spaced-Repetition-Quizfragen in den Text ein, damit Leser Inhalte aktiv abrufen
- Derselbe Ansatz wird auf Code-Erklärdokumente angewandt, indem am Ende fünf interaktive Fragen zu den Änderungen platziert werden
Quizfragen sind der Geschwindigkeitsregler der AI-Schleife
- Es gilt die Regel, dass man das Quiz im Erklärdokument bestehen muss, bevor Code an andere geschickt wird
- Beim Review von Code anderer Personen wird derselbe Maßstab angelegt
- Das Quiz ist kein Zusatzfeature zur Wissensbewertung, sondern ein Geschwindigkeitsregler
- Bei der Arbeit mit AI laufen Implementierungs-, Korrektur- und Regenerationsschleifen leicht schneller ab als menschliches Verstehen
- Das Quiz sorgt dafür, dass in jeder Schleife mechanisch die nächsten Fragen gestellt werden
- Kann man erklären, was sich tatsächlich geändert hat?
- Versteht man, warum diese Struktur verwendet wurde?
- Kennt man die Constraints, die sich auf die nächste Änderung auswirken?
- Besteht man nicht, muss die Arbeitsgeschwindigkeit gesenkt und Verständnis nachgeholt werden, sodass Menschen kreative Beteiligte bleiben können
Microworlds aus Seymour Paperts Mathland
- Die zweite Methode, Microworlds, geht auf eine Idee des Pädagogen Seymour Papert zurück
- Papert meinte: So wie man zum Französischlernen in Frankreich lebt, müsse man zum Mathematiklernen in einem Mathland leben, in dem Mathematik natürlich funktioniert
- Statt passiv Erklärungen zu hören, erkunden Kinder die Umgebung ihrer Neugier folgend und eignen sich mathematische Konzepte auf natürliche Weise an
- Auf Code übertragen heißt das, nicht nur Dokumente zur Erklärung eines Systems bereitzustellen, sondern eine Umgebung zu schaffen, in die Menschen eintreten und die Funktionsweise direkt erleben können
- Eine Microworld ist eine kleine Welt, die so gestaltet ist, dass bestimmte Prinzipien und Zustandsänderungen gut beobachtbar sind, statt das gesamte Produktionssystem unverändert offenzulegen
Einen Prolog-Interpreter entlang der Zeitachse erkunden
- Bei der Entwicklung eines Prolog-Interpreters war es schwer, intuitiv zu erfassen, was intern geschah
- Gemeinsam mit dem Agenten wurde ein spezialisierter Debugger gebaut, mit dem sich der Ablauf Schritt für Schritt erkunden lässt
- In diesem Debugger kann man direkt sehen
- wie man die Ausführungszeit vor- und zurückbewegt
- welche Werte sich im aktuellen Stack befinden
- welche Regeln in jedem Schritt ausgewertet werden
- wie man in dem Moment, in dem eine bestimmte Regel korrekt angewandt wurde, eine Notiz hinterlässt
- Statt nur das fertige Ergebnis zu sehen, kann man direkt nachverfolgen, wie sich die Ausführung einer logischen Sprache über die Zeit entfaltet
- Überlässt man dem Agenten das Debugging, kann das Problem gelöst werden; doch erst wenn Menschen den Debugger selbst bedienen, entsteht Verständnis für die Ausführungsstruktur
Der Unterschied zwischen Debugging durch den Agenten und dem Bau von Verständniswerkzeugen
- „Der Agent findet und behebt das Problem“ und „Der Agent baut ein Werkzeug, mit dem Menschen das Problem erkunden können“ führen zu unterschiedlichen Ergebnissen
- Ersteres liefert schnell ein Arbeitsergebnis, kann aber dazu führen, dass das menschliche Verständnis des internen Prozesses kaum wächst
- Letzteres bietet einen Erkundungsprozess, in dem Menschen Ausführungszustände untersuchen, Hypothesen aufstellen und Ergebnisse prüfen
- Während Teile des Codings an den Agenten abgegeben werden, können das zentrale Denken und Erkunden von Menschen selbst übernommen werden
- Dieser Ansatz erweitert die Rolle des Agenten vom Lieferanten richtiger Antworten zum Hersteller von Verständnisumgebungen
Eine Website-Migration wie ein Spiel durchführen
- Beim Umzug einer persönlichen Website von einem Framework auf ein anderes schrieb Claude ein Automatisierungsskript
- Da das neue Framework ungewohnt war, ließ sich das Skript beim Lesen kaum über „sieht ungefähr richtig aus“ hinaus bewerten
- Zur Lösung wurde Claude gebeten, eine Kommandozentrale in Form eines Videospiels zu bauen, mit der die Migration direkt durchgeführt wird
- In der Kommandozentrale lässt sich der Ablauf visuell verfolgen
- Per Button werden Migrationsschritte einzeln ausgeführt
- Die alte und die neue Site werden nebeneinander auf beiden Bildschirmseiten angezeigt
- Bei jedem Schritt wird sichtbar, wie sich die neue Site verändert
- Man kann beobachten, in welcher Reihenfolge sich der Dateibaum verändert
- Statt die gesamte Transformation auf einmal auszuführen, erlebt man direkt, wie die neue Site schrittweise lebendig wird
- Man gewinnt ein Verständnis ähnlich wie beim manuellen Verschieben aller Dateien, kommt aber viel schneller voran, weil die nötige Arbeit und Beobachtungsumgebung vorbereitet sind
Code erzeugen, um Code zu verstehen
- Code, den ein Agent schreiben kann, ist nicht auf Produktfeatures oder Automatisierungsskripte beschränkt
- Er kann auch temporäre Werkzeuge erstellen, die Menschen helfen, anderen Code zu verstehen, etwa
- Tools zur Ausführungsvisualisierung
- Schrittweise Debugger
- Side-by-Side-Vergleichsansichten
- Anzeigen für Veränderungen im Dateibaum
- Interaktive Konzepterklärungen
- Kommandozentralen, die Arbeit in kleine Schritte zerlegen
- Solche Werkzeuge haben ausreichend Wert, selbst wenn sie kein langfristig gepflegter Produktcode sind
- Da die Kosten der Codeerstellung mit AI sinken, werden auch einmalige Lernumgebungen für bestimmte Personen und bestimmte Aufgaben praktisch realisierbar
Teams müssen gemeinsam verstehen
- Dass Einzelne ein System verstehen, reicht für Teamarbeit nicht aus
- Teammitglieder müssen dasselbe mentale Modell besitzen, damit schon kurze Formulierungen dieselben Strukturen und Verhaltensweisen hervorrufen
- Mit gemeinsamem Vokabular und gemeinsamen Bildern lassen sich Ideen spontan austauschen und neue Richtungen gemeinsam weiterentwickeln
- Arbeiten dagegen alle isoliert mit jeweils eigenen Agenten, entstehen folgende Probleme
- Dieselben Begriffe werden mit unterschiedlichen Bedeutungen verwendet
- Die Annahmen technischer Pläne werden nicht geteilt
- Ergebnisse lassen sich zusammenführen, aber Verständnis wird nicht zusammengeführt
- AI-Nutzung im Team ist nicht nur eine Frage höherer individueller Produktivität, sondern auch die Aufgabe, gemeinsames Verständnis im ganzen Team aufzubauen
Die Arbeit von Agenten und Menschen im selben geteilten Raum hinterlassen
- In Notion können Claude- und Cursor-Agenten innerhalb einer Seite ausgeführt werden
- Von Agenten verfasste technische Pläne entstehen standardmäßig auf kollaborativen Seiten
- Teammitglieder können einen vom Agenten erstellten Plan direkt an derselben Stelle prüfen, ohne ihn in einen separaten Kanal zu kopieren
- Kommentare zu bestimmten Sätzen hinterlassen
- Implementierungsentscheidungen hinterfragen
- Den Plan gemeinsam bearbeiten
- Die Diskussion des Teams und die Ergebnisse des Agenten in einem Kontext festhalten
- Statt dass Agenten in persönlichen Silos arbeiten, denken Menschen und Agenten rund um ein gemeinsames Dokument
- Ein geteilter Raum ist kein Dokumentenschrank zum Speichern von Ergebnissen, sondern ein Ort, an dem das Team gemeinsam mentale Modelle aufbaut
Der Zweck von Computern war von Anfang an Erweiterung
- Das Thema Erklärungen, Quizfragen und Microworlds für Codeverstehen ist nicht auf Programmierung beschränkt
- Menschen brauchen Wissen nicht nur, um Ergebnisse zu verifizieren, sondern um zu verstehen, wie die Welt funktioniert, und sich an Veränderungen zu beteiligen
- Alan Kay entwarf Computer vor rund 50 Jahren als neues Bildungsmedium, das besser als Bücher sein sollte
- Die damaligen Zeichnungen zeigen Kinder, die auf tabletartige Geräte schauen, aber nicht passiv Videos ansehen
- Sie manipulieren interaktive Physiksimulationen
- Sie spielen ein Spiel und ändern direkt den Code
- Sie sehen, wie der veränderte Code die physische Bewegung verändert
- Computer können statt Maschinen zur Übermittlung statischer Informationen ein dynamisches Medium sein, mit dem man komplexe Konzepte bewegt, verändert und versteht
Nicht nur Automatisierung, sondern tiefere Teilhabe
- Der Kern wird durch ein Meme ausgedrückt: Ein Astronaut blickt auf die Erde und fragt: „War der Zweck von Computern, dynamische Simulationen zum Verstehen komplexer Konzepte zu erstellen?“, worauf der Astronaut dahinter antwortet: „Schon immer.“
- Wenn man den Zweck von Computern und AI nur darin sieht, menschliche Arbeit zu entfernen, können Menschen aus dem System hinausgedrängt werden
- Nutzt man AI dagegen zum Erstellen von Erklärungen, Simulationen, Microworlds und geteilten Räumen, können Menschen mehr Konzepte tiefer verstehen
- Während AI die Kosten für den Bau von Simulationen senkt, lassen sich bei Bedarf maßgeschneiderte Umgebungen zum Erlernen bestimmter Konzepte erzeugen
- Ziel ist nicht nur, Menschen aus der Schleife zu nehmen, sondern sie tiefer als zuvor in die Schleife hineinzubringen
Verwandte Beiträge
- Enough AI copilots! We need AI HUDs - AI-Interfaces, die über Copilots hinausgehen und den menschlichen Geist direkter erweitern
- AI-generated tools can make programming more fun - Ein Beispiel, bei dem eine maßgeschneiderte Debugger-UI mit AI erstellt wurde, um den Prozess des direkten Programmierens durch Menschen zu verbessern
- Code like a surgeon - Ein Ansatz, bei dem nebensächliche Routinearbeit delegiert wird und Menschen sich auf die Kernaufgabe konzentrieren
2 Kommentare
Um den Bottleneck vollständig zu beseitigen,
Da die menschliche Kognitions- und Gedächtnisstruktur in Kurzzeit- und Langzeitgedächtnis unterteilt ist, möchte ich sagen, dass es im Hinblick auf kognitive Schulden am effizientesten ist, wenn Menschen zwischendurch immer wieder überprüfen und dabei Kurzzeitgedächtnis aufbauen, ganz gleich, wie sehr man versucht, auf diese Weise die Coding-Geschwindigkeit von KI zu erhöhen.