Originaltitel: Überlegungen dazu, wie man bitte mal den fuck langsamer macht
Originalautor: Mario Zechner
Übersetzung: Peggy, BlockBeats

Redaktionsnotiz: In einer Zeit, in der generative KI die Softwareentwicklung beschleunigt, kippt die Stimmung in der Branche von „staunenswerten Fähigkeiten“ hin zu „Effizienz-Angst“. Nicht schnell genug zu schreiben, nicht genug zu nutzen, nicht gründlich genug zu automatisieren – all das scheint den Druck auszulösen, ersetzt zu werden. Aber wenn Coding Agents wirklich in die Produktion gehen, treten einige realistischere Probleme zutage: Fehler werden verstärkt, die Komplexität läuft aus dem Ruder, das System wird nach und nach unverständlich, und eine Effizienzsteigerung führt nicht im gleichen Verhältnis zu einer Qualitätssteigerung.

Dieser Artikel basiert auf Praxis aus dem Alltag und nimmt diese Welle des „agentic coding“ mit einer nüchternen Reflexion auseinander. Der Autor weist darauf hin, dass Agenten nicht – wie Menschen – aus Fehlern lernen. Ohne Engpässe und Feedback-Mechanismen werden kleine Probleme schnell vergrößert; und in komplexen Codebasen verstärkt zudem die lokale Perspektive und die begrenzte Recall-Fähigkeit weiter das Durcheinander in der Systemstruktur. Das Wesen dieser Probleme liegt nicht in der Technik selbst, sondern darin, dass Menschen unter Angstdruck Beurteilung und Kontrolle zu früh abgeben.

Daher ist es statt in der Angst zu versinken, ob man „KI umfassend umarmen muss“, besser, die Beziehung zwischen Mensch und Werkzeug neu auszurichten: Agenten übernehmen lokale, kontrollierbare Aufgaben, während Systemdesign, Qualitätsprüfung und die entscheidenden Entscheidungen fest in deiner Hand bleiben. In diesem Prozess wird „langsamer werden“ paradoxerweise zu einer Fähigkeit: Es bedeutet, dass du das System weiterhin verstehst, Entscheidungen abwägen kannst und auch ein Gefühl von Kontrolle über die Arbeit behältst.

In einer Ära, in der sich Werkzeuge unaufhörlich weiterentwickeln, ist vielleicht nicht die Fähigkeit, noch schneller zu generieren, das wirklich Seltene – sondern die Fähigkeit, Komplexität einzuschätzen, und die Standfestigkeit, zwischen Effizienz und Qualität abzuwägen.

Im Folgenden der Originaltext:

Das Gesicht der Schildkröte – so sieht meine Miene aus, wenn ich mir diese Branche anschaue

Etwa vor einem Jahr tauchten die ersten Coding Agents auf, die tatsächlich in der Lage sind, dir „vom Anfang bis zum Ende ein komplettes Projekt“ zu bauen. Davor gab es schon Tools wie Aider und frühe Cursor-Varianten, aber die wirkten eher wie Assistenten – nicht wie „Agenten“. Die nächste Generation von Tools ist extrem attraktiv, und viele Menschen haben dafür auch jede Menge Freizeit aufgebracht, um all die Projekte, die sie schon immer machen wollten, aber nie Zeit dafür hatten, einmal fertigzustellen.

Ich finde, daran ist grundsätzlich nichts auszusetzen. Etwas in der Freizeit zu machen ist an sich schon ziemlich viel Spaß, und die meiste Zeit musst du dir auch nicht besonders um die Codequalität und Wartbarkeit den Kopf zerbrechen. Das bietet dir außerdem einen Weg, um ein neues Tech-Stack kennenzulernen.

Während der Weihnachtsferien haben Anthropic und OpenAI zudem noch ein paar „kostenlose Kontingente“ verteilt – wie Spielautomaten, die Leute hineinziehen. Für viele war das das erste Mal, dass man wirklich die Magie erlebt hat: „Agenten schreiben Code“. Die Zahl der Mitwirkenden ist stetig gewachsen.

Inzwischen kommen Coding Agents auch in Produktions-Codebasen an. Nach 12 Monaten beginnen wir, die Folgen dieser „Fortschritte“ zu sehen. Hier sind meine aktuellen Ansichten.

Alles ist kaputt

Auch wenn das größtenteils nur Erfahrungen und Meinungen sind: Software fühlt sich inzwischen wirklich so an, als könne sie jederzeit „zerspringen“. 98% Verfügbarkeit werden gerade von einer Ausnahme zur Normalität, selbst bei großen Diensten nicht anders. In den Benutzeroberflächen wimmelt es von den verschiedensten absurden Bugs – von der Art, die ein QA-Team normalerweise sofort finden würde.

