- Mit der jüngsten Verbreitung von AI-Coding-Agenten hat sich die Entwicklungsgeschwindigkeit zwar erhöht, zugleich haben sich jedoch sinkende Softwarequalität und Instabilität verschärft
- Agenten häufen dieselben Fehler an, ohne aus Wiederholungen zu lernen, und in großen Codebasen treten sinkender Search-Recall und explodierende Komplexität auf
- Wenn man ihnen ohne menschliche Kontrolle das gesamte System überlässt, führt das zu dupliziertem Code, falschen Design-Patterns und einer nicht wartbaren Codebasis
- Derzeit sollten Agenten nur begrenzt für nicht zentrale Aufgaben oder experimentelle Bereiche eingesetzt werden, während der Mensch das letzte Quality Gate bleiben muss
- Das Tempo zu drosseln und menschliche Handlungsmacht zurückzugewinnen ist entscheidend für Lernen, Wachstum und ein nachhaltiges Software-Ökosystem
Alles ist kaputt
- Im vergangenen Jahr haben sich Coding-Agenten so weit entwickelt, dass sie reale Projekte fertigstellen können, doch als Folge tritt ein Rückgang der Softwarequalität deutlich hervor
- Selbst bei großen Services werden 98 % Uptime normal, und UI-Bugs treten häufig auf
- Erwähnt werden etwa AI-bezogene Ausfälle bei AWS oder Aussagen von Microsoft zum steigenden AI-Anteil am Code
- Einige Unternehmen behaupten, 100 % ihres Produktcodes werde von AI geschrieben, doch die Ergebnisse sind qualitativ schwach, mit Memory Leaks, UI-Fehlern und instabilen Funktionen
- Mehrere Entwickler berichten, dass sie durch agentenzentrierte Entwicklung wegen fehlender Code-Reviews, mangelndem Design und unnötiger Feature-Überladung in nicht wartbare Codebasen geraten sind
So sollte man nicht mit Agenten arbeiten
- Entwickler sind von Geschwindigkeit und Code-Menge abhängig geworden und haben dafür Qualität und Kontrolle aufgegeben
- Unter Schlagworten wie „verteilt, autonom, automatisiert“ wird Orchestrierung großer Agenten-Schwärme versucht, tatsächlich werden aber instabile Ergebnisse massenhaft produziert
- Manche Projekte lassen sich kaum überhaupt ausführen und sind ohne menschliche Eingriffe nicht wartbar
- Auf dem Niveau persönlicher Projekte mag das funktionieren, bei Produkten mit echter Nutzerbasis sind die meisten Beispiele jedoch gescheitert
-
Fehlerakkumulation und fehlendes Lernen, keine Engpässe, verzögerter Schmerz
- Agenten besitzen keine Fähigkeit zum iterativen Lernen und produzieren daher immer wieder dieselben Fehler
- Menschen lernen aus Fehlern, Agenten dagegen wiederholen denselben Fehltritt endlos
- Beim Menschen begrenzt die Schreibgeschwindigkeit die Fehlerakkumulation, doch Agenten-Armeen haben keinen Flaschenhals, sodass sich Fehler explosionsartig anhäufen
- Dadurch wird die Codebasis unzuverlässig, und selbst automatisierten Tests kann man nicht mehr trauen
- Am Ende bleibt manuelles Testen als einziges Verifikationsmittel, womit sich das Entwicklungsteam selbst in die Falle manövriert
-
Händler, die Komplexität gelernt haben
- Agenten treffen nur lokale Entscheidungen, ohne den Gesamtkontext des Systems zu sehen
- Dadurch häufen sich duplizierter Code, unnötige Abstraktionen und strukturelles Chaos mit hoher Geschwindigkeit an
- In menschlichen Organisationen wächst solche Komplexität über Jahre langsam, agentenbasierte Teams erreichen dasselbe Maß an Verwirrung in wenigen Wochen
- Agenten reproduzieren falsche Design-Patterns, die sie aus Trainingsdaten gelernt haben, und erzeugen ohne menschliche Kontrolle irreversible Komplexität
-
Niedriger Recall bei der Agenten-Suche
- Wenn Agenten Code-Änderungen oder Refactorings versuchen, finden sie nicht den gesamten benötigten Code
- Je größer die Codebasis wird, desto stärker sinkt der Search-Recall, wodurch Duplikate und Inkonsistenzen entstehen
- Selbst mit verschiedenen Tools wie Bash, LSP oder Vector-DBs gibt es Grenzen in großen Codebasen
- Dadurch verschärfen sich Code Smells und unnötige Komplexität weiter
So sollte man mit Agenten arbeiten (vorerst)
- Agenten sind durch schnelle Code-Generierung und hohe anfängliche Qualität attraktiv, doch wenn man ihnen das ganze System überlässt, bricht es zusammen
- Geeignete Einsatzfälle sind klein abgegrenzte, nicht zentrale Aufgaben, Aufgaben mit eigener Evaluationsschleife und Aufgaben, bei denen Scheitern nicht kritisch ist
- Beispiele sind interne Tools, Ideenexperimente oder automatisierte Research-Arbeiten auf Basis von Performance-Messungen (auto-research)
- Der Mensch muss unbedingt das letzte Quality Gate bleiben und die Ergebnisse der Agenten prüfen, korrigieren und integrieren
- Wenn die Bewertungsfunktion nur enge Metriken abbildet, können Agenten Codequalität, Komplexität und Korrektheit ignorieren
- Das Tempo zu drosseln ist der Kern
- Man muss sich Zeit nehmen, darüber nachzudenken, was man baut und warum, und unnötige Features konsequent ablehnen
- Die tägliche von Agenten erzeugte Code-Menge sollte auf ein reviewbares Maß begrenzt werden
- Architektur, APIs und andere wesentliche Systemformen müssen unbedingt direkt von Menschen geschrieben werden
- Man sollte mit Agenten Pair Programming betreiben, um beim Schreiben des Codes Reibung und Gelegenheiten zum Verstehen zu sichern
- Dieser Ansatz schafft wartbare Codebasen, erhöht die Nutzerzufriedenheit und hilft, sich auf Kernfunktionen statt auf unnötige Features zu konzentrieren
- Wenn menschliches Verständnis erhalten bleibt, wird auch das Recall-Problem bei der Agenten-Suche gemildert, und auftretende Probleme lassen sich direkt beheben
- Selbst wenn das anfängliche Design falsch war, bleibt die Fähigkeit erhalten, die Gründe zu verstehen und Verbesserungen vorzunehmen
- Letztlich braucht es Disziplin und menschliche Handlungsmacht
- Qualität und Nachhaltigkeit eines Systems hängen von menschlichem Eingreifen und Urteilsvermögen ab
- Langsamer zu werden ist der einzige Weg, Lernen und Wachstum sowie ein gesundes Software-Ökosystem zu bewahren
2 Kommentare
Pi – ein schlankes Terminal-Coding-Harness
Das ist also die Person, die das gemacht hat.
Hacker-News-Kommentare
Jedes Mal, wenn ich in letzter Zeit solche nachdenklichen Texte lese, habe ich das Gefühl, selbst irgendwann erschöpft zu sein.
Am Ende ist entscheidend: „Was bauen wir eigentlich?“ und „Hilft dieses Werkzeug tatsächlich?“
Dieselben Fehler haben wir schon in der Ära von Ruby, PHP, Lotus Notes und Visual BASIC wiederholt.
Man muss Werkzeuge klug einsetzen und in einem Tempo arbeiten, das es dem Team erlaubt, die komplexe Realität dessen zu verstehen, was es tatsächlich baut.
Ob Agile oder Waterfall, Docker oder Podman – das ist nicht das Wesentliche.
Heute leben wir in einer Zeit, in der LLMs Produktionsdatenbanken löschen und dazu sogar noch Illustrationen für den Postmortem-Blog zeichnen – aber ich weiß nicht, ob das wirklich Engineering ist.
Vielleicht war Softwareentwicklung von Anfang an gar keine ingenieurwissenschaftliche Disziplin.
Die Softwarebranche der letzten zehn Jahre war voller Meta-Arbeit – neue Frameworks, Tools, Virtualisierungsschichten, Organisationsstrukturen und so weiter.
Aber wofür wir das eigentlich bauen, bleibt oft unklar.
Es fühlt sich fast wie eine Pyramidenstruktur an, als würden neue Jobs geschaffen, nur um die Branche am Laufen zu halten.
Trotzdem gibt es echtes Engineering – nämlich dann, wenn man Fragen wissenschaftlich formuliert und Entscheidungen auf Basis der Antworten trifft.
Wer stattdessen nach Bauchgefühl arbeitet und nur dem CEO folgt, betreibt kein Engineering.
Früher gab es viele Teams ganz ohne Versionsverwaltung, und selbst wenn es sie gab, war sie oft miserabel.
Wenn man sich den Joel Test von Joel Spolsky anschaut, wäre die Antwort bei den meisten Firmen damals „Nein“ gewesen.
Bei Brücken lassen sich Last, Material und Lebensdauer präzise berechnen, aber bei Websites ist oft schon der Traffic schwer vorherzusagen.
Es gibt keine Standards, um die Grenzwerte von Servern oder Frameworks quantitativ zu behandeln.
Vielleicht kann Software eines Tages echtes Engineering werden, aber bis dahin ist es noch ein weiter Weg.
Das Wort „Engineer“ wurde vermutlich nur angehängt, damit man mehr Geld verdienen kann.
Echte Ingenieure legen Wert auf Beweis und Verifikation, wir dagegen mögen neue Muster und Experimente.
Deshalb fühlt sich das Wort „Engineer“ für mich eher unpassend an.
Er kritisierte es als „Methodologie, mit der Menschen programmieren wollen, die nichts vom Programmieren verstehen“, und das scheint bis heute zuzutreffen.
Der heutige AI-basierte Entwicklungsprozess verfestigt sich vor allem in Großunternehmen und verstärkt die Vendor-Lock-in-Problematik.
Wenn eine Codebase agentenzentriert wird, versteht am Ende nur noch dieser Agent den Code.
Dann werden die Preise steigen, und es könnte zu einer Einbahnstraßen-Transformation werden, aus der menschliche Entwickler kaum noch zurückfinden.
Optimisten sagen zwar: „Technologie wird immer billiger und besser“, aber es könnte auch wie auf dem Ölmarkt laufen.
So wie damals beim Übergang von DVDs zu Streaming kaufen wir im Grunde denselben Film zweimal.
Modelle wie Claude Opus 4.6 kosten inzwischen 1 Dollar pro Minute, und mit Prompt Engineering lässt sich das nicht mehr wirklich ausgleichen.
Am Ende entwickeln sich auch AI-Services zu einer Low-End–Midrange–Premium-Hierarchie.
Prompt Engineering wird inzwischen fast wie eine Art raffiniertes Jailbreaking behandelt.
Es ist riskant, die eigene Wissensarbeit an AI-Unternehmen zu „vermieten“.
Wenn jemand sagt: „Die Kosten werden schon nicht weiter steigen“, ist die Diskussion eigentlich beendet – die Würfel sind bereits gefallen.
Die großen AI-Unternehmen werden denselben Weg gehen.
Am Ende landen wir womöglich in einem Markt für Token-Abhängige.
Die unsichtbare Hand von Open Source wird am Ende alles kostenlos machen.
Mit Fortschritten bei Hard- und Software fallen die Rechenkosten pro Einheit kontinuierlich.
Technologien ohne echte Nutzung verschwinden wie beim Blockchain-Boom, aber AI hat reale Nutzer.
Auch Dienste wie Uber wurden anfangs kritisiert und haben sich am Ende doch als nachhaltiges Geschäftsmodell etabliert.
Anders als Öl wird Computing jedes Jahr billiger und schneller.
Der Autor dieses Textes ist der Entwickler des Open-Source-Coding-Agent-Frameworks Pi.
Es wird auch bei OpenClaw verwendet.
Auch sein Blogbeitrag zu Pi ist lesenswert.
Er ist jemand, der sich mit LLMs und Agenten tiefer beschäftigt hat als fast jeder andere.
Gerade Unternehmen, die behaupten, „AI schreibt 100 % des Codes“, bringen oft chaotische Produkte heraus.
In der DOS- oder MacOS-Ära war Qualität wichtiger, weil solcher Code das ganze System zum Absturz bringen konnte.
Heute sind Betriebssysteme toleranter geworden, deshalb überlebt auch schlampiger Code.
Dank OTA-Updates lassen sich unfertige Produkte leicht ausliefern, nur um schneller als die Konkurrenz auf den Markt zu kommen.
Wir erinnern uns nur an die wenigen Produkte, die gut gemacht waren.
Heute reicht eine Netzwerkverbindung, und sogar ein OS lässt sich fast so einfach aktualisieren wie ein Spiel.
Coding-Agenten sind wie „verführerische Sirenen“.
Anfangs wirken sie schnell und klug, aber in dem Moment, in dem man denkt: „Computer, erledige meine Arbeit für mich“, bricht alles zusammen.
Das ist allerdings nur vorübergehend – AI übertrifft den Menschen bereits in messbaren Bereichen.
Das eigentliche Problem ist HCI (Human-Computer Interaction).
Interfaces zu entwerfen, die mit menschlichen Werten übereinstimmen, wird die zentrale Aufgabe der Zukunft sein.
Wir befinden uns gerade auf dem Höhepunkt des AI-Hype-Zyklus.
So wie damals bei MongoDB oder NoSQL, als man rief „SQL ist tot“, werden die Leute am Ende wieder zu einem realistischen Gleichgewichtspunkt zurückkehren.
NoSQL ist nicht verschwunden, wird heute aber nur noch dort eingesetzt, wo es wirklich gebraucht wird.
Ich stimme der Aussage zu, dass „moderne Software zerbrechlicher Murks“ ist, aber eigentlich hat sich Software selbst nicht verändert.
Früher fehlte das Vertrauen, daher haben Menschen alles selbst geprüft – und gerade dieses langsame Tempo hat Probleme reduziert.
Der Kern von DevOps ist, auf Basis von Vertrauen schnell zu arbeiten und trotzdem Qualität zu halten.
Wie beim Andon-Cord von Toyota sollte man, sobald ein Problem entdeckt wird, sofort anhalten und die Grundursache beheben.
Das ist kein technisches, sondern ein kulturelles und prozessuales Problem.
Falsche Interfaces oder fehlende Passung zum Geschäftskontext müssen früh erkannt werden.
Wenn alle GitHub, AWS und Cloudflare nutzen, steht beim Ausfall einer Stelle gleich die ganze Welt still.
Wenn kurz vor dem Tape-out ein Bug entdeckt wird, erschießt man nicht den Boten, sondern entscheidet mit Bedacht.
Das Ergebnis des Programmierens ist nicht nur Code, sondern auch der Programmierer selbst.
Die beim Schreiben von Code entstehenden mentalen Modelle und das Muskelgedächtnis sind der eigentliche Vermögenswert.
Wenn AI diesen Prozess ersetzt, verschwindet am Ende auch das Wachstum des Programmierers.
Jonathan Blow behandelt dasselbe Problem in „Preventing the Collapse of Civilization”.
Siehe „Programming as Theory Building”.
Ich hatte gestern ein ähnliches Gespräch mit einem Kollegen.
Wir haben eine Demo gesehen, in der AI Logs liest, Bugs behebt und sogar das Postmortem schreibt,
aber das Problem ist, dass Menschen keine Zeit mehr haben, diesen Prozess zu verinnerlichen.
Wie bei dem Spruch „Ein Auto kann nur schnell fahren, wenn es Bremsen hat“
muss man die Reibung des Lernens in einem Tempo erhalten, das Menschen noch verstehen können.
Wenn ein Agent das selbst erkennt und sich selbst wiederherstellt, müssen Menschen dann überhaupt noch etwas lernen?
Natürlich kann die Grundursache übersehen werden, aber wenn ein autonomes Self-Healing-System robust genug ist, wäre das dann wirklich ein Problem?
Auch aus Sicht des Produktdesigns spürt man ein ähnliches Problem.
Die Entwicklung ist so schnell geworden, dass keine Zeit bleibt, Dinge selbst zu benutzen und zu validieren.
Wenn man auf ein falsches Design immer mehr Funktionen stapelt, wird es später schwer, das wieder zurückzudrehen.
Entscheidend ist am Ende nicht Geschwindigkeit, sondern das Gleichgewicht zwischen Qualität und Lernen.
Für so einen Prozess braucht man zwangsläufig Zeit.