Schneller coden, weniger verstehen: Die Systemdynamik von Coding-Agents

Ich habe an einer Policy für KI-gestützte Entwicklung bei einem Open-Source-Projekt geschrieben, und irgendwo zwischen „wer verantwortet Code, den niemand Zeile für Zeile gelesen hat" und „was passiert, wenn die Review-Kapazität nicht mehr mit der Codeproduktion mithält" ist mir aufgefallen, dass ich gar keine Policy mehr schreibe. Ich war dabei, ein Systemdynamik-Diagramm auf eine Serviette zu kritzeln.

Also habe ich Claude das Diagramm zeichnen lassen. Und dann den Blogpost schreiben.

Das Modell

Fünf Knoten, drei Feedbackschleifen. Systemdynamik — als Methode in den 1950ern am MIT entwickelt, Jay Forrester — modelliert nicht einzelne Ursachen, sondern die Struktur der Rückkopplungen: welche Schleifen verstärken sich gegenseitig, welche bremsen, und wo sind die Verzögerungen, die dafür sorgen, dass Probleme erst sichtbar werden, wenn sie schon tief sitzen? Wer schon mal einem Team beim langsamen Kontrollverlust über seine Codebase zugesehen hat, dem wird die Struktur hier bekannt vorkommen.

Neun Knoten; drei externe Kräfte, drei interne Feedbackschleifen und ein Output. Klickt mal auf „Delivery Pressure", um den Druck zu erhöhen, und schaut zu, wie das Signal durch das System propagiert. Dann auf „Compliance" als Gegengewicht.

Schleife 1: Die Produktivitätstretmühle

Mehr Agent-Autonomie → mehr Code-Output → höhere Erwartungen
→ Druck, Agents mehr zu nutzen → mehr Agent-Autonomie

Das ist das Jevons-Paradoxon im Hoodie. Euer Team führt Coding-Agents ein, die Velocity geht hoch, das Management merkt’s. „Klasse, damit planen wir ab jetzt." Und plötzlich sind die Agents nicht mehr optional, sondern die Baseline — und jeder Versuch, langsamer zu machen und in Verständnis zu investieren, läuft gegen „aber wir haben letztes Quartal dreimal so viel ausgeliefert."

Das Muster dahinter — Effizienzgewinne, die von gestiegenen Erwartungen aufgefressen werden, statt in Puffer umgewandelt — ist älter als Software. Ruth Schwartz Cowan hat es für Waschmaschinen dokumentiert: Amerikanische Hausfrauen verbrachten in den 1920ern 52 Stunden pro Woche mit Hausarbeit, und in den 1960ern — nach Waschmaschine, Staubsauger und Wasseranschluss — immer noch 52 Stunden. Die Maschinen schufen keine Freizeit; sie schufen höhere Sauberkeitsstandards. Wäsche, die vorher wöchentlich gewaschen wurde, kam jetzt nach jedem Tragen in die Maschine. Die Technologie wurde schneller, die Zielmarken wanderten mit, die Stunden blieben gleich. Was bei Coding-Agents neu ist, ist die Geschwindigkeit, mit der sich die Tretmühle dreht: bei Haushaltsgeräten hat sich der Zyklus über Jahrzehnte eingependelt. Coding-Agents schaffen es innerhalb weniger Sprints.

Eine achtmonatige Ethnographie in einem US-Techunternehmen (Ranganathan und Ye, HBR) hat exakt diesen Zyklus dokumentiert: KI beschleunigte die Aufgaben, die Erwartungen stiegen proportional, die KI-Abhängigkeit nahm zu, und die Arbeitsbelastung intensivierte sich, ohne dass es tatsächlich Zeitersparnis gegeben hätte. Für Technikhistoriker:innen wenig überraschend; für die Branche offenbar schon.

Schleife 2: Die Skill-Erosions-Spirale

Mehr Agent-Autonomie → weniger manuelles Coden → geringere Skills
→ weniger Fähigkeit, Agent-Output zu bewerten → Durchwinken beim Review
→ ungerechtfertigtes Vertrauen → mehr Agent-Autonomie