Ich gebe zu: Diese Situation gab es zum Teil bereits vor dem Auftauchen von Agents. Aber jetzt nimmt die Geschwindigkeit der Verschlechterung offensichtlich zu.

Wir können nicht sehen, wie es innerhalb von Unternehmen wirklich aussieht, aber manchmal sickern Informationen durch – etwa bei dem Gerücht, dass „KI zu einem AWS-Ausfall geführt hat“. Amazon Web Services hat die Darstellung anschließend umgehend „korrigiert“, startete aber direkt danach intern einen 90-Tage-Umbauplan.

Auch Satya Nadella (CEO von Microsoft) betont seit Kurzem immer wieder, dass in der Firma immer mehr Code von KI geschrieben werde. Auch wenn es keinen direkten Beleg gibt, ist das Gefühl dennoch da: Die Windows-Qualität rutscht ab. Sogar in einigen Blogs, die Microsoft selbst veröffentlicht hat, scheint man das stillschweigend anzunehmen.

Unternehmen, die behaupten, „das Produkt besteht zu 100% aus von KI generiertem Code“, liefern fast immer die schlechtesten Produkte, die man sich vorstellen kann. Nicht weil es gegen jemanden geht, sondern weil das, was man dann sieht, Dinge sind wie Speicherlecks in GB-Größe, Chaos in der UI, fehlende Funktionen, häufige Crashes … Das ist keineswegs das, was sie unter „Qualitätssicherung“ verstehen, und erst recht kein positives Beispiel dafür, „dass Agenten für dich alles erledigen“.

Insgeheim hört man immer häufiger, dass sowohl große Unternehmen als auch kleine Teams sagen: Sie sind durch „Agenten schreiben Code“ in eine Sackgasse geraten. Ohne Code-Reviews Designentscheidungen an Agenten abgeben und dann noch einen Stapel Funktionen draufpacken, die niemand braucht – das Ergebnis wird zwangsläufig nicht gut sein.

Warum sollten wir Agenten nicht so verwenden?

Wir haben praktisch alle Ingenieursdisziplinen und unsere eigene Urteilsfähigkeit aufgegeben und sind stattdessen in eine „suchtartige“ Arbeitsweise gerutscht: Es gibt nur ein Ziel – in kürzester Zeit so viel Code wie möglich zu generieren. Wie die Folgen aussehen, spielt überhaupt keine Rolle.

Du baust eine Orchestrierungs-Schicht, um ein Heer aus automatisierten Agenten zu dirigieren. Du installierst Beads, aber du weißt nicht, dass es im Grunde genommen fast eine nicht deinstallierbare „Schadsoftware“ ist. Nur weil im Internet gesagt wird: „Alle machen das so“. Wenn du es nicht machst, bist du „gefroren“ („ngmi“).

Du verzehrst dich in einer endlosen „Schachtelpuppen“-Schleife.

Schau – Anthropic hat mit einer Gruppe von Agenten einen C-Compiler gebaut. Obwohl es jetzt noch Probleme gibt, wird die nächste Generation an Modellen es sicherlich reparieren können, oder?

Schau – Cursor hat mit einer großen Gruppe von Agenten einen Browser gebaut. Obwohl er im Moment im Grunde unbrauchbar ist und man ab und zu manuell eingreifen muss, wird die nächste Modellgeneration das sicherlich hinbekommen, oder?

„Verteilt“, „teile-und-herrsche“, „autonome Systeme“, „Black-Light-Fabriken“, „in sechs Monaten Softwareprobleme lösen“, „SaaS ist tot, meine Oma hat gerade mit Claw einen Shopify gebaut“ …

Diese Narrativen klingen einfach herrlich.

Natürlich kann diese Vorgehensweise für dein Side-Project gelten, das so gut wie niemand nutzt (inklusive dir selbst) – vielleicht „läuft es dann tatsächlich noch“. Vielleicht gibt es auch wirklich irgendeinen Genie-Typen, der mit dieser Methode ein nicht-miserables, wirklich von Menschen verwendetes Softwareprodukt zustande bringt. Wenn du genau diese Person bist, dann habe ich echten Respekt.

Aber zumindest in meiner Entwickler-Community habe ich noch nie echte Beispiele gesehen, bei denen diese Methode wirklich funktioniert hat. Natürlich ist es auch möglich, dass wir einfach alle zu schlecht sind.

Fehler stapeln sich durch fehlendes Lernen, fehlende Engpässe und verzögerte Explosionen

