LLM-Codegenerierung kann zu geringerem Vertrauen führen

• 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

[GN⁺]

Hacker-News-Meinungen

• archive.is-Link geteilt, funktioniert auch in alten Browsern, und JavaScript wird nur benötigt, um CloudSnare zu umgehen

• Ein Freund von mir sagt immer: „Innovation geschieht mit der Geschwindigkeit des Vertrauens.“ Seit dem Auftauchen von GPT3 geht mir dieser Satz nicht mehr aus dem Kopf. Verifikation ist teuer, und Vertrauen ist ein zentrales Mittel, um diese Kosten zu senken. Aber ich weiß nicht, wie man bei LLMs Vertrauen aufbauen soll. Sie gehen sowohl mit Code als auch mit natürlicher Sprache unglaublich flüssig um, verirren sich dabei aber gleichzeitig in Richtungen, die man bei einem Menschen als böswillig ansehen würde

  • Hier der Autor: Dieses Zitat gefällt mir wirklich sehr. Es fasst in aller Kürze zusammen, was ich in mehreren Absätzen zu erklären versucht habe. Eine Welt, in der man jetzt alles einzeln verifizieren muss, ist ehrlich gesagt wirklich ermüdend und langsam
  • Dem Output von LLMs kann man nie vollständig vertrauen. Aber Härtung und Begrenzung des Schadenspotenzials sind möglich. Man wird wohl am Ende bei Standards wie „Best Practices“ und „SOC-AI-Compliance“ landen, etwa durch das Filtern von Nutzereingaben, Penetrationstests und das Verstecken von Secrets in dot-Dateien. LLMs sind zu nützlich, um sie zu ignorieren. Auch Vertrauen wird Schritt für Schritt aufgebaut. Menschen sind schließlich auch alles andere als zuverlässig, und ähnlich wie beim autonomen Fahren werden wir vermutlich in klar definierten Regelwerken Code erzeugen können, der fehlerärmer ist als der von Menschen. Danach wird man die Komplexität schrittweise verbessern
  • „Innovation geschieht mit der Geschwindigkeit des Vertrauens“ braucht etwas mehr Erklärung. Gab es dieses Maß an Vertrauen, als Elektrizität, Flug oder Radioaktivität erstmals entdeckt wurden? In der Wissenschaft entsteht Vertrauen im Fortschritt selbst

• Ich habe dieses Thema in der Firma auf unerwartete Weise erlebt. Unter Druck auf schnelle Ergebnisse haben ein Kollege und ich ein großes Refactoring von mir gemergt, obwohl der PR noch provisorisch war. Danach trat in ungetestetem Code ein Bug auf. Beim Debuggen gab der Kollege zu, dass er gedacht hatte, ich hätte mit AI programmiert, und dass es ihn frustriert habe, den AI-erzeugten Code im Nachhinein verstehen zu müssen. Dabei war der Code sorgfältig von Hand geschrieben, und die Ursache des Bugs waren kleine Fehler beim simplen API-Änderungsprozess. Gerade diese Erfahrung hat es uns ermöglicht, Spannungen rund um Vertrauen ganz natürlich offenzulegen und konstruktiv darüber zu sprechen. Rückblickend war diese Erfahrung des Vertrauensaufbaus auf diese Weise bedeutsam, und in einem anderen Umfeld hätte sich das viel komplizierter verheddern können. Man hat das Gefühl, immer vorsichtig sein zu müssen

