- In letzter Zeit benötigen Entwickler mehr Zeit, um von LLMs (Large Language Models) erzeugten Code zu ändern und zu ergänzen
- Wie bei bestehendem Legacy-Code muss man, um Code sicher zu ändern, zuerst verstehen, was implementiert wurde und warum – LLM-Code erschwert diesen Prozess jedoch zusätzlich
- Manche Teams verlangsamen sich, weil sie den Code gründlich reviewen und überarbeiten, aber viele Teams übernehmen kaum lesbaren und nur oberflächlich getesteten Code direkt ins Repository
- Dadurch entstehen „Verständnisschulden (Comprehension Debt)“, die später, wenn Änderungen am Code nötig werden, als noch höhere Zeitkosten zurückkehren
- LLMs können Probleme im Allgemeinen vielleicht zu etwa 70 % lösen, doch die wiederholten Fehlschläge der „Doom Loop“ lassen sich nicht vermeiden, und irgendwann ist es unvermeidlich, dass Menschen den Code selbst verstehen und korrigieren müssen
Von LLMs erzeugter Code und das Problem der Verständnisschulden
- In der aktuellen Entwicklungspraxis nimmt der Einsatz von LLM-basierten Tools zur automatischen Codegenerierung wie ChatGPT, Copilot zu
- Diese Tools erzeugen auch komplexen Code schnell, selbst ohne Wissen oder direktes Verständnis auf Seiten der Entwickler
- Dabei wird jedoch oft die Absicht, die Einschränkungen und die Funktionsweise des Codes nicht klar nachvollzogen, wodurch sich „Verständnisschulden“ aufbauen
Was sind Verständnisschulden (Comprehension Debt)?
- Verständnisschulden bezeichnen einen Zustand, in dem Teammitglieder die Qualität, Struktur und Absicht des Codes nicht ausreichend verstehen
- Kurzfristig kann das die Entwicklung beschleunigen, langfristig drohen jedoch verschiedene Nebenwirkungen wie steigende Wartungskosten, Bugs und eingeschränkte Erweiterbarkeit
Zusätzliche Risiken von LLM-generiertem Code
- Von LLMs erzeugter Code liefert schnell Ergebnisse, jedoch ohne klare Kommentare oder Kontext
- Dadurch steigt das Risiko von mangelhaftem Wissensaustausch im Team und unzureichender Kompatibilität mit bestehenden Systemen
- Wenn man sich wiederholt auf LLM-Code verlässt, kann das insgesamt zu geringerer Zuverlässigkeit des Projekts führen
Vergleich mit technischen Schulden
- Klassische technische Schulden entstehen durch bewusste Kompromisse von Entwicklern, während LLM-bedingte Verständnisschulden unbewusst anwachsen können und daher besonders riskant sind
- Das Problem ist schwer zu erkennen, und die Nachverfolgung der Ursachen sowie die Behebung werden noch komplexer
- Bei der Problemlösung ist die „Doom Loop“ (ein Teufelskreis, in dem ein LLM trotz wiederholter Versuche scheitert) eine häufige Erfahrung
Fazit und Implikationen
- Am Ende müssen Menschen den Code doch selbst lesen und korrigieren
- Beim Einsatz von LLMs ist es wichtig, Kontext und Absicht des Codes so zu dokumentieren und zu teilen, dass das gesamte Team sie versteht
- Es braucht organisatorische Maßnahmen wie stärkere Code Reviews, bessere Kommentare und Dokumentation sowie Wissensaustausch-Sessions
- Ohne das Management von Verständnisschulden können sich die Vorteile von Automatisierungstools langfristig sogar in Risiken verwandeln
- Die gesamte Branche sitzt derzeit auf einem schnell wachsenden Berg von Verständnisschulden
8 Kommentare
Ich treffe auch immer selbst die Entscheidungen für den gesamten Code, weil KI nicht alles vollständig entscheiden kann, und prüfe eigenständig, ob alles gut umgesetzt wurde.
Nach meinem Maßstab nutze ich es eigentlich nur zum Erstellen von Snippets mit klar unter 10 Zeilen (z. B. JSON-Parsing, Implementierung von Sortierung). Schon auf diese Weise scheint sich enorm viel Zeit sparen zu lassen.
Mit KI-Hilfe das Grundgerüst zu bauen ist okay, aber es scheint wirklich sehr schwierig zu sein, bis zum Schluss auch die Details sauber auszuarbeiten.
Ich persönlich habe auch schon öfter die Nebenwirkungen gespürt, wenn ich 0 bis 90 mit einem LLM geschrieben habe. Deshalb mache ich den Abschnitt von 0 bis 90 in letzter Zeit möglichst selbst und nutze es hauptsächlich im Prozess von 90 bis 100 – damit bin ich zufrieden.
Hacker-News-Kommentare
Mit der wachsenden Abhängigkeit von LLMs habe ich erlebt, dass sich bereits bestehende Probleme noch verschärfen.
Unter Verweis auf Naurs Konzept des „Theorieaufbaus“ wird darauf hingewiesen, dass ein Programm im Grunde tot ist, wenn das Entwicklungsteam dahinter aufgelöst wird.
Auch Lamports Argument „Programmieren ≠ Codieren“ wird erwähnt, um zu betonen, dass der Kern des Programmierens im Aufbau einer Theorie darüber liegt, was erreicht werden soll und wie.
Ich denke, gerade Programmierer, die keine nötigen Modelle oder Theorien aufbauen, haben besonders stark das Gefühl, dass LLMs ihnen schnell helfen.
Ich habe tatsächlich die Erfahrung gemacht, dass ich bei Softwareprojekten größeren Wert schaffe, wenn ich mich zeitweise komplett von Computern und Technik entferne.
Wenn man genau weiß, was man will, steigt die Entwicklungsgeschwindigkeit sprunghaft an, und dann werden LLMs sehr nützlich.
Hat man ein klares Ziel, lassen sich auch Halluzinationen von LLMs sofort erkennen.
Ich halte den Ansatz, einfach nur auf eine leere Leinwand zu starren und loszulegen, nicht für besonders effektiv.
LLMs können beim Einstieg helfen, aber oft gerät man dadurch auch auf völlig falsche Fährten.
Die schwierigsten Probleme habe ich manchmal eher beim Kochen in der Küche durch Nachdenken gelöst.
Einer der Gründe, warum ich AI Coding erfolgreicher als einige Kollegen nutzen konnte, ist wohl, dass ich schon vor dem Einsatz von LLMs Dinge schnell prototypisch gebaut und dann wieder komplett umstrukturiert oder verworfen habe.
Dieser Ansatz – schnelles Prototyping, kontinuierliches Refactoring usw. – ist eigentlich recht bekannt, aber viele Engineers neigen dazu, entweder von Anfang an perfekt designen zu wollen oder einen Prototyp endlos weiterzupatchen, ohne ihn wirklich zu verbessern.
Mit AI lassen sich mehrere Implementierungen parallel günstig erzeugen, sodass man verschiedene Versionen ausprobieren und vergleichen kann und dadurch schneller und effektiver eine stärkere Programmentheorie oder ein besseres Design aufbaut.
AI verkürzt diesen Loop und macht den Entwicklungsprozess viel effizienter, weil man sich stärker auf die Review der Ergebnisse konzentrieren kann.
Ich fand beeindruckend, wie das Konzept des „Theorieaufbaus“ mit der „Verstehensschuld“ von LLM-Code verknüpft wurde.
Das betrifft aus meiner Sicht nicht nur das Programmieren, sondern auch menschliches Denken und Verstehen insgesamt.
Code, Texte oder Bilder, die LLMs erzeugen, sind nur oberflächliche Resultate; wenn man die dahinterliegende Theorie nicht selbst aufbaut und erlebt, bleibt am Ende nur oberflächliches Verständnis.
Selbst wenn LLMs eines Tages den Theorieaufbau selbst leisten könnten, hätte ein rein künstliches Verständnis ohne direkte menschliche Beteiligung für mich nur begrenzte Bedeutung.
Je bequemer es wird, Maschinen für uns denken zu lassen, desto mehr sorge ich mich, dass die menschliche Fähigkeit zum <Verstehen> allmählich verkümmert.
Ich stimme Lamport zu, denke aber zugleich, dass AI auch im Prozess des „Theorieaufbaus“ – also beim Verständnis von Codebase, Algorithmen und dem Gesamtsystem – sowohl dem bestehenden Team als auch einem übernehmenden Team teilweise helfen kann.
Auch wenn sie nicht das gesamte Wissen ersetzen kann, erwarte ich, dass AI zumindest einen Teil der Lücke schließen kann.
Ich habe einmal ein Projekt übernommen, nachdem alle ursprünglichen Entwickler verschwunden waren, und die gesamte Wissensbasis des vorherigen Teams war praktisch verdampft, was zu einer sehr harten Zeit geführt hat.
Beim Versuch, das ursprüngliche Design zu verstehen, haben wir viele Bugs erzeugt, und am Ende mussten wir den Großteil des Codes neu schreiben und erweitern.
Trotz dieser Schwierigkeiten gab es dabei aber auch den Effekt, dass wir viele Designprobleme selbst noch einmal durchlebt haben.
LLMs produzieren oft Lösungen, die zwar funktionieren, aber viel komplexeren Code enthalten als nötig.
Zum Zeitpunkt der ersten Erstellung versteht man das Problem am besten und kann unnötige Komplexität relativ leicht entfernen, aber später wird der komplexe Code leicht für notwendig gehalten, wodurch eine starke Vereinfachung noch schwieriger wird.
Wartende Entwickler haben oft nicht genug Kontext oder Hintergrundwissen, um überhaupt zu erkennen, dass einfachere Alternativen möglich wären.
Erstens sollte man den Prompt klar formulieren, damit das LLM nicht unnötig komplizierte Ergebnisse erzeugt.
Zweitens sollte man immer Regeln, Training oder Kontext mitgeben, dass das Problem möglichst einfach zu lösen ist.
Und zuletzt kann man bei einer zu komplexen Lösung per zusätzlichem Prompt gezielt um Reduktion der Komplexität bitten.
Es gibt real das Problem, dass LLMs riesige Mengen schwer zu debuggenden Codes erzeugen.
Zwar gilt der Grundsatz „Teams, denen Qualität wichtig ist, müssen ausreichend reviewen und verstehen“, aber die Geschwindigkeit der Codegenerierung ist oft so hoch, dass Reviews nicht mithalten, zum Bottleneck werden oder in bloße Formalitäten abrutschen.
In meinem Umfeld fügt man immer neue Review-Prozesse hinzu, aber das hilft eher bei Junior-Entwicklern; AI lernt daraus nicht, sodass dieselben Probleme wiederkehren.
LLMs brauchen sehr viel Kontext, aber die meisten Leute geben fast gar keine Informationen und sagen nur Dinge wie „Schreib mir eine Funktion, die dieses Problem löst“.
Am Ende häufen alle Berge von Code an, die niemand versteht – also Tech Debt.
Was grundlegend fehlt, ist ein besseres „Primitive“, um dem LLM wirksamer zu vermitteln, warum etwas so gebaut werden soll, mit welchem Hintergrund, welcher Absicht und welchen Präzedenzfällen.
Wenn Code Review der Bottleneck ist, dann ist es meiner Meinung nach trotzdem besser, wenn nur das Review der Bottleneck ist, als wenn man sowohl Codierung als auch Review selbst machen muss.
Es gibt bereits Werkzeuge, die diesen Prozess ergänzen können, etwa Linting, Fuzzing oder Tests.
Für Leute, denen die Fähigkeit fehlt, ein Gesamtprojekt zu architekturieren oder Code schnell zu lesen und zu analysieren, könnte das LLM-Zeitalter schwierig werden – aber diese Fähigkeiten kann man entwickeln, und mit der Zeit werden sich alle anpassen.
Ich mag dieses Feld und sehe neue Herausforderungen positiv.
Ich habe die Erfahrung gemacht, verschiedene instruction-.md-Dateien zu erstellen und zu pflegen, in denen Coding-Regeln, unbedingt zu vermeidende Fallen und Links zu Coding-Standards für Agents festgehalten werden.
Modelle wie Gemini und Claude befolgen solche dokumentbasierten Anweisungen einigermaßen gut, machen aber gelegentlich dieselben Fehler wieder (z. B. wenn in C++ die Nutzung von
autoverboten wurde und sie es trotzdem verwenden).Ich erwarte, dass sich diese Feedback-Verarbeitung verbessert, wenn die Modelle besser werden.
Letztlich habe ich den Eindruck gewonnen, dass es der ideale Kompromiss ist, sich vom „vibe coding“ zu lösen, Menschen auf Codestruktur und Interaktionen zwischen Units achten zu lassen und AI auf Syntax und Tipparbeit zu fokussieren – das erhöht die Produktivität und hält Entwickler bei der Gesamtsteuerung.
Nachdem ich meine Denkweise beim Aufbau von Prompts und Kontext verändert hatte, wurde meine Intuition für den Einsatz von LLMs deutlich besser.
Ich betrachte Prompts und Kontext jetzt als Mittel, den Wahrscheinlichkeitsraum möglicher Ergebnisse einzuengen.
Dieser Prozess ist auch sehr effektiv, um wiederverwendbar Theorie in den Code einzubringen.
Allerdings erfordert die Vorbereitung solchen Kontexts viel Mühe und Nachdenken, und es ist noch immer nicht leicht, die Grenze zu finden, ab wann direkte Implementierung besser ist und ab wann Delegation an ein LLM sinnvoller wird.
Ich stimme dem Hinweis zu, dass „das Primitive anders ist“, und denke, dass die wirklich wichtige Einheit der Test ist.
Ich lasse das Modell beim Schreiben von Code auch Tests mit erzeugen und prüfe immer, ob die Tests gut lesbar sind.
Code sollte nur gemergt werden, wenn die gesamte Test-Suite erfolgreich durchläuft.
Die Test-Infrastruktur muss laufend verbessert werden, damit die komplette Test-Suite nicht zu langsam wird.
Alte Legacy-Codebasen zeichneten sich oft dadurch aus, dass sie keine Tests hatten – im LLM-Zeitalter gilt dasselbe.
Zur Aussage „es wird zum Bottleneck“: Auch wenn ich Code von StackOverflow einkopiere, lese und prüfe ich ihn immer zuerst, also ist am Ende ohnehin der Mensch der Bottleneck.
Ohne diesen Schritt kann man Code im Grunde gar nicht verantwortungsvoll verwenden.
Im Podcast von Dwarkesh Patel wurde kürzlich der Roman <A Deepness In The Sky> empfohlen, und beim Lesen fand ich beeindruckend, dass Computersysteme nach Jahrtausenden und überliefertes Legacy-Wissen darin eine wichtige Rolle spielen.
Der Roman behandelt den Wert von Legacy-Code und organisationalem Wissen auf interessante Weise und ist absolut empfehlenswert.
Podcast: https://www.youtube.com/watch?v=3BBNG0TlVwM
Buchinfo: https://amzn.to/42Fki8n
Es ist schade, dass der Autor Vernor Vinge verstorben ist; ich habe das Gefühl, dass seine Ideen mit der Zeit immer mehr reale Inspiration liefern.
Die Darstellung davon, wie man in ferner Zukunft Programmierer wird, war wirklich faszinierend.
Wegen der gewaltigen Menge an Libraries und Packages bestand die zentrale Fähigkeit nicht mehr darin, neuen Code zu schreiben, sondern vorhandene Module zu finden und zu kombinieren.
Als wahres Können wurde beschrieben, die feinen Nuancen und Interpretationen existierenden Codes vollständig zu durchdringen.
„A Deepness In The Sky“ scheint der zweite Band der Reihe zu sein; ich frage mich, ob man ihn auch lesen kann, ohne vorher den ersten Band gelesen zu haben.
Die Frage ist also, ob man direkt damit einsteigen kann.
Die meisten Entwickler verstehen weder Assembler noch Maschinensprache wirklich bis auf unterster Ebene.
Hochsprachen sind zur zentralen Ebene für Kommunikation und Zusammenarbeit zwischen Menschen geworden.
Mit dem Aufkommen von LLMs wird diese Ebene nun in Richtung natürlichsprachlicher und spezifikationsbasierter Entwicklung verschoben.
Letztlich denke ich, dass Hochsprachen nach jahrzehntelanger Evolution nahezu die optimale Form darstellen, um Programmspezifikationen zu vermitteln.
Versucht man mit natürlicher Sprache noch mehr Abstraktion, geht Information verloren; geht man tiefer auf niedrigere Ebenen, wird alles zu weitschweifig.
Der Sprung zur natürlichen Sprache ist nicht einfach nur ein Wechsel der Abstraktionsebene, sondern grundsätzlich eine völlig neue Art zu arbeiten.
Frühere Werkzeuge – Assembler, Compiler, Frameworks usw. – beruhten auf hartkodierter Logik und ließen sich mathematisch verifizieren; mit LLMs betreten wir dagegen eine Welt aus Unsicherheit, Vermutung und sogar Halluzination.
Viele JavaScript-Entwickler verstehen oft nicht einmal hochrangige Konzepte wie geeignete Datenstrukturen, DOM oder die Node API wirklich tiefgehend.
Es entsteht eine übermäßige Abhängigkeit von Abstraktionsschichten, und man gelangt an einen Punkt, an dem die internen Funktionsweisen kaum noch verstanden werden.
Außenstehende können gar nicht anders, als sich zu fragen: „Was passiert hier eigentlich wirklich?“
Dieses Phänomen ist bereits alltäglich geworden.
Damit wird sinnbildlich erklärt, dass es letztlich keinen grundlegenden Unterschied mehr macht, wenn LLMs Code schreiben, weil ohnehin niemand den Code intern vollständig versteht.
Natürlichsprachliche Spezifikation hat sicher eine Rolle, aber ich denke, dass es zwingend eine Zwischenschicht mit strenger Semantik geben muss.
Als Beispiel: In Kombination mit Rust schließen ein starkes Typsystem und seine Constraints ungültige Zustände aus, und selbst wenn das Kompilieren länger dauert, kommt meist das gewünschte Ergebnis heraus.
In der Rust-Community gibt es die Kultur „Wenn es kompiliert, funktioniert es meistens“; logische Bugs sind zwar weiterhin möglich, aber der reale Fehlerraum wird deutlich kleiner.
Ideal wäre für mich eine strenge Programmiersprache mit präzise definierter logischer Semantik, ergänzt um Spezifikationen wie Vor- und Nachbedingungen, während LLMs natürliche Sprache in formale Spezifikationen übersetzen.
Natürliche Sprache ist von Haus aus nicht eindeutig, sondern trägt Mehrdeutigkeit in sich.
Wenn es in Programmiersprachen Ambiguität beim Parsing gibt, gilt das als schwerer Bug; in natürlicher Sprache hat Mehrdeutigkeit dagegen kommunikative Funktionen wie Poesie, Nuancen oder Andeutungen.
Die deterministische Natur von Hochsprachen ist nicht der einzige Unterschied.
Im Programmieren ist Determinismus nicht alles, und auch Code, dessen Bedeutung für Menschen unklar ist, kann völlig deterministisch sein.
Die Achse „hohe/niedrige Abstraktion“ ist also ein ganz anderes Thema als „deterministisch/probabilistisch“.
Für mich und mein Team sieht das nach einer riesigen Welle an Arbeit aus, die auf uns zukommt.
Wir halten seit fast acht Jahren Unternehmen am Laufen, indem wir Legacy-Code retten, aber in letzter Zeit ist die Nachfrage gesunken, weil Firmen sich beim Coding auf LLMs verlassen.
Ich erwarte jedoch, dass wir nur etwa 18 Monate durchhalten müssen, bis massenhaft Anfragen kommen, kurzfristig aufgestaute LLM-bedingte Tech Debt zu beseitigen – eine riesige Chance also.
Die Schäden aus den Schuldenbergen, die Claude mit Aussagen wie „der Code ist jetzt produktionsreif“ hinterlassen hat, werden bald sichtbar werden.
Ich habe von einem Bekannten eine Geschichte über das Review eines von einem LLM erzeugten PRs gehört.
Oberflächlich funktionierte das Feature im PR perfekt, aber beim genaueren Hinsehen stellte sich heraus, dass im Grunde nur am Cache manipuliert wurde, ohne das Backend tatsächlich zu aktualisieren.
Es kostete viel Mühe, den Manager davon zu überzeugen, dass dieser Code nicht gemergt werden darf.
Seitdem vermute ich, dass es ziemlich viel Software auf der Welt gibt, die nur oberflächlich funktioniert und auf diese Weise „vibe coded“ wurde.
In solchen Fällen halte ich es fast für besser, es einfach zu mergen und die Folgen direkt erleben zu lassen.
Erst wenn man die Konsequenzen einer falschen Entscheidung selbst spürt, lernt man wirklich etwas.
Ohne Feedback findet kein Lernen statt, und solche Manager entwickeln sonst nur immer unrealistischere Erwartungen und mehr Druck auf das Entwicklungsteam, bis Mitarbeiter ausbrennen und ersetzt werden.
Ich frage mich, wie ein fachlich nicht versierter Engineering-Manager so lange in der Branche bestehen konnte.
In den letzten 15 Jahren habe ich kaum echte nichttechnische Manager gesehen.
Wenn ein solcher Manager Probleme verursacht, sollte man das meiner Meinung nach an CTO, CEO, Eigentümer oder Investoren eskalieren.
Nicht nur bei LLM-Code, sondern bei jedem fremden Code muss man „Verstehensschuld“ bezahlen.
Selbst in großen Unternehmen wie Google brauchen neue Engineers Monate, bevor sie schnell größere Änderungen an Algorithmen vornehmen können.
Von Menschen gut designter Code ist aber klar leichter zu verstehen als LLM-Erzeugnisse.
Man kann sich Dinge direkt von Menschen erklären lassen, und auch wenn LLMs plausible Antworten geben, bleibt ein echter Unterschied im tatsächlichen Kontext.
Ich habe selbst viel „vibe coding“ ausprobiert, aber am Ende baut sich dadurch kein mentales Modell des Codes auf; man spart vielleicht anfangs Zeit, verliert aber beim späteren Debuggen noch mehr davon.
Es ist in der Praxis ohnehin unmöglich, von Anfang an jedes Detail perfekt zu designen.
Und ich halte Metriken wie „akzeptierte Codezeilen“ nicht für eine verlässliche Grundlage, um Produktivität oder Zeitersparnis zu beurteilen.
Code aus LLMs sorgfältig zu prüfen und schrittweise in die richtige Form zu bringen, ist dagegen eindeutig effektiv.
Dieser Prozess ähnelt eher Pair Programming.
Es wird betont, dass die unmittelbare Übernahme von LLM-Output ohne jede Prüfung („vibe coding“) unmöglich wirklich effizient sein kann.
Unter Verweis auf Kernighan’s Law wird gesagt: „Debugging ist doppelt so schwer wie Code zu schreiben.“
Wenn ein LLM also Code erzeugt, könnte man meinen, dass zum Debuggen ein doppelt so intelligentes LLM nötig wäre.
Meine Erfahrung war nicht unbedingt so; ich muss immer selbst am Steuer sitzen.
Ich nutze hauptsächlich Claude Code und muss bei Fehlern klar benennen, was falsch ist, oder die problematischen Bereiche gezielt markieren.
LLMs wissen selbst nicht, welche Fehler sie gemacht haben, daher fühlt es sich an wie die Zusammenarbeit mit einem Junior-Entwickler.
Debugging ist also nicht zwingend eine Frage einer höheren Intelligenzstufe, sondern eher davon, dass LLMs ihre Probleme nicht selbst erkennen.
Zur Aussage „Zum Debuggen braucht man jemanden, der doppelt so intelligent ist“ denke ich, dass das mit den verschiedenen Modi unterschiedlicher „Denktiefe“ bei LLMs zusammenhängen könnte.
Bei komplexen Funktionen lasse ich das LLM oft zuerst Code-Kommentare schreiben oder anhängen, die Absicht und Vorgehensweise klar erklären.
Es gibt einen Kommentar, dass auch dann ein Review nötig ist, wenn man etwas übernimmt, das ein anderer Entwickler in den Kommentaren geschrieben hat, und dass sich das daher nicht vom Fall eines LLM unterscheidet. Ich sehe das jedoch anders. Bei Menschen wirken Dinge wie Ruf, Ansehen, Belohnung und Bestrafung. Wer heute so arbeiten würde wie ein LLM, wäre vermutlich sofort entlassen.
Ich denke immer: "KI übernimmt die Verantwortung nicht für einen."
Ich denke, der Tag ist nicht mehr fern, an dem der Einsatz von KI beim Programmieren verboten wird. Das klingt vielleicht absurd, aber ich glaube, dass es Realität werden wird.