Das Problem der Agenten ist: Sie machen Fehler. Das ist an sich nicht weiter schlimm – Menschen machen auch Fehler. Vielleicht sind es nur einige Korrektheitsfehler, die leicht zu erkennen und leicht zu beheben sind; und mit noch einem Regressionstest wird es dann noch stabiler. Oder es sind Code-Smells, die ein Linter nicht erwischt: hier eine nutzlose Methode, dort ein unplausibler Typ, plus doppelter Code usw. Für sich genommen sind das alles Kleinigkeiten – Menschen machen genau solche kleinen Fehler ebenfalls.

Aber „Maschinen“ sind keine Menschen. Nachdem Menschen denselben Fehler ein paar Mal wiederholen, lernen sie normalerweise, es nicht mehr zu tun – entweder weil sie dafür angeschimpft werden, oder weil sie es im echten Lernprozess abändern.

Agenten haben diese Lernfähigkeit nicht – zumindest ist standardmäßig nicht vorgesehen, dass sie sie haben. Sie werden dieselben Fehler immer und immer wieder machen, und möglicherweise „konstruieren“ sie sogar wundervolle Kombinationen aus verschiedenen Fehlern, basierend auf den Trainingsdaten.

Du kannst natürlich versuchen, sie zu „trainieren“: In AGENTS.md Regeln schreiben, damit sie diesen Fehler nicht mehr machen; ein komplexes Speichersystem entwerfen, sodass es frühere Fehler und Best Practices abfragen kann. Das ist für bestimmte Arten von Problemen durchaus effektiv. Aber die Voraussetzung ist – du musst zuerst beobachten, dass es genau diesen Fehler macht.

Der entscheidende Unterschied ist aber noch wichtiger: Menschen haben Engpässe – Agenten nicht.

Menschen können in ein paar Stunden nicht 20.000 Zeilen Code aus dem Ärmel schütteln. Selbst wenn die Fehlerquote nicht gering ist, kann man pro Tag nur eine begrenzte Anzahl von Fehlern einführen, und die Ansammlung davon geschieht langsam. Meistens stoppen Menschen (aus einem instinktiven Unbehagen heraus) dann, wenn sich das „Schmerzpotenzial von Fehlern“ auf ein gewisses Maß aufgestaut hat. Oder Menschen werden ersetzt, und jemand anderes repariert das. Wie auch immer: Das Problem wird behandelt.

Aber wenn du eine komplette orchestrierte „Agenten-Armee“ einsetzt, gibt es keinen Engpass und auch keinen „Schmerz“. Diese ursprünglich winzigen Fehler stapeln sich mit einer unhaltbaren Geschwindigkeit. Du bist bereits aus dem Kreislauf herausgeschoben und merkst nicht einmal, dass diese scheinbar harmlosen kleinen Probleme sich zu einem riesigen Monster auswachsen. Wenn du den Schmerz dann wirklich spürst, ist es häufig schon zu spät.

Bis irgendwann der Tag kommt, an dem du eine neue Funktion hinzufügen willst – und feststellst, dass die aktuelle Systemarchitektur (im Grunde schon eine Ansammlung von Fehlern) das gar nicht mehr unterstützt. Oder Nutzer fangen an, sich wahnsinnig zu beschweren, weil beim letzten Release etwas schiefgelaufen ist, vielleicht sogar Daten verloren wurden.

Dann erkennst du: Du kannst dieser Codebasis nicht mehr vertrauen.

Noch schlimmer: Die Tausenden von Unit-Tests, Snapshot-Tests und End-to-End-Tests, die von Agenten generiert wurden, sind ebenfalls nicht mehr vertrauenswürdig. Die einzige verbleibende Methode, um festzustellen, ob „das System normal funktioniert“, ist manuelles Testen.

Glückwunsch – du hast dich (und dein Unternehmen) komplett reingefahren.

Die Verkäufer von Komplexität

Du weißt inzwischen überhaupt nicht mehr, was in deinem System vor sich geht, weil du die Kontrolle an Agenten abgegeben hast. Und Agenten verkaufen im Kern „Komplexität“. Sie haben in ihren Trainingsdaten massenhaft schlechte Architekturentscheidungen gesehen und verstärken diese Muster außerdem im Prozess des Reinforcement Learning fortlaufend. Du lässt sie das System designen – das Ergebnis liegt auf der Hand.

Am Ende erhältst du: eine ganze Reihe extrem komplexer Systeme, die aus einer holprigen Imitation verschiedener „Best Practices aus der Branche“ bestehen – und bevor das Ganze aus dem Ruder läuft, hast du es nicht eingeschränkt.