• Ich verstehe die Grundannahme nicht so recht. Vertrauen darin, dass jemand guten Code schreibt, kommt doch aus realer Erfahrung damit, dass diese Person selbst programmiert hat und das Ergebnis gut war. Wenn jemand mit einem LLM arbeitet und trotzdem nur fehlerfreien Code liefert, vertraue ich ihm, und wenn jemand mit einem LLM arbeitet und Bugs liefert, dann eben nicht. Ich sehe nicht, was daran anders sein soll als bei reinem Denken im eigenen Kopf

  • Hier der Autor: Mein Punkt ist, dass es in Umgebungen mit geringem Vertrauen — etwa großen Teams mit mittlerem Vertrauensniveau oder Open Source — durch LLMs zunehmend schwer wird, allein anhand des eingereichten Codes die Fähigkeiten eines Entwicklers einzuschätzen. Wenn man die Veranlagung des Gegenübers nicht erfassen kann, muss man am Ende allen Code wie in einer „Null-Vertrauen“-Situation sorgfältig prüfen. Die Abkürzungen, die man bisher für schnelle Reviews genutzt hat, funktionieren dann nicht mehr, und für Organisationen, die kulturell daran gewöhnt sind, kann das ziemlich schmerzhaft sein. In Teams mit bereits hohem Vertrauen wirkt dieses Problem möglicherweise überhaupt nicht nachvollziehbar
  • Früher galt A=B, und ein hohes B bedeutete auch, dass A gut war. Jetzt ist daraus A+AI=B geworden, sodass ein hohes B nicht mehr bedeuten muss, dass A ebenfalls hoch ist. Und da AI derzeit probabilistisch arbeitet, ist sie oft sogar schlechter, als gar nichts zu tun
  • Du sagst „Vertrauen nur in gut funktionierenden Code“, aber die Grundlage dieses Vertrauens ist, dass der Entwickler schon vorher weiß, dass der Code wirklich bugfrei ist. In komplexen Systemen muss der Autor aber den Gesamtkontext verstehen, um zu wissen, wie der Code mit anderen Teilen interagiert und welche Edge Cases auftreten können. Wenn stattdessen ein LLM den Code geschrieben hat und der Entwickler ihn nicht vollständig versteht, verlagert sich diese Verifikationslast am Ende auf den Reviewer und führt zu Überlastung. Darum geht es
  • Wenn man mit LLMs programmiert, klappt es ein paarmal gut, und dann wird man übermütig und vernachlässigt Tests. In Wirklichkeit entstehen viele Probleme durch Kommunikationsfehler. Der Bearbeiter versteht die Gesamtaufgabe klar, aber LLMs tun sich schwer damit, Zustand zu halten, und treffen bei mehrdeutigem Kontext absurde Annahmen. Ich wünschte, ein Ansatz wie bei 4o, das zuerst aktiv nach zusätzlichen Informationen fragt, würde bei allen Code-Generierungsmodellen Standard — das könnte wirklich viele Probleme verhindern
  • Vertrauen entsteht nicht nur durch funktionierenden Code, sondern auch durch viele andere Faktoren: klare Erklärungen zu Änderungen, eine Historie guter Beiträge, angemessene Änderungsgrößen (also sinnvoll geschnittene Commits), Priorisierung von Problemen (erst Bugs beheben, dann Features hinzufügen), Fähigkeit zur Pflege bestehender Codebasis, konstante Aktivität und so weiter

• Wir leben bereits in dieser Zeit. Ich sehe viel zu oft Formulierungen wie „Entschuldigung, dass ich das übersehen habe, du hast recht.“ Bestimmt 8 oder 9 von 10 Malen. Gleichzeitig sehe ich oft Leute, die von LLMs erzeugten Code gedankenlos per Copy-and-paste einfügen und dann wütend werden, wenn das Ergebnis hinter den Erwartungen zurückbleibt. Ehrlich gesagt ist mir das lieber. Etwas klar Kaputtes ist besser als etwas, das nur oberflächlich richtig aussieht

  • Meiner Erfahrung nach neigen LLMs dazu, Code so zu ändern, dass nur die Tests durchlaufen, statt die eigentlichen Anforderungen zu erfüllen
  • Nutzt ihr LLMs über Browser-Chatbots? Wir verwenden AI-Agenten mit direktem Codezugriff, und die reden viel weniger und liefern oft tatsächlich bessere Arbeit als manche Junioren hier. Kurze, konkrete Aufgaben erledigen sie gut, sodass oft nur noch Code-Review nötig ist und wir das fast direkt verwenden. Natürlich kann eine Prediction Engine kein echtes Engineering. Wenn man zum Beispiel nicht ausdrücklich Python-Generatoren verlangt, produziert sie oft Code, der Unmengen an Speicher frisst. Aber ähnliche Fehler machen auch viele Python-Entwickler um mich herum. Insofern hilft das sogar, statt „add feature“ lieber klare Spezifikationen zu formulieren. Am nützlichsten sind AI-Agenten bei Legacy-Code, um den sich sonst niemand kümmern will. Wir haben zum Beispiel ein System, das Daten über 200 Koordinaten aus einst per Fax eingegangenen Dokumenten extrahiert. Es läuft seit über 30 Jahren unverändert, aber kürzlich hat sich das Dokument geändert. Copilot hat 30 Sekunden gebraucht, um die Koordinaten anzupassen. Ein Mensch hätte dafür locker einen Tag gebraucht. Aber ich weiß nicht, wie man in so einer Coding-Ära noch zum Experten werden soll
  • 8 oder 9 von 10 Malen ist stark übertrieben. Das ist eine völlig erfundene Statistik