Diese Schleife hat eine Verzögerung, und genau die macht sie gefährlich. Aber bevor wir in Panik verfallen: Skill-Erosion durch Abstraktion ist normal. Niemand kann mehr Assembler, und niemand vermisst es. Jeder Abstraktionswechsel — Assembler→C→Python→Framework — hat Skills obsolet gemacht, und die Antwort war jedes Mal: die alten Skills waren die falschen zum Behalten.

Die Frage ist also nicht „verlieren wir Skills?" — natürlich tun wir das. Die Frage ist: verlieren wir die richtigen?

Bei Assembler→C verschiebt sich die Abstraktionsebene, aber der Mensch versteht die neue Ebene. Du kannst Python nicht debuggen, ohne ein Modell davon zu haben, was Python tut. Bei Agent-generiertem Code ist das anders: der Output ist auf derselben Abstraktionsebene — derselbe Python-Code, dieselben Frameworks — aber der Mensch hat den Denkprozess nicht durchlaufen. Das ist nicht Abstraktion. Das ist Delegation. Assembler-Skills haben wir ersetzt; hier werden Verständnis-Skills übersprungen.

Ob das ein Problem ist oder eine neue Normalität, ist eine offene Frage. Vielleicht landen wir in einer Welt, in der man Code nicht mehr Zeile für Zeile versteht, so wie heute niemand mehr jeden Assembler-Befehl seines Compilers versteht — und es funktioniert trotzdem. Aber die Indizien, die wir bisher haben, deuten in eine andere Richtung:

Clive Thompsons „Coding After Coders" im NYT Magazine porträtierte einen Entwickler, der nach vier Monaten intensiver Copilot-Nutzung Skill-Degradation an sich selbst bemerkte — vier Monate, ein Quartal, ein Performance-Review-Zyklus. Der entscheidende Unterschied zum Assembler-Argument: dieser Entwickler verlor nicht die Fähigkeit, auf einer niedrigeren Abstraktionsebene zu arbeiten. Er verlor die Fähigkeit, auf seiner eigenen Abstraktionsebene zu arbeiten.

Und das Grausamste: Die Leute, die Skills verlieren, merken nicht, dass sie Skills verlieren. Dell’Acqua et al. (Harvard/BCG, 2023) zeigen, dass KI-gestützte Consultants 25% schneller und 40% besser arbeiten — solange die Aufgabe innerhalb der KI-Fähigkeitsgrenze liegt. Außerhalb verschlechtert sich die Qualität erheblich, und die Testpersonen merkten den Unterschied nicht. Parallel dazu zeigt eine systematische Metastudie zu Automation Bias (35 Studien, 2015–2025, AI & Society), dass werkzeuggestützte Performance die Selbsteinschätzung der eigenen Kompetenz aufbläht — und zwar gerade bei den Erfahrensten (ein “Reverse Dunning-Kruger”-Effekt, publiziert 2025). Die Kombination — bessere Ergebnisse bei gleichzeitig schlechterer Kalibrierung — ist als Gesamtdynamik noch nicht längsschnittlich belegt, aber die Einzelteile sind solide. Die KI kompensiert das Defizit und verbirgt es im selben Zug.

Schleife 3: Der Review-Engpass (eure einzige Bremse)

Mehr Code-Output → mehr Review-Last → schlechtere Review-Qualität
→ mehr Bugs → weniger Vertrauen in Agents → weniger Agent-Autonomie
→ weniger Code-Output

Das ist die entgegenwirkende Schleife, die natürliche Bremse des Systems: wenn die Code-Produktion die Review-Kapazität übersteigt, sinkt die Qualität, Bugs tauchen auf, das Vertrauen erodiert, und das Team drosselt. Jedenfalls in der Theorie.

In der Praxis hat diese Schleife eine Weggabelung, und welchen Abzweig euer Team nimmt, hängt von etwas ab, das mit Technologie eigentlich nichts zu tun hat: Management-Kultur.

