Simon Willison & Mario Zechner: 'Slow the fuck down' – Warum der Agenten-Hype gefährlich ist

KI-Agenten versprechen, dass wir Code deutlich schneller schreiben können. Aber was, wenn diese Geschwindigkeit uns die Kontrolle kostet? Mario Zechner und Simon Willison warnen vor einem Muster, das in vielen Entwicklerteams gerade erst sichtbar wird: Agenten können Code schneller erzeugen, als Menschen ihn verstehen, prüfen und langfristig warten können.

Wenn Werkzeugbauer vor dem Werkzeug warnen

Mario Zechner ist kein Außenseiter. Er hat das Pi-Agent-Framework gebaut, das im OpenClaw-Umfeld für Coding-Agenten relevant ist. Wenn jemand die Mechanik KI-gestützter Entwicklung aus der Nähe kennt, dann er. Seine Diagnose ist deutlich: Viele Teams hätten Disziplin und Handlungsfähigkeit zugunsten eines Tempos aufgegeben, bei dem möglichst viel Code in möglichst kurzer Zeit entsteht.

Simon Willison greift diese Warnung auf seinem Blog auf und stimmt der Grundthese zu. Agenten lassen Entwickler so schnell arbeiten, dass Änderungen, über die man früher Tage oder Wochen nachgedacht hätte, heute in wenigen Stunden landen. Das Ergebnis nennt Willison cognitive debt: Codebasen, deren Komplexität schneller wächst als die Fähigkeit des Teams, sie klar zu durchdenken.

Die Mathematik der Agenten-Fehler

Ein Mensch ist ein natürlicher Flaschenhals. Selbst ein unerfahrener Entwickler kann nicht unbegrenzt viele Zeilen Code in kurzer Zeit produzieren. Damit ist auch begrenzt, wie viele Fehler pro Tag in eine Codebase gelangen können.

Agenten verschieben diese Grenze. Sie produzieren ununterbrochen, und ihre kleinen, harmlos wirkenden Fehler häufen sich mit einer Geschwindigkeit an, die schwer zu kontrollieren ist. Zechner beschreibt sinngemäß, dass eine orchestrierte Armee von Agenten den menschlichen Schmerzpunkt entfernt: Man merkt nicht mehr sofort, wo sich kleine Ungenauigkeiten zu einer unüberschaubaren Codebase verbinden.

Willisons Begriff cognitive debt trifft genau diesen Punkt. Es geht nicht nur um Bugs, sondern um mentale Last. Ein Team kann Features ausliefern und trotzdem den Überblick verlieren, wie das System wirklich funktioniert.

Drei gefährliche Muster im Agenten-Hype

1. Die Geschwindigkeitsfalle

Agenten eliminieren das Tippen als Engpass. Das ist verlockend, verschiebt den eigentlichen Engpass aber auf Review, Architekturdenken und Wartbarkeit. Wenn über Nacht dutzende Pull Requests entstehen, stellt sich die entscheidende Frage: Wer prüft sie, und wer versteht danach noch das Gesamtsystem?

2. Vendor-Lock-in durch Komplexität

In der Hacker-News-Diskussion wird ein beunruhigendes Szenario skizziert: Wenn eine Codebase so komplex wird, dass nur noch Agenten sie zuverlässig bearbeiten können, entsteht eine neue Form von Abhängigkeit. Dann hängt nicht nur die Produktivität am Modellanbieter, sondern auch die Fähigkeit, das eigene System weiterzuentwickeln.

Das ist keine sichere Prognose, aber ein plausibles Risiko. Wenn KI-Provider ihre Preise erhöhen oder Modellverhalten sich ändert, kann eine agentenabhängige Codebase schnell zur Kosten- und Wartungsfalle werden.

3. Verlust von implizitem Wissen

Wissen lebt nicht nur in Dokumentation, sondern auch in der Praxis. Beim Programmieren entsteht tiefes Verständnis durch Schreiben, Umbauen, Debuggen und Wiederholen. Wer nur noch Agenten schreiben lässt, verliert einen Teil dieses impliziten Wissens.

Das wird besonders gefährlich, wenn Systeme im Notfall repariert werden müssen. Wer die entscheidenden Komponenten nie selbst gebaut oder bewusst gestaltet hat, kann sie schlechter einschätzen, debuggen und stabilisieren.

Drei Gegenmaßnahmen für Teams

Scope strikt begrenzen

Agenten sollten kleine, klar abgegrenzte Aufgaben bekommen, die ein Mensch in einem Stück reviewen kann. Ein Pull Request, der Linting-Probleme behebt und gleichzeitig ein neues Feature implementiert, ist riskant. Besser sind mehrere kleine Änderungen, deren Wirkung nachvollziehbar bleibt.

Architektur und APIs bewusst selbst gestalten

Zechners Rat lässt sich auf eine einfache Regel bringen: Alles, was die Gestalt des Systems definiert, sollte nicht blind an Agenten delegiert werden. Architektur, APIs und Schlüsselkomponenten brauchen menschliche Entscheidungen. Das zwingt Teams, die grundlegenden Trade-offs selbst zu verstehen.

Code-Erzeugung an Review-Kapazität koppeln

Willison schlägt vor, das tägliche Volumen generierten Codes an die eigene Review-Kapazität zu binden. Das klingt unsexy, ist aber zentral. Nicht die Menge des erzeugten Codes ist entscheidend, sondern die Menge des verstandenen und geprüften Codes.

Die Kontrolle behalten

Die Diskussion ist keine Fundamentalkritik an KI-Agenten. Zechner und Willison nutzen solche Werkzeuge selbst. Ihre Warnung zielt auf die Balance zwischen Geschwindigkeit und Verständnis.

Agenten sind mächtige Werkzeuge, aber sie ersetzen nicht die Verantwortung für Architektur, Wartbarkeit und Betrieb. Wer jetzt Guardrails einzieht, kann von der Geschwindigkeit profitieren, ohne die eigene Codebase aus der Hand zu geben. Wer nur auf Durchsatz optimiert, riskiert eine Zukunft, in der Software zwar schneller entsteht, aber immer schwerer zu verstehen ist.