Geoffrey Litt, Design Engineer bei Notion, sitzt vor einem Berg von Code-Diffs. Sein KI-Agent schreibt täglich neue Funktionen, refaktoriert Module und migriert Frameworks. Der Output ist beeindruckend, aber Litt überkommt ein ungutes Gefühl. Er scrollt durch die Änderungen und merkt: Er versteht nur noch die Hälfte davon. Vielen Entwicklern geht es ähnlich. Der Flaschenhals der Softwareentwicklung ist nicht mehr die Fähigkeit der Maschinen, Code zu produzieren. Der Engpass liegt woanders: zu verstehen, was dieser Code tut.
In seinem Vortrag stellt Litt die These auf: Verständnis ist der neue Engpass. Während KI-Agenten mehr Code schreiben, wächst die Kluft zwischen dem, was produziert wird, und dem, was Menschen geistig nachvollziehen können. Die naheliegende Antwort – mehr Vertrauen, weniger Kontrolle – hält er für falsch. Stattdessen schlägt er Techniken vor, die menschliches Verständnis in den KI-Entwicklungsprozess integrieren. Es geht nicht darum, jeden Diff zu lesen. Es geht darum, als Mensch aktiv am kreativen Prozess beteiligt zu bleiben.
Warum Verstehen mehr ist als bloßes Kontrollieren
Die erste intuitive Antwort: Wir verstehen Code, um ihn zu verifizieren. Wir prüfen, ob die Arbeit des Agenten korrekt ist, ob sie der Spezifikation entspricht und ob die Architektur sauber bleibt. Das ist ein Daumen-hoch-oder-Daumen-runter-Spiel. Doch Litt weist darauf hin, dass dieses Argument schwächer wird. KI-Agenten werden besser darin, ihre eigene Arbeit zu prüfen und Fehler zu finden. Das ist gut – niemand will einen Agenten, der Unsinn produziert. Aber wenn die Maschinen ihre Arbeit selbst verifizieren können, wo bleibt dann der Mensch?
Litts Antwort ist anders: Wir verstehen nicht nur, um zu kontrollieren, sondern um zu partizipieren. Ein Projekt ist nie nur eine Schleife aus Prompt und Ergebnis. Es besteht aus vielen iterativen Zyklen, in denen Mensch und Agent zusammenarbeiten. Verständnis ist entscheidend, weil die Konzepte, die du im Kopf hast, die Basis für deine nächste kreative Idee sind. Wenn du nicht fließend mit den Bausteinen des Systems denken kannst, fehlt dir die Basis, um das Projekt sinnvoll weiterzuentwickeln. Deine Fähigkeit, als aktiver Teilnehmer am Gestaltungsprozess aufzutreten, hängt direkt davon ab, wie gut du das System verstehst.
Das Phänomen hat einen Namen. Margaret Storey und Simon Willison prägten den Begriff der kognitiven Schulden. Wie bei technischen Schulden profitierst du eine Weile davon, Dinge nicht zu verstehen. Aber irgendwann holt es dich ein. Wenn Entwicklungsteams den Überblick verlieren, was ihre KI-Agenten tun, entsteht ein stiller Prozess: Der Code wächst, das Verständnis der Menschen wächst nicht mit. Und dann bricht es zusammen.
Erklärungen als erstes Werkzeug gegen die Verständnislücke
Litt hat praktische Antworten auf die wachsende Verständnislücke. Sein erster Ansatzpunkt sind Erklärungen. Wenn ein Agent eine Aufgabe abgeschlossen hat, entsteht natürliches Rohmaterial: ein Code-Diff. Die einfache Methode ist, diesen Diff zu lesen. Aber ist das die beste Art, Verständnis aufzubauen? Litt stellt eine andere Frage: Wie würde die beste Erklärung aussehen? Wenn ein Team – menschlich oder künstlich – Wert darauf legt, etwas gut zu erklären, wie sähe das Ergebnis aus?
Aus dieser Überlegung heraus hat Litt /explain-diff entwickelt. Das Tool erstellt strukturierte Code-Erklärungen als HTML, Markdown oder Notion-Dokumente. Das Prinzip folgt guter Pädagogik. Bevor der veränderte Code gezeigt wird, erklärt die Erklärung den Hintergrund. Am Beispiel eines Videospiels, das die Perspektive wechselt, zeigt Litt, wie das funktioniert: Das Dokument lehrt zuerst die Grundlagen der Spiel-Engine, erläutert Konzepte wie isometrische Projektion und baut so Intuition auf. Erst danach folgt der Code. Entscheidend ist: Intuition vor Details. Anstatt dich mit einer alphabetischen Liste geänderter Dateien zu konfrontieren, bekommst du eine Erzählung. Der Diff wird zu Prosa, die in logischer Reihenfolge durch die Änderungen führt.
Diese Erklärung erreicht ein Ziel. Sie holt dich auf den aktuellen Stand. Du bist nicht mehr derjenige, der hinterherhinkt, sondern gleichwertiger Partner im Gespräch über den Code. Litt setzt zusätzlich auf interaktive Elemente. In manchen Erklärungen kann man direkt in der Seite herumspielen – zum Beispiel Steine in einem isometrischen Garten verschieben und beobachten, wie sich die Koordinaten ändern. So entsteht Verständnis, das über bloßes Lesen hinausgeht.
Quizze als Temporegler für menschliches Verständnis
Eine gute Erklärung allein reicht nicht. Am Ende jedes Explainers wartet ein interaktives Quiz. Fünf Fragen über die Änderungen, die Litt beantworten muss, bevor er zufrieden ist. Seine Regel ist streng: Er schickt keinen Code an andere weiter, bis er das Quiz bestanden hat. Dasselbe Prinzip gilt beim Review des Codes seiner Kollegen. Das mag streng klingen, aber Litt hat gute Gründe.
Das Quiz wirkt als Geschwindigkeitsregler in der KI-Schleife. Mit KI-Agenten passiert es leicht, dass der Entwicklungszyklus schneller läuft als das menschliche Verständnis. Der Agent produziert, der Mensch nickt ab, und irgendwann ist das System ein Fremdkörper. Das Quiz ist die Gegenkraft. Es zwingt dich, die Frage zu beantworten: Verstehe ich das wirklich? Diese Selbstprüfung ist der Schlüssel, um ein vollwertiger kreativer Teilnehmer zu bleiben – nicht nur ein Passagier im eigenen Projekt.
Was für einzelne Entwickler funktioniert, lässt sich auf Teams übertragen. Stellen wir uns vor, jedes Review beginnt mit einer kurzen Wissensabfrage. Das klingt nach Bürokratie, ist aber ein effizienter Weg, um sicherzustellen, dass alle Teammitglieder das gleiche Verständnis haben. Die Zeit für das Quiz spart später viel Verwirrung und Missverständnisse.
Mikrowelten: Spielerisch Systeme begreifen
Die zweite Technik sind Mikrowelten. Litt bezieht sich auf eine Idee des Pädagogen Seymour Papert, der von einem Leben in Mathematikland träumte. Wenn man Französisch lernen will, zieht man nach Frankreich. Also: Wer Mathematik lernen will, sollte in einer Umgebung leben, in der mathematisches Verständnis natürlich wächst. Papert wollte Umgebungen bauen, in denen Kinder Mathematik aus Neugier lernen – ungezwungen und intrinsisch motiviert. Litt überträgt diese Idee auf Code. Kann man Welten bauen, die du bewohnst und in denen du natürlich verstehst, wie ein System funktioniert und wie es sich verändert?
Ein Beispiel: Litt entwickelte letztes Jahr einen Prolog-Interpreter. Während der Arbeit merkte er, dass er Schwierigkeiten hatte, zu verstehen, was im Inneren der Logiksprache passiert. Also bat er seinen Agenten, einen Debugger zu bauen. Das Ergebnis war ein Werkzeug, mit dem er durch die Ausführung seiner Sprache schritt – durch die Zeit scrollte, den Stack inspizierte und sehen konnte, welche Regeln bei jedem Schritt ausgewertet wurden. Sogar Kommentare konnte er hinterlassen. Der Unterschied zwischen einem Tool, das der Agent für dich baut, und einem, das du selbst benutzt, ist groß. Indem du selbst durch den Prozess schrittst, baust du nebenbei Verständnis auf. Du beobachtest nicht nur das Ergebnis, sondern erlebst den Ablauf.
Ein zweites Beispiel. Litt musste seine Website von einem Framework auf ein anderes migrieren. Sein Agent schrieb ein Skript, das das automatisch erledigte. Aber das Review war schwierig – Litt kannte das neue Framework nicht gut und konnte nur sagen: Sieht ungefähr richtig aus. Statt sich mit diesem vagen Gefühl zu begnügen, bat er seinen Agenten, ein Videospiel zu bauen: eine Kommandozentrale, in der er die Migration selbst durchführt, Schritt für Schritt. Die UI zeigte ihm Buttons, um die Migration Teilschritt für Teilschritt auszuführen, während alte und neue Website nebeneinander live liefen. So schaute Litt zu, wie die neue Seite Stück für Stück entstand. Am Ende hatte er ein ähnliches Verständnis, als hätte er alles von Hand gemacht – aber schneller, weil die Erfahrung für ihn aufbereitet war. Der Kern: Agenten können Code schreiben, um Menschen zu helfen, anderen Code zu verstehen.
Gemeinsame Räume: Verständnis im Team entwickeln
Bisher ging es um individuelles Verständnis. Aber die wenigsten arbeiten allein. Litts dritte Technik zielt auf gemeinsame Räume. Wenn mehrere Personen eine gemeinsame Vorstellung des Systems teilen, kommunizieren sie effizient. Ein geteilter Wortschatz ruft dieselben Bilder hervor – das ermöglicht schnelles, kreatives Denken. Ohne diese geteilten Strukturen sind Gespräche über Code und Architektur mühsamer.
Litt mag Umgebungen, in denen Teams gemeinsam Verständnis aufbauen. Als Mitarbeiter von Notion nennt er ein Beispiel: Claude- und Cursor-Agenten laufen inzwischen direkt in Notion-Dokumenten. Wenn diese Agenten einen technischen Plan erstellen, geschieht das in einer kollaborativen Seite. Das Team kann sofort kommentieren und diskutieren. Verständnis entsteht nicht mehr in Silos, sondern im gemeinsamen Raum. Das ist die Weiterentwicklung der Idee: Denken zusammen statt allein.
Das geht über Code hinaus. Laut Litt war es schon immer wichtig für Menschen zu verstehen, wie die Dinge funktionieren. Nicht nur, um Ergebnisse zu verifizieren, sondern um aktiv mitzugestalten. Die Idee ist alt. Vor fast fünfzig Jahren hatte Alan Kay die Vision, dass Computer ein neues Medium sein könnten – besser als Bücher –, um Menschen, insbesondere Kindern, beizubringen, wie man über die Welt denkt. Auf den ersten Blick sah es so aus, als würden Kinder auf einem Tablet Videos schauen. Tatsächlich spielten sie ein interaktives Spiel und bearbeiteten dabei den Code, um die Physik besser zu verstehen. Schon damals war die Idee klar: Nicht nur automatisieren, sondern den Menschen erweitern.
Litt endet mit einer optimistischen Perspektive. KI macht es zugänglich, Simulationen zu erstellen, die uns Dinge beibringen. Diese Technik demokratisiert Bildung und Verständnis. Das ist eine große Möglichkeit, die das Computing eröffnet. Die Werkzeuge, die Litt und andere entwickeln, zielen nicht darauf ab, den Menschen aus der Schleife zu nehmen. Sie versuchen das Gegenteil: uns tiefer in den Prozess zu integrieren. Durch Erklärungen, Quizze, Mikrowelten und gemeinsame Räume wird Verständnis zum gestalteten Teil des Entwicklungsprozesses – nicht als Kontrollmechanismus, sondern als Fundament für kreative Teilhabe. Wenn diese Ideen sich durchsetzen, basiert die Zusammenarbeit zwischen Mensch und Maschine nicht auf Vertrauen oder Kontrolle, sondern auf echtem, gemeinsamem Verständnis.
Quelle: geoffreylitt.com