• Frühere Abstraktionswerkzeuge reduzierten Komplexität und setzten dabei die „Korrektheit“ der jeweiligen Abstraktion grundsätzlich voraus. Natürlich waren sie nicht perfekt und hatten Bugs, aber das waren Implementierungsprobleme, keine wesentlichen Irrtümer. Sobald etwas gepatcht war, wurde es robuster. LLMs dagegen sind probabilistische Vorhersagemaschinen und liefern nur für gewisse Zeit eine annähernde Korrektheit. Was der Autor hier übersieht, ist, dass man auch mit unvollkommenen probabilistischen Agenten vertrauenswürdige deterministische Systeme bauen kann. Ein Beispiel: Ich vertraue einem Garbage-Collection-Tool nicht, weil ich dem Autor glaube, sondern weil das Tool selbst ausreichend getestet ist und nachweislich wie gewünscht funktioniert. In Zukunft dürfte Test-Driven Development noch wichtiger werden. Nicht Vertrauen, sondern Verifikation

  • Zu glauben, automatisierte Tests könnten alle Probleme abfangen, ist naiv. Es gibt zu viele Dinge, die schwer zu automatisieren sind: Nebenläufigkeit, Ressourcenmanagement, Sicherheitslücken und mehr. Und wer verifiziert die Tests selbst? Code und Tests implementieren jeweils Logik, und manchmal zeigt sich die Ursache eines Bugs eher in den Tests als im Code. Auch Tests darf man nicht blind vertrauen
  • Hier der Autor: Ich spreche hier eher über das Werkzeug selbst als über dessen Wirkung. Wenn zum Beispiel das Modell selbst direkt die Rolle eines Garbage Collectors hätte, also einen Speicherdump des Programms bekäme und selbst entscheide, welche Blöcke freigegeben werden, dann könnte ich diesem Urteil niemals dauerhaft vertrauen. Auch mit „Patches“ oder „Finetuning“ gäbe es da Grenzen. Bei deterministischem Output wie in der JVM verschwindet ein Fehler nach einem Patch dauerhaft. Bei LLMs ist das nicht so. Ich halte genau diesen Unterschied für den wesentlichen Trennpunkt zwischen früheren Abstraktionen und der Welt der LLMs. Ich glaube, dass LLMs großen Einfluss auf die Industrie haben werden, aber wegen der wenigen historischen Vergleichsfälle ist das echtes Neuland
  • Die Aussage, aus einem „probabilistischen Faktor“ oder einer „Entropiemaschine“ entstehe ein vertrauenswürdiges deterministisches System, klingt für mich ziemlich radikal. Und TDD wird immer wie ein Allheilmittel vorgestellt, das alle Probleme löst. Dabei habe ich peinlich oft erlebt, dass mit den falschen Tests komplett die falsche Software gebaut wurde

