LLM-Codegenerierung kann zu geringerem Vertrauen führen
(jaysthoughts.com)- In letzter Zeit werden LLM-basierte Codegenerierung und entsprechende Werkzeuge unter Entwicklern zunehmend häufiger genutzt
- Durch automatisch erzeugten Code wachsen die Bedenken hinsichtlich Codequalität und Zuverlässigkeit
- Entwickler erleben aufgrund mangelnden Codeverständnisses und unzureichender Validierung eine steigende Schwierigkeit bei der Projektwartung
- Die zunehmende Nutzung nicht vertrauenswürdigen Codes wirkt sich auf das gesamte Software-Ökosystem aus
- Mit dem technischen Fortschritt wird die Notwendigkeit betont, Maßnahmen zur Sicherung der Zuverlässigkeit zu schaffen
Überblick
Jay behandelt in seinem Blog die Auswirkungen der jüngst aufgekommenen LLM-(Large Language Model)-basierten Codegenerierungstechnologie auf die Softwareentwicklung in der Praxis. Zwar steigern die Fortschritte dieser Werkzeuge die Entwicklungseffizienz, zugleich rücken jedoch Fragen der Zuverlässigkeit und Qualität des Codes in den Vordergrund.
Der Aufstieg der LLM-Codegenerierungstechnologie
- In der Entwicklungspraxis verbreiten sich Werkzeuge zur automatischen Codegenerierung mit LLMs rasant
- Bei der Umsetzung komplexer Funktionen oder repetitiver Codieraufgaben bieten sie hohe Produktivität
- Sie ermöglichen schnelle Prototypenerstellung und verringern die Hürde beim Erlernen neuer Sprachen
Zuverlässigkeitsprobleme
- Von LLMs erzeugter Code funktioniert nicht immer wie beabsichtigt
- Da Absicht und Entwurfslogik innerhalb des Codes unklar sein können, werden Verständnis und Validierung erschwert
- Wenn Review- und Testprozesse unzureichend sind, können unerwartete Bugs oder Schwachstellen entstehen
Projektwartung und Auswirkungen auf das Ökosystem
- Bei automatisch erzeugtem Code treten Probleme wie mangelnde Dokumentation und unzureichende Erklärungen auf
- Entwickler haben Schwierigkeiten, die Funktionsweise des Codes nachzuvollziehen, wodurch die Wartungskomplexität zunimmt
- Es besteht das Risiko, dass eine Kultur der Entwicklung zuverlässiger Software beschädigt wird
Fazit und Empfehlungen
- LLM-basierte Codegenerierung ist innovativ, doch die Sicherung der Zuverlässigkeit ist eine zentrale Aufgabe
- Bei der Einführung automatisch erzeugten Codes werden stärkere Validierung und systematische Code-Reviews besonders wichtig
- Langfristig ist es entscheidend, Standards zum Schutz des Vertrauens im Computing-Ökosystem zu schaffen
1 Kommentare
Kommentare auf Hacker News
https://archive.is/5I9sB
Funktioniert auch in alten Browsern und braucht kein JavaScript, außer wenn man durch CloudSnare muss.
Ein Freund sagt immer: „Innovation geschieht mit der Geschwindigkeit des Vertrauens“, und seit GPT-3 muss ich ständig daran denken.
Verifikation ist teuer, und Vertrauen ist das zentrale Mittel, um diese Kosten zu senken. Ich weiß nicht, wie man LLMs vertrauenswürdig machen kann. Sie sind sowohl bei Code als auch bei natürlicher Sprache sehr eloquent, gehen aber zugleich bereitwillig in Kaninchenbaue, die sich fraktal immer weiter verzweigen, und zeigen auch Verhalten, das man bei Menschen als böswillig ansehen würde.
Diese neue Welt, in der man immer alles verifizieren muss, ist ziemlich ermüdend und ehrlich gesagt sehr langsam.
Es ist zu nützlich, um es zu ignorieren, und Vertrauen entsteht immer Stein für Stein. Man darf auch nicht vergessen, dass Menschen von Anfang an nicht besonders vertrauenswürdig sind. Wie beim Autofahren dürfte die Fähigkeit, auf vorab definierten Straßen Code mit weniger Bugs zu produzieren, den Menschen bald übertreffen; danach ist es nur noch ein Kampf um die Grundlagen zur Verbesserung der Komplexität.
In der Wissenschaft baut man Vertrauen auf, während man voranschreitet.
Bei der Arbeit habe ich so etwas auf eine andere Weise erlebt, als ich erwartet hätte. Ein Kollege und ich standen unter Druck, Fortschritt zu zeigen, und ich beschloss, ein ziemlich großes Refactoring, an dem ich arbeitete, schnell zu mergen. Es war ein Draft-PR, aber der Dynamik wegen habe ich ihn gemergt, und in der folgenden Woche tauchten ein paar Bugs in nicht getesteten Codebereichen auf.
Beim Debuggen ließ mein Kollege erkennen, dass er angenommen hatte, ich hätte den Code mit KI geschrieben, und sagte, es sei frustrierend, im Nachhinein KI-Generiertes verstehen zu müssen. Dieser Code war jedoch ohne KI entstanden. Natürlich nutze ich KI beim Programmieren, aber diesen Code hatte ich von Hand geschrieben und dabei das Gesamtdesign sorgfältig durchdacht. Die Bugs waren keine grundlegenden Mängel des Refactorings, sondern kleine Versäumnisse, die beim Anpassen bestehenden Codes an die geänderte API entstanden waren.
Am Ende wurde es zu einer vertrauensbildenden Erfahrung, weil ich die Spannungen mit meinem Kollegen explizit ansprechen konnte. Wir sind der Kraft dessen, was gerade passiert, ziemlich behutsam begegnet. Rückblickend bin ich froh, dass es sich so aufgelöst hat, und ich kann mir vorstellen, dass es in einem anderen Arbeitsumfeld deutlich schmutziger hätte werden können. Man muss vorsichtig sein.
Vor etwa vier Jahren habe ich mich selbst ziemlich blamiert. Eine Lokalzeitung veröffentlichte einen Artikel mit einer abwegigen Behauptung über eine Person und stützte sich dabei hauptsächlich auf ein Foto als Beleg. Ich schrieb dem Redakteur direkt eine E-Mail und erklärte, warum ich überzeugt war, dass das Bild manipuliert sei. Meine Argumentation beruhte auf einem Missverständnis: Ich hatte falsch interpretiert, dass die betreffende Person bei einem Meet-and-Greet mit mehreren Leuten posierte und dabei Position und Haltung fast unverändert blieben. Der Redakteur war gekränkt und antwortete spöttisch; als ich nicht nachgab, erkannte er, dass ich kein Hetzer war, sondern einfach nur dumm, und teilte mit mir das unveröffentlichte vollständige Video, aus dem das Foto stammte. Ich entschuldigte mich damals ausführlich und spendete auch, und im Jahr danach war mein Ego angemessen klein.
Schon bevor ich die E-Mail schickte, wollte ich keine falsche Anschuldigung erheben, also teilte ich das Foto mit besonnenen Freunden und fragte nach ihrer Meinung. Da auch sie zu dem Schluss kamen, dass das Bild sehr wahrscheinlich manipuliert war, war ich ziemlich selbstsicher. Heute vertraue ich dieser Zeitung und den Beteiligten implizit, aber schon eine einzige Person zu überzeugen, war wirklich viel Arbeit.
Die Prämisse ist schwer nachzuvollziehen. Wenn man jemandem zutraut, guten Code zu schreiben, dann hat man dieses Vertrauen gelernt, weil der Code dieser Person gut funktioniert hat – nicht, weil es im Kopf dieser Person irgendein apriorisches mentales Modell gibt, das „guten Code produziert“.
Wenn jemand mit einem LLM fehlerfreien Code erstellt, werde ich ihm vertrauen. Wenn jemand mit einem LLM fehlerhaften Code erstellt, werde ich ihm nicht vertrauen. Was ist daran anders als zu der Zeit, als diese Person Code ausschließlich mit dem eigenen Kopf geschrieben hat?
Durch LLMs wird es sehr schwer, allein anhand des eingereichten Codes sofort die Qualität des Entwicklers einzuschätzen, der den Patch erstellt hat. Wenn man nicht einschätzen kann, was für ein Typ Mensch das Gegenüber ist, fällt man auf „kein Vertrauen“ zurück und muss alles äußerst engmaschig prüfen. Es gibt also keine sicheren „Review-Abkürzungen“ mehr, und dort, wo man sich bislang auf solche Signale verlassen hat, um Arbeit voranzubringen, kann das schmerzhaft sein. In einem bereits kompetenten Team mit hohem Vertrauen gilt dieses Problem nicht, und das Konzept selbst dürfte sich dort wahrscheinlich fremd anfühlen.
Wenn ein Beitragender Änderungen gut erklärt, vertraut man ihm eher. Wenn er in der Vergangenheit hervorragende Arbeit geleistet hat, vertraut man ihm eher. Wenn er Änderungseinheiten gut handhabt, etwa in sinnvollen Commits, vertraut man ihm eher. Wenn er die richtigen Probleme auswählt, zum Beispiel erst Bugs behebt, bevor er neue Features hinzufügt, vertraut man ihm eher. Wenn er zeigt, dass er bestehenden Code warten kann, statt einfach nur oben etwas draufzusetzen, vertraut man ihm eher. Wenn er regelmäßig beiträgt, vertraut man ihm eher.
Das Problem ist häufig ein Kommunikationsfehler. Für den Bearbeiter kann die Aufgabe klar sein, aber wegen häufiger Kontext-Resets ist schwer sicherzustellen, dass auch das LLM das Gesamtbild kennt; bei Mehrdeutigkeiten trifft es leicht dumme Annahmen. Die Art, wie 4os Deep Research zusätzliche Informationen erfragt, bevor es etwas tut, sollte meiner Meinung nach auch bei der Codegenerierung zum Standard werden. Das könnte einen ganzen Berg von Problemen verhindern.
Manche Fälle sind einfach: Es geht darum, ob diese Routine den gewünschten Wert zurückgibt oder nicht. Andere Situationen sind aber viel komplexer, weil man vorhersehen muss, wie der Code mit anderen Teilen des Systems interagiert und welche weniger offensichtlichen Grenzfälle es gibt. Um in solchen Situationen „fehlerfreien“ Code zu schreiben, muss der Autor die Implikationen des Codes verstehen; wenn ein Entwickler nicht versteht, was der vom LLM geschriebene Code genau tut, kann er auch diese Implikationen nicht verstehen. Dann wandert diese Last zum Reviewer, und dessen Arbeitsaufwand steigt. Das war die Prämisse.
Eine gute Faustregel ist, Arbeiten, an denen ein LLM beteiligt war, einfach abzulehnen und auch von einem LLM verfasste Kommunikation zu ignorieren. Selbst bei Menschen, die Englisch als Fremdsprache verwenden, finde ich ihr „holpriges“ Englisch deutlich besser als das, was ChatGPT an ihrer Stelle sagt. Je deutlicher die gravierenden Probleme von LLMs werden, desto eher wird eine solche Policy meiner Meinung nach allgemein zum Standard werden – und ich hoffe, dass es so kommt.
LLMs lassen jede Art von schlechter Arbeit wie plausibel gute Arbeit aussehen. Deshalb ist es vernünftig, die Ergebnisse von Personen, die KI eingesetzt haben, automatisch mit einem Abschlag zu betrachten.
Vor einiger Zeit stellte sich ein Verwandter von mir als Betrüger heraus. Nachdem er aufgeflogen war, brach ich den Kontakt ab und sagte, ich kenne ihn nicht; er sagte: „Ich bin derselbe Mensch, den du seit zehn Jahren kennst.“ Ich antwortete: „Mag sein. Aber mir ist jetzt erst klar geworden, dass ich überhaupt nicht wusste, wer dieser Mensch ist, und es auch künftig nicht wissen kann.“
Wir alle gehen davon aus, dass die Menschen in unserem Leben nicht aktiv versuchen, uns zu schaden. Wenn dieses Vertrauen bricht, bricht es sehr heftig. Niemand, der KI benutzt, kann behaupten: „Das ist meine Arbeit.“ Denn man kann nicht wissen, ob es die eigene Arbeit ist. Wer KI benutzt, kann auch nicht behaupten, es sei gute Arbeit, sofern er sie nicht gründlich versteht – und vermutlich tut er das nicht. Viele meiner Studierenden behaupteten, sie hätten meine Texte gelesen und verstanden, aber ich stellte fest, dass das tatsächlich nicht der Fall war. Was wäre, wenn ich eine KI wäre und sie meine Arbeit nähmen und ihren Namen als Autor daruntersetzten? Sie könnten nichts erklären, verteidigen oder darauf aufbauen. Dieses Problem gab es schon vor KI, aber jetzt ist es zehnmal schlimmer.
Ich habe mehr als „10.000 Stunden“ in die Programmierung komplexer Anwendungen investiert, bevor nützliche LLMs aufkamen. Jahrelang habe ich mich jede Nacht durch Dokumentation und den Source Code anderer Leute gegraben und mich vollständig in Full-Stack-Kompetenz vertieft. Am Ende führte diese Versenkung zu einem schweren Burnout; meine Gesundheit litt, und meine Ehe geriet ins Wanken. Kurz nachdem ich eine Anwendung veröffentlicht hatte, musste ich drei Jahre lang komplett loslassen, um mich zu erholen, und ich war überzeugt, dass ich es nie wieder aufnehmen könnte.
Nachdem ich viele Berichte gehört hatte, dass LLMs beim Code ziemlich gut geworden seien, kehrte ich vorsichtig an den Computer zurück – und ab diesem Punkt weicht meine Erfahrung deutlich von den Bedenken ab. Der Aussage „Wer KI benutzt, kann nicht behaupten: ‚Das ist meine Arbeit‘“ kann ich nicht zustimmen. Wenn ich ein LLM verwende, bin ich Architekt und Endabnehmer. Ich gebe die Vision vor, entwerfe das System und prüfe jede vom LLM erzeugte Zeile mit Diff-Tools. Kürzlich habe ich zusammen mit einem LLM ein komplexes Optimierungsmodell für die Kalkulations-Engine meines Unternehmens gebaut. Ein echtes Optimierungsmodell zu verwenden war immer der „richtige“ Weg, aber früher hätte das Monate mühsamer Arbeit bedeutet, alle Details der Library zu lernen und fremden Code zu lesen. Diesmal war es in einer Woche erledigt. Fühlt sich das wie meine Arbeit an? Absolut. Ich hatte nur einen unermüdlichen, hervorragenden, aber gelegentlich fehlerhaften Assistenten.
Auch der Aussage, Nutzer würden es „nicht gründlich verstehen“, widerspricht meine Erfahrung. Um ein LLM für nichttriviale Aufgaben effektiv einzusetzen, braucht man ein tieferes Verständnis der Grundlagen, um das LLM zu führen und die häufigen subtilen Fehler zu erkennen. Ohne meine jahrelange Erfahrung hätte ich keine komplexe Multi-Modul-Entwicklung steuern, die Ausgaben debuggen oder erkennen können, dass Arbeit, die plausibel gut aussieht, tatsächlich auf Arten wie einem N+1-Problem falsch ist.
Mit der Erfahrung als Lehrkraft kann ich mitfühlen. Dass Studierende mit solchen Tools Verständnis vortäuschen, ist ein reales und schwieriges Problem. In der Wissenschaft ist der Lernprozess das Ziel – also irgendeinen substanziellen Teil der 10.000 Stunden zu bekommen. In der professionellen Welt ist jedoch das Ergebnis das Ziel, und dies ist ein neues, mächtiges Tool, um bessere Ergebnisse zu erzielen. Ich weiß nicht, wie Lehrkräfte Studierende in dieser neuen Realität unterrichten sollten, aber LLM-Nutzung zu verteufeln ist vermutlich nicht der beste Weg.
Für mich hat es schlechte Arbeit nicht gut aussehen lassen. Es hat hervorragende Arbeit wieder möglich gemacht und mir zugleich mein Leben zurückgegeben. Es hat mir die Freude am Craft der Softwareentwicklung zurückgegeben, ohne mich und meine Familie kaputtzumachen, und mein Leben ist jetzt viel ausgewogener; dafür bin ich dankbar.
Für mich ist das bereits der Zustand. Ich habe „Entschuldigung, das habe ich übersehen, Sie haben vollkommen recht“ schon unglaublich oft gelesen. Ungefähr 8–9 von 10 Mal.
Gleichzeitig sehe ich immer wieder, wie Leute bezahlten, von LLMs generierten Code gedankenlos kopieren und dann wütend werden, wenn er nicht wie erwartet funktioniert. Nebenbei: Das ist noch die bessere Option. Denn offensichtlich kaputt ist besser, als wenn es oberflächlich so aussieht, als würde es funktionieren.
Trotzdem können Prediction Engines noch kein echtes Engineering leisten. Wenn man nicht konkret anweist, so etwas wie einen Python-Generator zu verwenden, kommt mit hoher Wahrscheinlichkeit Code heraus, der enorm viel Speicher frisst. Leider unterscheidet sich das nicht stark von vielen Python-Programmierern, die ich kenne, aber es ist auch ein Beispiel dafür, dass LLMs genau so schlecht sind, wie gesagt wurde. Positiv ist, dass sie Leute dazu bringen, tatsächlich detailliertere Spezifikationen zu schreiben als nur eine Zeile „Feature hinzufügen“.
Wo AI Agents für uns am nützlichsten sind, ist Legacy-Code, den niemand priorisiert. Wir haben einen Datenextraktor aus dem vorigen Jahrtausend, der etwa 200 hartcodierte Koordinaten verwendet, um Daten aus einer bestimmten Art von per Fax eingehenden Dokumenten zu extrahieren. Die Dokumente hatten sich etwa 30 Jahre lang nicht geändert, daher funktionierte das gut, aber kürzlich änderten sie sich, und Copilot brauchte ungefähr 30 Sekunden, um die Koordinaten zu korrigieren. Für einen Menschen wäre das vermutlich ein extrem langweiliger ganzer Arbeitstag gewesen. Allerdings habe ich überhaupt keine Ahnung, wie unsere Branche im Zeitalter des Vibe Coding Experten ausbilden will.
Gegen LLMs anzukämpfen ist, als würde man gegen den Wind pinkeln
LLMs in ihrer heutigen Form scheinen Entwickler produktiver zu machen. Für weniger erfahrene Entwickler könnten sie sogar größere Vorteile bringen als für erfahrene. Produktivitätssteigerungen – vielleicht sogar um ein Vielfaches – werden nicht wegen Hürden aufgegeben werden, die Leute errichten, die aus irgendwelchen Gründen gegen die Technologie sind.
Selbst wenn es Beispiele dafür gibt, dass ein neues Produktivitätstool enormen Schaden anrichtet, etwa einen Bug, der einen großen Dienst für längere Zeit lahmlegt: Wenn die Technologie erhebliche Produktivität liefert, wird sie nicht gestoppt werden. Der einzig vernünftige Weg ist, mit der Technologie zu arbeiten und ihre Schwächen abzumildern. Und diese Abmilderungen dürfen kein Regelwerk sein, das die Produktivitätsgewinne der neuen Technologie vollständig beseitigt. Sie müssen zusammen mit der Technologie funktionieren und ihre Einführung eher ausweiten; andernfalls werden sie umgangen.
Meiner Erfahrung nach sind die Leute, die sehr nachdrücklich sagen, dass LLMs sie 10-mal produktiver gemacht hätten, meist relativ juniorige Frontend-Entwickler oder Serien-Startup-Entwickler, die ständig neue Apps von Grund auf bauen. Das sind natürlich völlig legitime Use Cases, aber deshalb reden ein Junior-Frontend-Entwickler und ein Senior-Embedded-C-Entwickler leicht aneinander vorbei, wenn es um Produktivitätsgewinne durch AI geht.
Statt zu sagen, dass es nur vernünftig sei, mit der Technologie zu arbeiten und ihre Schwächen abzumildern, sollte man sie einfach mit mehr Augenmaß einsetzen. Ist zum Beispiel schon die Idee eines AI-„Agenten“ an sich gut? Der jüngste Copilot-Vorfall[0] ließ MS und AI ziemlich lächerlich aussehen. Der Versuch, AI autonom arbeiten zu lassen, ist möglicherweise an sich nicht besonders klug.
Eine jüngere Analogie wären Blockchain und Kryptowährungen. Ob man sie mag oder nicht: Am Erfolg von Coinbase und anderen sieht man, dass Blockchain reale, aber enge Use Cases gefunden hat. Während des Krypto-Hypes gab es jedoch Leute, die Dinge sagten wie: „Wir werden die Lieferkette von Kaffeebohnen per Blockchain nachverfolgen.“ 2025 klingt das wie ein übertriebener Twitter-Witz, aber 2020 hat IBM tatsächlich versucht, so etwas zu verkaufen[1]. Vielleicht werden wir irgendwann zurückblicken und feststellen, dass AI-Agenten oder einige heutige Anwendungen generativer AI die Kaffee-Blockchain dieser Blase waren.
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
Aber das bedeutet nicht, dass die Modell/Mensch-Kombination die Bedürfnisse der Nutzer effektiver erfüllt. Es bedeutet, dass sie „mehr Code“ produziert. Es gibt kein LLM, das ein Change Set ausgibt, das 2000 Zeilen Code löscht. Daran erkennt man, dass „macht Engineers produktiver“ sich auf die Menge des erzeugten Codes bezieht.
Es klingt, als würdest du so argumentieren, als ginge es binär darum, ob man LLMs nutzt oder nicht; der Autor spricht aber vor allem über Risikominderung. Als Analogie: Der Autor weist darauf hin, dass ein paar Autos explodiert sind, und sagt lediglich, dass die alten Pferde nicht explodierten und man Autos weniger explosionsanfällig machen sollte, bevor man die Leimfabriken hochfährt. Du scheinst daraus zu schließen, der Autor sei grundsätzlich gegen die Entwicklung von Autos.
Auch jetzt habe ich eine Abneigung dagegen, GPT zu nutzen, aber in letzter Zeit sagen Kollegen Dinge wie „ChatGPT sagt“ oder „diesen Code hat ChatGPT geschrieben“. Ich bin stolz darauf, Code selbst zu schreiben und GPT nicht zu verwenden, aber gleichzeitig nutze ich Google und Stack Overflow. Man könnte sagen, das ist auch nur eine langsamere Version von GPT.
Der Autor scheint zu übersehen, dass auch unvollkommene, probabilistische Akteure vertrauenswürdige deterministische Systeme bauen können.
Ein Garbage-Collection-Tool würde man ja nicht aufgrund der Vertrauenswürdigkeit seines Autors glauben, sondern weil es nach umfangreichen Tests nachweislich das tut, was es soll. Ich kann mir gut vorstellen, dass Vertrauen künftig erodiert, und dass testgetriebene Entwicklung dadurch mehr Rückenwind bekommt. Nicht vertrauen, sondern verifizieren.
Die wichtigere Frage ist: Wer testet die Tests selbst? In der traditionellen Entwicklung wird jede Logik zweimal implementiert: einmal im Code und einmal in den Tests. Die Tests prüfen den Code, und umgekehrt prüft der Code implizit die Tests. Es kommt ziemlich häufig vor, dass der Bug nicht im Anwendungscode, sondern im Test lag. Man kann nicht blind den Tests vertrauen und warten, bis ein Agent einen Weg findet, den Test-Bug in den Code zu replizieren.
Um beim Beispiel der Garbage Collection zu bleiben: Natürlich ist es denkbar, dass ein agentisches System irgendwann etwas hochzieht und es mit Test-Harness, Bugfixes usw. zurechtklopft. Aber stell dir vor, man nutzt das Modell als Garbage Collector bzw. als Tool selbst. Also etwa, dass man dem Modell bei jedem Sweep den Programmspeicher vorwirft und es anweist, nicht mehr benötigte Blöcke freizugeben. Man könnte niemals darauf vertrauen, dass das Modell die richtigen Speicherblöcke exakt identifiziert, und keine „Patch“- oder „Fine-Tuning“-Maßnahme würde einen dorthin bringen.
Bei früheren Abstraktionen wie der JVM gilt: Wenn eine deterministische Ausgabe, in diesem Fall der vom JIT ausgegebene Assembler, falsch ist, wird der Bug gepatcht, und diese Abstraktion hat denselben Defekt nie wieder. Bei LLMs ist das nicht so. Wenn es um frühere Entwicklungswerkzeuge geht, die den Charakter der gesamten Branche verändert haben, ist dieser Unterschied für mich sehr wichtig. Ich sage nicht, dass LLMs die künftige Arbeitsweise nicht tiefgreifend beeinflussen werden. Ich denke nur, dass wir uns auf völlig unbekanntem Terrain mit kaum historischen Präzedenzfällen befinden.
Auch die Aussage, testgetriebene Entwicklung werde mehr Rückenwind bekommen: Ich verstehe nicht, warum TDD immer als Allheilmittel präsentiert wird, das alle Probleme beim Bau von Software löst. Ehrlich gesagt ist es fast peinlich, wie oft ich gesehen habe, dass TDD ausgehend von falschen Tests falsche Software hervorgebracht hat.
Man sollte das Ergebnis spezifizieren, nicht den Prozess. Zu erwarten, dass ein Contributor einen Patch versteht, ist eine gute Idee.
Aber Junior-Entwicklern während des Onboardings zu empfehlen oder vorzuschreiben, eine Zeit lang auf LLM-Assistenten zu verzichten, ist eine furchtbare Idee. Beim Onboarding gibt es viele zufällige Umgebungs-Setup-Probleme, und genau darin sind LLMs oft ziemlich stark. Außerdem geht es darum, sich in Code und Dokumentation einzuarbeiten, und es gibt hervorragende Textsuch- und Zusammenfassungstools, die man teilen möchte.
Es scheint ziemlich offensichtlich: Wenn man alle Schwierigkeiten und Komplexität im Leben glatt wegräumt, wird man bald überhaupt nicht mehr wissen, was zu tun ist, sobald man auf Schwierigkeiten oder Komplexität stößt. Bin ich der Einzige, der so denkt?
Dass LLMs „eine Zeit lang etwas annähern, das nahe an der richtigen Antwort liegt, und nach einiger Zeit die Genauigkeit stark einbricht“ – ein Phänomen, das der Autor AI-Klippe nennt –, höre ich zum ersten Mal. Haben andere das auch erlebt?
Die aktuellen Generatoren neigen dazu, Dinge mit der Zeit eher komplexer als einfacher zu machen. Ich bin immer derjenige, der das LLM dazu auffordert, einfacher zu refaktorisieren, oder der selbst refaktorisiert, wenn es für das LLM zu komplex geworden ist. Zumindest bei der aktuellen Generation von LLMs wirkt es daher ziemlich unvermeidlich, dass man, wenn man dem LLM einfach „die Zügel löst“ und es machen lässt, am Ende ein riesiges Rube-Goldberg-artiges Chaos bekommt, das man dann aufräumen darf.
Um das mit der Kernaussage des Textes zu verbinden: Eine erfahrene Person merkt früh, wenn ein LLM beginnt, einen aufs offene Meer hinauszuziehen, und findet, selbst wenn es etwas weiter hinausgeht, einen Weg zurück ins flache Wasser. Anfänger geraten über ihre Tiefe hinaus und verlieren sich auf See, bevor sie überhaupt verstehen, was passiert ist.
Stell dir vor, im Kontextinput stehen 10.000 Tokens, die zu 99 % korrekt sind. Jedes Mal, wenn das LLM antwortet, fügt es 1.000 Tokens hinzu, die zu 90 % korrekt sind. Nach ein paar Hin-und-her-Runden und Korrekturen am LLM ist das Kontextfenster größtenteils mit den eigenen Rest-Ausgaben des LLM gefüllt. Noch schlimmer ist, dass sich Fehler akkumulieren. Selbst die korrekten 90 % sind nur eine korrekte Extrapolation einer Diskussion über falschen Code, und das LLM gewichtet neuere Tokens höher. Dasselbe Problem tritt auch bei Prosa auf.
Bei Reasoning-Modellen kann dieses Problem noch schlimmer werden. Der gesamte Denkprozess liegt im Kontext, und wenn die Gedanken wirklich auf Abwege geraten, pflanzen sie giftige Samen, die den Verfall nähren. Es wäre gut, wenn irgendeine Form von Kontext-Pruning implementiert würde, sodass irrelevanter Kontext abgeschnitten werden kann, sobald er entsteht. Im Moment erstelle ich eine Zusammenfassung und wechsle zu einer neuen Instanz, wenn ich merke, dass Verfall einsetzt.
Bei agentischen Tools wie claude code, codex oder gemini cli ist es ein deutlich geringeres Problem. Sie verwalten ihr eigenes Kontextfenster und können Entwicklertools ausführen, um selbst Sanity Checks zu machen.
Dieser Prozess trainiert die Gewohnheit, den aktuellen Arbeitsstand zu dokumentieren, damit der neue Agent aufholen kann.