Doch das ist noch nicht alles. Deine Agenten teilen nicht miteinander ihren Ausführungsprozess, sie sehen nicht die gesamte Codebasis und sie wissen nicht, welche Entscheidungen du oder andere Agenten zuvor getroffen haben. Deshalb sind ihre Entscheidungen stets „lokal“.

Das führt direkt zu den oben genannten Problemen: viel doppelter Code, Strukturen „um der Abstraktion willen“, allerlei Inkonsistenzen. Diese Probleme stapeln sich weiter, bis am Ende ein nicht mehr rückgängig zu machendes komplexes System entsteht.

Das ist im Grunde sehr ähnlich zu dem, was menschlich geschriebene Unternehmens-Codebasen sind. Nur entsteht diese Komplexität dort normalerweise über Jahre: Der Schmerz wird auf viele Menschen verteilt, niemand erreicht die Schwelle, ab der man „wirklich reparieren muss“, und die Organisation hat insgesamt eine hohe Toleranz. So können Komplexität und Organisation gemeinsam „symbiotisch evolvieren“.

Aber mit der Kombination aus Mensch + Agent wird dieser Prozess massiv beschleunigt. Zwei Menschen plus eine ganze Menge Agenten – in ein paar Wochen erreicht man diese Komplexität.

Agentic Search hat eine sehr geringe Recall-Rate

Du setzt vielleicht darauf, dass Agenten „das Chaos aufräumen“ kann – um zu refactoren, zu optimieren und das System sauberer zu machen. Aber das Problem ist: Sie können das inzwischen nicht mehr.

Denn die Codebasis ist zu groß, die Komplexität ist zu hoch, und sie sehen stets nur lokales Material. Das liegt nicht nur daran, dass das Kontextfenster nicht groß genug ist oder dass Long-Context-Mechanismen bei Millionen Codezeilen einfach versagen. Das Problem ist noch verdeckter.

Bevor Agenten versuchen, das System zu reparieren, müssen sie zuerst alle Stellen finden, die geändert werden müssen, sowie die bereits vorhandenen Implementierungen, die man wiederverwenden kann. Diese Phase nennen wir agentic search (Agentensuche).

Wie Agenten das machen, hängt davon ab, welche Tools du ihnen gibst: Bash + ripgrep, durchsuchbare Code-Indexes, LSP-Services, Vektordatenbanken …

Aber egal, welche Tools du verwendest: Im Kern ist es immer gleich – je größer die Codebasis, desto niedriger die Recall-Rate. Und eine niedrige Recall-Rate bedeutet: Agenten können nicht alle relevanten Code-Stellen finden, und damit können sie auch keine korrekten Änderungen durchführen.

Darum tauchen auch am Anfang diese kleinen Fehler mit „Code-Smells“ auf: Weil es keine gefundene bestehende Implementierung gibt, bauen sie das Rad erneut und führen Inkonsistenzen ein. Am Ende breiten sich diese Probleme weiter aus, stapeln sich und ergeben eine extrem komplexe „miese Blütenpracht“.

Wie vermeiden wir also all das?

Wie wir mit Agenten zusammenarbeiten sollten (zumindest aktuell)

Coding Agents sind wie Sirenen: Mit einer extrem schnellen Geschwindigkeit beim Generieren von Code und dieser Art „unterbrochen, aber manchmal wirklich erstaunlich“ wirkender Intelligenz ziehen sie dich in ihren Bann. Sie können oft mit beeindruckender Geschwindigkeit und hoher Qualität einige einfache Aufgaben erledigen. Erst wenn du genau diese Idee entwickelst – „Das Ding ist zu stark. Computer, mach für mich die Arbeit!“ – beginnt es wirklich problematisch zu werden.

Einen Task an Agenten zu übergeben, an sich ist nicht unbedingt falsch. Gute Agent-Aufgaben haben normalerweise ein paar gemeinsame Eigenschaften: Der Umfang kann sich gut begrenzen lassen, sie müssen nicht das ganze System verstehen; die Aufgabe ist ein geschlossener Regelkreis, sodass Agenten das Ergebnis selbst bewerten können; die Ausgabe ist kein Critical Path – es sind nur temporäre Tools oder Software für den internen Gebrauch, die echte Nutzer oder Einnahmen nicht beeinflussen; oder du brauchst einfach einen „Gummienten“-Assistenten, um beim Denken zu helfen – im Grunde nimmst du deine Ideen, prallst sie in einer Runde mit den komprimierten Wissensbeständen des Internets und mit synthetisierten Daten zusammen.