• Ablehnung gegenüber LLMs bringt nichts. Derzeit steigern LLMs die Produktivität von Entwicklern. Zumindest für weniger erfahrene Entwickler sind sie besonders nützlich. Werkzeuge, die die Produktivität stark erhöhen, werden nicht verschwinden, egal was irgendwer sagt. Selbst wenn große Ausfälle auftreten und wichtige Services wegen gravierender Bugs lange down sind, stoppt Technologie nicht, solange Produktivität zählt. Realistisch ist nur, die Schwächen zu lösen oder abzumildern und mit der Technologie zu gehen. Wenn Maßnahmen zur Abmilderung die Produktivitätsgewinne beeinträchtigen, werden sie umgangen werden, und am Ende werden sich Ergänzungen durchsetzen, die mit der Technologie harmonieren

  • „LLMs steigern die Produktivität von Entwicklern“ variiert extrem je nach Person und Kontext. Nach meiner Erfahrung sind es meist Junior-Frontend-Entwickler oder Leute in Startups, die oft frühe Apps bauen, die von „10x Produktivität“ sprechen. Das sind natürlich legitime Beispiele, aber solche Entwickler und ein Senior für Embedded C sprechen oft buchstäblich verschiedene Sprachen und reden völlig aneinander vorbei. Die Debatte über AI-Produktivität findet also in unterschiedlichen Kontexten statt. Und was „vernünftige Nutzung“ angeht, bin ich nicht einmal sicher, ob das Konzept des AI-Agenten selbst gut ist. Wenn man sich den Copilot-Vorfall ansieht, wurden sowohl Microsoft als auch AI verspottet. Einem AI-System autonom Arbeit zu überlassen, ist vielleicht nicht immer klug. Ähnlich gab es beim Blockchain-Hype während der Krypto-Hochphase alle möglichen Übertreibungen, aber manche Fälle wie Coinbase haben tatsächlich eine sinnvolle Nische gefunden. 2020 behauptete IBM noch, die Lieferkette von Kaffeebohnen mit Blockchain zu verwalten — aus heutiger Sicht 2025 klingt das wie ein Twitter-Witz, damals war es ernst gemeint. Am Ende könnten aktuelle AI-Agenten und andere Anwendungen generativer AI ebenfalls als Beispiele für überzogenen Hype gelten Copilot-Vorfall Forbes-Artikel
  • Der Ausdruck „produktiver“ taucht immer wieder auf, sagt aber nicht, ob das Mensch/AI-Gespann am Ende die Anforderungen der Nutzer besser erfüllt, sondern nur, dass „mehr Code produziert wird“. Ich habe noch nie davon gehört, dass ein LLM einen PR erstellt hat, der 2.000 Zeilen Code löscht. „Steigerung der Engineering-Produktivität“ bedeutet faktisch meistens einfach, mehr Code zu schreiben
  • Es ist ein Missverständnis zu glauben, der Autor wolle LLMs grundsätzlich kritisieren. Es geht nicht um ein Entweder-oder bei der Nutzung von LLMs, sondern um Risikomanagement und Schadensbegrenzung. Anders gesagt: nicht gegen die Entwicklung von Autos zu sein, sondern zu sagen, dass Autos explodieren können und man sich deshalb stärker darauf konzentrieren sollte, dieses Explosionsrisiko zu senken
  • Für mich wirkt der Originalbeitrag nicht wie „sinnloses Gejammer“, sondern wie eine realistische Auseinandersetzung mit den Fallstricken, bei denen man in der Zusammenarbeit mit LLMs leicht nachlässig wird, und mit möglichen Gegenmaßnahmen im Team
  • Ich bereue bis heute, damals React am Anfang nicht gelernt zu haben. Auch gegen GPT habe ich immer noch eine Abneigung, und um mich herum höre ich ständig „chatGPT hat das gesagt“ oder „das ist chatGPT-Code“, während ich stolz darauf bin, durch eigene Mühe zu programmieren. Ich benutze GPT nicht, aber eigentlich könnte man Google oder Stack Overflow auch als langsames GPT betrachten

• Statt Richtlinien wie „versprich, dass eingereichter Code kein LLM-Produkt ist, originell und vollständig verstanden“ oder „meistens nur Handarbeit erlaubt“ sollte man sich auf das Ergebnis konzentrieren. Es ist sinnvoll zu verlangen, dass Beitragende ihre Änderungen gut verstehen. Aber Regeln wie „Junioren sollen LLM-Tools eine Zeit lang vermeiden oder dürfen sie nicht benutzen“ finde ich nicht gut. LLMs helfen enorm bei chaotischen Onboarding-Problemen rund um das Setup von Umgebungen. Außerdem sind sie gut, um Code und Dokumentation zu erschließen, und auch als nützliche Werkzeuge für Textsuche und Zusammenfassungen

  • Onboarding ist in der Praxis auch ein Lernprozess darin, zufällige Umgebungsprobleme zu lösen. Wenn man jede Schwierigkeit und Komplexität per Automatisierung entfernt, weiß später womöglich niemand mehr, was in solchen Situationen zu tun ist. Geht das nur mir so?