Pfad A (gesund): Die Review-Queue wächst. Das Team sagt: „Wir schaffen die Reviews nicht schnell genug, lasst uns die Produktion drosseln." Kurzfristig schmerzhaft, langfristig tragfähig. Macht fast niemand freiwillig.

Pfad B (pathologisch): Die Review-Queue wächst. Jemand sagt: „Approve halt einfach, die Tests sind doch grün und es ist schon 23:07." Das Review wird aufgeweicht. Kurzfristig bleibt die Velocity hoch, keine sichtbaren Probleme, alle sind happy. Langfristig habt ihr eure einzige Bremse deaktiviert, und die verstärkenden Schleifen laufen ohne Gegengewicht.

Die meisten Organisationen driften in Pfad B — nicht weil sie dumm wären, sondern weil die kurzfristigen Anreize genau dorthin zeigen und der Schaden durch geschwächtes Review mit Verzögerung kommt. Sicherheitslücken in agent-generiertem Code können monatelang unentdeckt bleiben; wenn die Konsequenzen dann eintreffen, ist die Ursache längst im Nebel der Vergangenheit.

Der Kipppunkt

Es gibt ein Verhältnis in diesem System, das mehr zählt als jede einzelne Metrik: wie viel von eurer Codebase ist Comprehension Debt, gemessen an dem, was das Team tatsächlich noch versteht? Kein formales Maß, eher ein Denkmodell — aber ein nützliches.

Comprehension Debt ist Code in eurer Codebase, den niemand im Team gut genug versteht, um ihn zu ändern, zu debuggen oder auf Korrektheit zu prüfen. Sie akkumuliert sich jedes Mal, wenn ein Agent Code produziert, der durch Review-by-Vibes durchkommt statt durch Review-by-Understanding — schleichend, geräuschlos, wie Schimmel hinter der Trockenbauwand.

Unter einem bestimmten Schwellenwert ist das beherrschbar. Das Team versteht vielleicht nicht jede Zeile, aber es kennt die Architektur, die Designentscheidungen, die Fehlermodi.

Über dem Schwellenwert fliegt ihr blind. Änderungen in einem Modul machen Dinge in einem anderen kaputt, und niemand weiß warum. Debugging wird zum Ratespiel, und der Agent wird unverzichtbar — nicht weil er gut wäre, sondern weil sonst niemand mehr durch das Chaos navigieren kann, das er selbst mitverursacht hat. Lieben wir nicht.

Der Übergang ist kein Gefälle, er ist eine Klippe. An einem Tag ist das System noch beherrschbar; am nächsten kündigt eine Senior-Entwicklerin, und ihr Anteil an der Codebase — der Teil, den nur sie verstanden hat, der Teil, bei dem es hieß „frag einfach Maria" — wird über Nacht zu Comprehension Debt. Das Szenario ist nicht empirisch belegt im strengen Sinne — aber jede:r, die oder der lange genug in der Branche war, kennt eine Variante davon. Der Bus Factor ist real, auch wenn ihn niemand misst.

Was ihr tatsächlich tun könnt

Ich werde jetzt nicht so tun, als wäre das hier ein Listicle mit fünf actionable Takeaways. Die Dynamiken sind strukturell; wer glaubt, man könnte sie mit einer Checkliste einfangen, hat das Diagramm nicht verstanden. Aber Meadows’ Forschung zu Hebelpunkten zeigt zumindest, wo im System die Interventionen am meisten bewegen — und wo man seine Energie verschwendet.