Wenn diese Bedingungen erfüllt sind, dann sind das Aufgaben, die man Agenten anvertrauen kann – vorausgesetzt, dass du als Mensch weiterhin der letzte Qualitätskontrollierer bist.

Zum Beispiel: Mit Andrej Karpathys auto-research-Methode die App-Startzeit optimieren? Sehr gut. Aber die Voraussetzung ist: Du weißt, dass der von auto-research ausgegebene Code garantiert nicht produktionsfähig ist. auto-research funktioniert, weil du ihm eine Bewertungsfunktion gibst, mit der es um einen Kennwert (z.B. Startzeit oder Loss) optimieren kann. Aber diese Bewertungsfunktion deckt nur sehr einen schmalen Dimension ab. Agenten werden dann selbstverständlich „erklärbar“ ignorieren, was außerhalb dieser Bewertungsfunktion liegt – etwa Codequalität, Systemkomplexität, und in manchen Fällen sogar Korrektheit. Wenn deine Bewertungsfunktion selbst schon fehlerhaft ist, gilt das natürlich erst recht.

Die Kernidee ist im Grunde ganz einfach: Lass Agenten die langweiligen Aufgaben erledigen, die dich nichts Neues lernen lassen, oder die explorativen Arbeiten, für die du ursprünglich keine Zeit hattest. Und dann bewertest du das Ergebnis, wählst die wirklich sinnvollen und korrekten Teile aus, und fertigst die finale Umsetzung. Natürlich kannst du den letzten Schritt auch mit Agenten unterstützen.

Aber ich möchte vor allem betonen: Wirklich, man sollte sich dann und wann Zeit lassen.

Gib dir Zeit zum Nachdenken: Was machst du eigentlich – und warum machst du es. Gib dir auch die Möglichkeit, „Nein“ zu sagen: „Nein, das brauchen wir nicht.“ Setze Agenten eine klare Obergrenze: Wie viele Zeilen Code darf es pro Tag generieren? Diese Menge sollte zu deiner tatsächlichen Kapazität passen, die du realistisch prüfen kannst. Alle Entscheidungen, die das System als Ganzes prägen – etwa Architektur, APIs usw. – solltest du selbst schreiben. Du kannst Autocomplete verwenden, um ein bisschen „das Gefühl von handgeschriebenem Code“ zu bekommen, oder mit Agenten im Pair-Programming arbeiten – aber entscheidend ist: Du musst im Code präsent sein.

Denn ob du Code selbst schreibst oder dabei zusiehst, wie er Schritt für Schritt aufgebaut wird – dieser Prozess vermittelt per se so eine Art „Reibungsgefühl“. Genau diese Reibung macht dir klarer, was du wirklich erreichen willst, wie das System funktioniert und wie sich das „Gesamtgefühl“ anfühlt. Genau hier spielen Erfahrung und „Geschmack“ eine Rolle – und genau das kann der aktuell fortschrittlichste Modellstand nicht ersetzen. Langsam werden, ein bisschen Reibung aushalten – das ist genau der Weg, wie du lernst und wächst.

Am Ende bekommst du ein System, das weiterhin wartbar ist – zumindest wird es nicht schlimmer sein als vor dem Erscheinen von Agenten. Ja, frühere Systeme waren auch nicht perfekt. Aber deine Nutzer werden sich bedanken, weil dein Produkt „funktioniert“ – statt ein Haufen zusammengeklatschter Müll zu sein.

Du wirst weniger Features bauen, aber dafür mehr richtig. Zu lernen, „Nein“ zu sagen, ist an sich schon eine Fähigkeit. Und du kannst auch beruhigt schlafen, weil du wenigstens noch weißt, was in deinem System passiert, und du weiterhin die Kontrolle hast. Genau dieses Verständnis hilft dir dabei, das Recall-Problem von agentic search auszugleichen, sodass die Outputs von Agenten verlässlicher werden und du weniger nachbessern musst.

Wenn das System kaputtgeht, kannst du selbst eingreifen und reparieren. Wenn das Design von Anfang an nicht vernünftig ist, kannst du das Problem verstehen und in eine bessere Form refactoren. Ob es dafür überhaupt Agenten gibt, ist im Grunde nicht so wichtig.

All das braucht Disziplin. All das geht nicht ohne Menschen.

[Originallink]

Klicke, um dich über Lüdong BlockBeats über offene Stellen zu informieren

Willkommen in der offiziellen Community von Lüduong BlockBeats:

Telegram-Abonnement-Gruppe: https://t.me/theblockbeats

Telegram-Chatgruppe: https://t.me/BlockBeats_App

Twitter offizielles Konto: https://twitter.com/BlockBeatsAsia