• Vom Begriff „AI Cliff“ — also dem plötzlichen Einbruch der LLM-Genauigkeit — habe ich zum ersten Mal gehört. Mich würde interessieren, ob andere das auch erlebt haben

  • Ich erlebe das oft. Sobald die Komplexität des Codes einen Schwellenwert überschreitet, kann das LLM den Kontext nicht mehr komplett im Kopf behalten und verhält sich dann völlig daneben. Meine Aufgabe besteht darin, die Komplexität zu managen, die das LLM zu sehen bekommt. Aktuelle LLMs neigen mit der Zeit dazu, die Struktur immer komplizierter zu machen. Normalerweise bitte ich sie deshalb um Refactoring zur Vereinfachung, oder ich räume selbst auf, wenn es zu komplex wird. Wenn man heutige LLMs einfach weiterlaufen lässt, produzieren sie am Ende ein riesiges Durcheinander im Stil einer Rube-Goldberg-Maschine, das dann doch wieder ein Mensch aufräumen muss. Erfahrene Entwickler merken schnell, wie weit das LLM sie aufs offene Meer hinausführt, und kehren früh genug um; Anfänger hingegen verirren sich oft komplett, bevor sie überhaupt merken, was passiert
  • Ich nenne das context drunk. Wenn der Eingabekontext 10.000 Tokens umfasst und zu 99 % korrekt ist, liefert das LLM vielleicht 1.000 Tokens Antwort, die nur zu 90 % korrekt sind. Nach mehreren Hin-und-her-Runden besteht der Großteil des Kontextfensters aus wiederholtem, weniger präzisem Output des LLM. Fehler akkumulieren sich, und weil jüngere Informationen stärker gewichtet werden, wird alles zunehmend unsinniger. Das betrifft nicht nur Code, sondern auch Prosa
  • Ich nenne es context rot. Wenn sich Kontext ansammelt, sinkt die Ausgabequalität. Je mehr Smalltalk oder irrelevanter Inhalt dabei ist, desto schneller wird es schlechter. Besonders wenn chain of thought (COT) im Kontext stehen bleibt, verschlimmert sich das, sobald das Denken abdriftet. Ich persönlich hätte gern eine Pruning-Funktion, die Teile des Kontexts gezielt abschneidet. Ich begegne context rot, indem ich selbst zusammenfasse und mit einer neuen Session weitermache
  • So etwas habe ich nur in Chat-Interfaces wie beim vibe coding erlebt. Agentenbasierte Tools verwalten ihr Code-Kontextfenster selbst und führen Dev-Tooling direkt aus, um Sanity Checks zu machen, daher passiert das dort deutlich seltener
  • Ich setze AI-Sessions für die Arbeit oft zurück und spüre deshalb selten einen „AI Cliff“. Beim Schreiben von fiktionalen Geschichten ist die Länge und Kohärenz des Kontexts aber wichtig, und da habe ich erlebt, dass die AI irgendwann die Persönlichkeit von Figuren nicht mehr konsistent halten konnte und seltsam reagierte. Weil sich das nicht zurückdrehen ließ, war das ein sehr fremdartiges Erlebnis

• Der Autor des Originalbeitrags sagt zwar, er werde nicht mehrere Beiträge zusammenfassen, aber faktisch scheint er genau das zu tun. Trotzdem fände ich es gut, wenn Dateien mit AI-generiertem Code im PR markiert würden. LLM-Code und menschlicher Code haben unterschiedliche Fehlermuster, daher könnte man Reviews gezielter durchführen und Zeit sparen. Mich würde interessieren, ob jemand so eine Richtlinie schon in großen Organisationen erlebt hat oder ob es dafür bereits Automatisierungs-Tools gibt. Wenn Unternehmen den Anteil von LLM-generiertem Code messen, gibt es vielleicht für detaillierte Metriken längst solche Werkzeuge

  • Hier der Autor: Tatsächlich gibt es in Teams noch nicht viele explizite Diskussionen über Vertrauen und LLMs, deshalb habe ich noch keine formalisierten Beispiele gesehen. Ich weiß nicht, ob ich einfach am falschen Ort arbeite und man so etwas dort stärker problematisiert, oder ob es sich deshalb schwer im Mainstream finden lässt