Die balancierende Schleife ist eure einzige Bremse, und sie ist die einzige, die aktiv geschützt werden muss. Review-Kapazität ist nicht „nice to have", sie ist eure Qualitätssicherung. Wenn die Review-Queue schneller wächst als die Review-Kapazität, ist das kein Review-Problem: das ist ein Qualitätsproblem. Und „die Tests sind grün" ist kein Ersatz für „ein Mensch hat das verstanden" — oder wenn es einer sein soll, dann managed wenigstens die Comprehension Debt bewusst. Welche Teile der Codebase versteht eigentlich niemand im aktuellen Team? Das ist euer tatsächliches Risikoregister, nicht das JIRA-Board. Ich habe an einem Labeling-System gearbeitet — AI:RED bis AI:WHITE — das anzeigt, wie viel menschliches Verständnis in ein Artefakt eingeflossen ist. Nicht perfekt, aber es macht das Unsichtbare sichtbar.

Das zweite, was sich lohnt: die Erwartungsspirale bewusst durchbrechen. „Wir haben mit Agents 3x ausgeliefert" heißt eben nicht „3x ist die neue Baseline." Ein Teil dieses Outputs sollte in Puffer fließen — Zeit für Verständnisaufbau, deliberate Practice, Refactoring. Das ist ein Management-Thema, kein technisches; wenn euer Management dieses Argument nicht nachvollziehen kann, zeigt ihnen das Diagramm. Dafür ist es da.

Und drittens — das Schwierigste, weil es gegen die Intuition geht: die Skills eures Teams erodieren gerade, jetzt, in diesem Moment, und ihr werdet es monatelang nicht merken. Regelmäßige Agent-freie Coding-Sessions sind keine Maschinenstürmerei, sondern kognitives Äquivalent zur Physiotherapie. Ihr hört ja auch nicht auf, ein Hilfsmittel zu benutzen, um etwas zu beweisen; ihr trainiert, damit ihr ohne es arbeiten könnt, falls es nötig wird.

Dem System sind eure Absichten egal

Ich benutze Coding-Agents jeden Tag. Ich habe diesen Post mit einem geschrieben. Ich argumentiere nicht dafür, dass ihr aufhören sollt, sie zu benutzen — der Zug ist abgefahren, und er brennt zwar ein bisschen, aber er ist trotzdem schneller als laufen. 🔥🐕☕ This is fine.

Was ich sagen will: Die Systemdynamik der Adoption ist nicht neutral. Sie hat eine Richtung, und die geht zu mehr Autonomie, weniger Verständnis und einem Team, das sich produktiv fühlt, während es schleichend die Fähigkeit verliert, die eigene Arbeit zu beurteilen. Wenn ihr nicht aktiv in die Feedbackstruktur eingreift, gewinnen die verstärkenden Schleifen. Nicht weil irgendjemand das so entschieden hätte, sondern weil verstärkende Schleifen eben genau das tun.

Donella Meadows schrieb, der effektivste Hebelpunkt in einem System sei das Paradigma — das mentale Modell, aus dem die Ziele und Regeln des Systems überhaupt erst entstehen. Und das aktuelle Paradigma hat einen Namen: Akzelerationismus. Der Vibe Shift in der Tech-Kultur — von „move fast and break things" zu „move fast and don’t even look" — manifestiert sich konkret: Andreessens Techno-Optimist Manifesto, Karpathy, der „Vibe Coding" prägt, Shopifys Lütke, der KI-Nutzung zur Voraussetzung macht, bevor man überhaupt nach Headcount fragen darf. Das ist nicht nur Diskurs; es ist das, was den Delivery-Pressure-Knoten im Diagramm antreibt: Führungskräfte lesen dieselben Narrative und handeln unabhängig voneinander danach, was koordiniertes Verhalten erzeugt, ohne dass sich jemand abgesprochen hätte. DiMaggio und Powell nannten das 1983 institutionellen Isomorphismus; 2026 läuft der Mechanismus über Twitter¹ statt über Management-Journals, aber er ist derselbe.

Das alternative Paradigma hat noch keinen eingängigen Namen, und das ist Teil des Problems. „Agents sind eine tolle kognitive Erweiterung unserer Fähigkeiten, aber nur so lange wir ihnen nicht zu viel unserer Arbeit übertragen" passt halt einfach nicht auf eine Folie. Aber es ist das Paradigma, bei dem euer Team nächstes Jahr sein eigenes System noch versteht.