Zwei Dinge, die LLM-Coding-Agenten immer noch schlecht beherrschen

 (kix.dev)
8 Punkte von GN⁺ 2025-10-10 | 1 Kommentare | Auf WhatsApp teilen
  • LLM-Coding-Agenten können Code-Verschiebungen wie Copy-and-Paste-Aufgaben nicht auf natürliche Weise ausführen
  • Beim Refactoring von Code ist es aufgrund einer auf Erinnerung basierenden Art der Code-Erstellung schwierig, Konsistenz zu gewährleisten
  • Im Problemlösungsprozess stellen sie kaum Fragen und bleiben stattdessen bei spekulativen Versuchen
  • Menschliche Entwickler klären Probleme durch Fragen, wenn etwas unklar ist, aber LLMs wiederholen Versuche, bis sie gegen eine Wand laufen
  • Aufgrund dieser Eigenschaften werden LLM-Agenten nicht als Ersatz für menschliche Entwickler, sondern eher als übermäßig selbstbewusste Praktikanten wahrgenommen

Zentrale Grenzen von LLM-Coding-Agenten

In letzter Zeit wird versucht, LLMs als Hilfswerkzeug beim Programmieren zu nutzen, doch aus Sicht menschlicher Entwickler gibt es dabei weiterhin Dinge, die sich unnatürlich anfühlen. Dieser Artikel erklärt klar die zwei Gründe, warum LLM-Coding-Agenten besonders unangenehm auffallen

1. Die Unnatürlichkeit bei Code-Verschiebung und Refactoring

  • LLMs führen keine echte „Copy-and-Paste“-Aktion aus
    • Wenn man sie zum Beispiel bittet, eine große Datei in kleinere Dateien zu refaktorieren, „merken“ sie sich Teile des Codeblocks, verwenden in der Originaldatei den Befehl delete und schreiben den „gemerkten“ Code mit dem Befehl write in die neue Datei
    • Sie verwenden keine „cut“- oder „paste“-Werkzeuge, sondern rekonstruieren alle Änderungen aus dem Gedächtnis
    • Menschliche Entwickler haben beim Verschieben von Code durch „Copy-and-Paste“ Gewissheit über die Übereinstimmung des Codes, LLMs können das jedoch nicht garantieren
    • Bisher hat nur Codex teilweise versucht, menschliches „Copy-and-Paste“-Verhalten mit Befehlen wie sed oder awk nachzuahmen, aber auch das ist nicht perfekt

2. Problemlösung ohne Fragen

  • Auch der Problemlösungsprozess von LLMs ist sehr anders als der von Menschen
    • LLMs stellen fast nie Fragen und versuchen stattdessen, Probleme auf Basis zahlreicher Annahmen zu lösen
    • Menschliche Entwickler prüfen bei großen Änderungen oder unklaren Situationen immer durch Fragen die Lage und handeln nach dem Prinzip, dass es keine schlechten Fragen gibt
    • LLMs hingegen neigen dazu, einfach weiter zu probieren und bei Problemen noch hartnäckiger zu wiederholen
    • Man kann Prompts übermäßig ausarbeiten, um Fragen zu provozieren, aber abgesehen von einigen Tools wie Roo passiert dieses Verhalten selten
    • Grundsätzlich könnte das daran liegen, dass LLM-Unternehmen RL (Reinforcement Learning) mit Fokus auf „schnelleres Schreiben von Code“ angewendet haben

Fazit

  • Aufgrund dieser Eigenschaften sind LLMs noch nicht so weit, menschliche Entwickler zu ersetzen
  • In der Praxis zeigen sie eher das Leistungsniveau eines übertrieben selbstbewussten Praktikanten
  • Das ist der Grund, warum sich die Zusammenarbeit mit LLMs noch nicht vollkommen natürlich anfühlt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-10
Hacker-News-Kommentare

  • Ich hatte vor Kurzem eine interessante Erfahrung. Es ging zwar nicht um Code, aber es hätte genauso gut in einem Code- oder verwandten Bereich passieren können (tatsächlich ist es auch einem Kollegen passiert). In einer HN-Diskussion darüber, warum eine vor 15 Jahren verabschiedete Regulierung nicht breiter verallgemeinert wurde, vermutete ich, dass der damalige Stand der Technik nicht ausreichte, um allgemeine Fälle abzudecken, und die Regulierung daher nur auf das angewendet wurde, was damals machbar war (zugehöriger Kommentar). Als ich die Diskussion einige Stunden später erneut prüfte, schrieben einige Leute bereits, dass die betreffende Technik damals schon ausreichend günstig gewesen sei. Also ließ ich ein LLM nach Belegen zu diesem Thema suchen, und es antwortete, der Grund seien technische Einschränkungen gewesen. Ich prüfte die zitierte Quelle zur Verifikation — tatsächlich gab es genau eine Quelle, die technische Grenzen erwähnte, und diese Quelle war ausgerechnet mein eigener HN-Kommentar. Als ich das bei der Arbeit erzählte, sagte ein Kollege, er habe auf GitHub einmal die Meinung gepostet, „so funktioniert X unter Windows“, und als er später bei Google suchte, stellten LLM-basierte Antworten genau dasselbe mit Verweis auf seine Aussage als Fakt dar. Deshalb hätte ich bei LLMs lieber die Möglichkeit zu fragen: nicht „Wie funktioniert X?“, sondern „Wenn jemand fragen würde, wie X funktioniert, zeig mir bitte eine Liste zitierfähiger Links.“

    • Ich denke, diese Art zu fragen ähnelt einem „sorting prompt“. Das ist eine Technik, die ich aus Mike Caulfields Beitrag gelernt habe und die ich auch beim Programmieren nutze (z. B. mit Claude code slash command). Wenn man das LLM nicht einfach nur antworten lässt, sondern Recherche sowie Sortierung und Bewertung überträgt, bekommt man deutlich präzisere Ergebnisse.

    • Die meisten Menschen vertrauen auf HN beim Lesen von Kommentaren zu einem bestimmten Thema ohnehin oft nach dem Muster: „Diese Person scheint etwas zu wissen, also nehme ich es erst mal als Tatsache.“ Direkte Erfahrung oder verifiziertes Wissen zu erwerben, ist tatsächlich extrem teuer, daher haben auch solche „billigen Erkenntnisse“ letztlich ihren Wert.

    • Ich habe versucht, von LLMs Begründungen zu verlangen, aber bisher hat mir noch kein LLM jemals echte Belege geliefert, die tatsächlich untermauerten, was es behauptet hatte.

    • LLMs erfinden manchmal sogar Links. Man braucht einen Deep-Research-Modus, der wirklich echte Recherche macht, und selbst dann hängt die Art, wie Informationen in den Links interpretiert werden, letztlich vom Training ab.

    • Ich habe kürzlich NotebookLM mit 6–8 vertrauenswürdigen Quellen gefüttert (IETF-, OpenID-Spezifikationen und zusätzliche Dokumente) und die sehr einfache Frage gestellt: „Welche Credential-Formate erlaubt OID4VP?“ Etwa 90 % der Antwort waren korrekt, aber dann fügte es selbstbewusst ein völlig zufälliges Format hinzu, für das es keinerlei Grundlage gab — als wäre es der Autor der Spezifikation. Weil mir das verdächtig vorkam, habe ich die Spezifikation selbst geprüft, und es stellte sich sofort als falsch heraus. Selbst bei einem „gegroundeten“ LLM ist das Vertrauen in Fakten damit für mich komplett zusammengebrochen.

  • Ich habe kürzlich mit Codex CLI eine HTML-Datei refaktorisieren lassen. Statt den Code wie erwartet zu kopieren und einzufügen, ersetzte das LLM ihn durch neu geschriebenen Code aus dem Gedächtnis und entfernte dabei auch Kommentare. Es gab einen Abschnitt mit 40 komplexen Links hintereinander. Beim letzten Check vor dem Deployment klickte ich sie einzeln durch: Der Anfang war in Ordnung, aber ab der Mitte lieferten 31 Links nur noch 404. Die Domains waren korrekt, aber die URL-Pfade waren verändert worden. Als ich im Git-Commit die alten URLs ansah, stellte sich heraus, dass das LLM die URLs auf „halluzinierte“ Pfade geändert hatte, die in Wirklichkeit gar nicht existierten. Solche subtilen und stillen Fehler sind wirklich gefährlich. Man muss extrem aufpassen.

    • Ich halte den letzten Punkt für sehr wichtig. Wegen solcher „sehr subtilen und still eingeschleusten Fehler“ werden LLMs, selbst wenn sie Arbeit so gut oder besser als Menschen erledigen, nicht auf dieselbe Weise behandelt. Vor allem Code Review ist traditionell eine wichtige Schutzschicht gegen Probleme. Wenn sich aber die Art der zu prüfenden Fehler ändert, werden bestehende Review-Methoden ineffizient. Früher konnte man bei großflächigem Code-Verschieben annehmen, dass ein Block einfach unverändert verschoben wurde, und sich stärker auf höhere Ebenen konzentrieren. Bei LLM-Refaktorisierung kann der „verschobene“ Code jedoch in Wirklichkeit zusammengefasster oder rekonstruierter „neuer“ Code sein, sodass man jedes einzelne Zeichen prüfen muss. Deshalb fände ich es sinnvoll, in Pull-Request-Beschreibungen einen Abschnitt „AI usage“ aufzunehmen, der Hinweise dazu gibt, wo und wie AI verwendet wurde, damit Reviewer wissen, welche Bereiche sie besonders genau prüfen sollten.

    • Ich habe ähnliche Erfahrungen oft gemacht, wenn ich Fragen zu Code oder Forschung gestellt habe. LLMs wirken anfangs gut, aber ab dem N-ten Schritt fangen sie an, Dinge zu erfinden. Vor einer Reise bat ich Gemini kürzlich um eine aktuelle Liste von Brauereien, und es nahm ganz selbstverständlich Orte auf, die bereits geschlossen waren oder nur vorübergehend in Betrieb gewesen waren. Ich ließ dann Links zu Öffnungszeiten ergänzen und geschlossene Orte entfernen, aber nur der vordere Teil der Liste wurde angepasst; im hinteren Teil nahm es völlig irrelevante Änderungen vor oder ließ geschlossene Orte einfach drin. Trotzdem antwortete es jedes Mal selbstbewusst, alles sei perfekt recherchiert.

    • Das ist zwar kein Code-Beispiel, aber einmal bat ich ein LLM nur darum, Rechtschreibung und Grammatik in einem Veranstaltungshinweis zu prüfen. Es schickte mir eine leicht überarbeitete Version zurück — und hatte das Datum unauffällig um einen Tag verschoben. Zum Glück habe ich es bemerkt und korrigiert, aber daraus habe ich gelernt, selbst bei sehr einfachen Aufgaben nicht blind zu vertrauen. Auch bei einem einfachen, klaren Ein-Satz-Prompt können LLMs Erstaunliches leisten, machen aber manchmal selbst bei den simpelsten Dingen unerwartete Fehler.

    • Erst vor fünf Minuten bat ich Claude, in Code nur Debug-Ausgaben hinzuzufügen, und es änderte stillschweigend auch noch einen regulären Ausdruck. Im diff war das leicht zu erkennen, aber bei großen Änderungen übersieht man so etwas schnell.

    • Dass du kurz vor dem Deployment alle 40 Links noch einmal geprüft hast, war eine kluge Entscheidung. Aber dass du nach dem Abschluss durch Codex ohne git diff einfach direkt nach master gemerged hast, überrascht mich etwas.

  • Ich stimme der Aussage des Beitrags zu. Meiner Meinung nach ist das größte Problem allerdings, dass Agenten nur einen extrem kleinen Teil des Code-Repositorys sehen. Sie kennen vorhandene Helper-Funktionen nicht und erstellen immer wieder dieselben Dinge neu. In der UI-Entwicklung können sie die gesamte UI-Struktur nicht vergleichen, weshalb sich inkonsistenter Code wiederholt. Am Ende muss ein Mensch den richtigen Kontext liefern: „Beziehe dich auf die Helper-Funktion in dieser Datei“, „Mach es wie in dieser Implementierung“, „Lies dieses Dokument unbedingt“. Wenn man passenden Kontext direkt mitliefert, kann man den Nutzen von Agenten stark erhöhen. Ein weiteres Problem ist übrigens, dass sie sich in großen Monorepos schlecht durch Ordnerstrukturen bewegen und zum Beispiel oft nicht einmal npm test aus einem Unterverzeichnis korrekt ausführen können.

    • Das ist exakt das Problem, das ich auch habe. Ich habe kürzlich rund 200 Zeilen Code für ein neues Feature geprüft, die mit Cursor erstellt wurden, und tatsächlich wurde nur ein kleiner Teil davon wirklich benötigt. Funktionen zu finden, die bereits in Utility-Bibliotheken vorhanden sind, ist extrem mühsam, deshalb lässt man es oft einfach durchgehen. Vor fünf Jahren war so ein Review noch stark vom Onboarding-Gedanken geprägt, also war es wichtig, so etwas zu zeigen. Heute wächst mit Cursor & Co. vor allem die Code-Menge, während die Entwickler die Struktur oft durchaus kennen, aber es aus Unternehmensgründen trotzdem so erzeugen, und ich habe das Gefühl, dass dadurch die Produktivität sinkt.

    • Befehle wie npm test aus Unterordnern auszuführen, war immer ein Problem. In einem Repo, das in ein Vite/React-Frontend und ein .NET-Backend aufgeteilt ist, geraten sie, wenn ein npm-Befehl fehlschlägt, in eine Art Panikzustand und kommen auch nach mehreren Versuchen nicht weiter; stattdessen wiederholen sie nur unnötiges Troubleshooting. Einmal schrieb ich sogar Anweisungen in CLAUDE.md, damit immer zuerst das aktuelle Verzeichnis geprüft wird, aber das Problem blieb: zufällig wurde der Pfad trotzdem immer wieder vergessen. Deshalb habe ich Aliasse wie run-dev server restart und run-dev client npm install hinzugefügt, die aus jedem Verzeichnis funktionieren, und reine dotnet-/npm-Befehle auf eine Verbotsliste gesetzt, um die AI dazu zu zwingen, die Projektanleitung zu lesen und die Aliasse zu verwenden. Diese Methode ist zumindest einigermaßen stabil, aber bis man dahin kommt, braucht es ziemlich viel Zeit, Mühe und Stress.

    • Ich denke, es wäre gut, große Kontextmodelle per Tool-Call zu nutzen. Gemini Chat kann ganze GitHub-Repositories ingestieren. Wie wäre ein „not-invented-here“-Tool, das vor dem Schreiben einer neuen Funktion prüft, ob es im Codebestand bereits etwas Gleichwertiges gibt? Wobei ich wohl zuerst recherchieren müsste, ob jemand so ein Tool nicht längst gebaut hat.

    • Genau deshalb braucht man Dokumente wie claude.md. Wenn wir unsere eigenen Regeln befolgen wollen, müssen sie unbedingt dokumentiert sein.

    • Eigentlich ist so eine Situation etwas, das Senior Engineers in der Praxis bei der Zusammenarbeit mit Kollegen ständig erleben.

  • Ich kann dem im Artikel zitierten Abschnitt voll zustimmen. Ich stimme zu, dass LLMs hochqualifizierte Entwickler nicht ersetzen. Wer noch bei Verstand ist, kann so etwas zum jetzigen Zeitpunkt eigentlich nicht ernsthaft behaupten. Aber leistungsschwache oder mittelmäßige Entwickler werden meiner Meinung nach bereits ersetzt. Zum Beispiel hatten wir in unserer Organisation drei Leute aus einem sechsmonatigen Bootcamp, die wir damals eingestellt haben, weil es extrem schwierig war, gute Entwickler zu finden. In der Praxis scheiterten sie jedoch schon an sehr einfachen Aufgaben, und ich musste bei jedem Review ihren Code vollständig aufräumen. Danach wurden AI-Tools exponentiell besser und übertrafen die Leistung dieser Leute. Am Ende wurden zwei entlassen, und der dritte kündigte selbst. In letzter Zeit stellen wir fast keine Junior-Entwickler mehr ein, und Leute aus Bootcamps werden wir gar nicht mehr einstellen. In meinem Umfeld ist es ähnlich, und vielleicht verschwindet deshalb gerade die ganze Bootcamp-Branche. Ob AI in Zukunft auch gute Entwickler ersetzen kann, weiß ich nicht, aber die aktuellen Daten zeigen klar, dass sie sich unglaublich schnell verbessert. Wer das negativ sieht, ignoriert die Realität. In der frühen Geschichte der USA arbeiteten 90 % der Bevölkerung in der Landwirtschaft, heute sind es nur noch 2 %. Trotzdem sind Menge und Vielfalt der Lebensmittelproduktion viel größer. All das ist ein Ergebnis technologischen Fortschritts. Ich kann mir gut vorstellen, dass sich etwas Ähnliches mit hoher Geschwindigkeit in der Softwareentwicklung wiederholt.

    • Sicher, Technologie hat die Lebensmittelproduktion gesteigert, aber tatsächlich ist auch wahr, dass der Nährwert gesunken und die Toxizität gestiegen ist.

    • Mich würde interessieren, was deiner Meinung nach der Grund dafür ist, dass Leute aus Bootcamps nicht gewachsen sind.

  • Die wichtigere Lehre ist, dass LLMs selbst bei recht einfachen Aufgaben extrem anfällig sind, wenn sie nicht mit einer beträchtlichen Menge an Anweisungen und Aufsicht begleitet werden. In meinem kleinen Projekt (2,5K Zeilen) bat ich um ein Parser-Refactoring, und der Plan sah plausibel aus. Ich setzte schrittweise Checkpoints und ließ alles nacheinander ausführen, aber jedes Mal, wenn ich fragte „Wurde die alte Struktur entfernt?“ oder „Wurde sie durch die neue ersetzt?“, kam zurück: „Nein, sie ist unverändert noch da.“ 80 % der Tests schlugen fehl, und selbst wenn ich konkrete Korrekturrichtungen vorgab, scheiterte es bei der abstrakten Aufgabe „Refactoring“ immer wieder an denselben Problemen. Am Ende musste ich so detailliert anweisen wie „Ändere in dieser Klasse genau dies“, sonst ging es nicht. In diesem Ausmaß kann man es nicht unabhängig arbeiten lassen, und der Sinn des LLM-Einsatzes wird dadurch deutlich geschmälert.

    • Meine Erfahrung ist etwas anders. Einen in TypeScript geschriebenen Expression-Tree-Parser (tinqerjs.org) habe ich mit 0 Zeilen selbst geschriebenem Code in zwei Wochen (Teilzeit) ausschließlich mit Codex+Claude fertiggestellt und dabei auch Hunderte Tests (einschließlich Duplikate) ergänzt. Ich habe auch ein ORM gebaut und konnte mit LLMs mindestens eine 4- bis 10-fache Zeitersparnis erzielen. Viel Aufsicht war nicht nötig; ich denke letztlich, dass Einsatzzweck und ein etablierter Prozess über das Ergebnis entscheiden. Entwickler, die im Umgang mit LLMs geübt sind, bauen alle ihren eigenen Workflow auf, und gemeinsam ist ihnen der Fokus auf Tests, Dokumentation und Code Reviews.

    • Das Problem „Wenn Refactoring-Anweisungen so detailliert sein müssen, lohnt es sich nicht“ sollte vielleicht eher in den Ansatz umgewandelt werden: „Wenn ich die Aufgabe in gute High-Level-Schritte zerlege und Anweisungen dazu gebe, bin ich viel schneller, als wenn ich es allein mache.“

    • Das hängt ebenfalls mit dem im Artikel angesprochenen Punkt zusammen, dass AI nicht per cut-paste arbeitet, sondern per Löschen und Neugenerieren. Dass der Code dabei Stück für Stück driftet, ist praktisch unvermeidlich.

    • Mich würde interessieren, welches Modell bzw. Tool du verwendet hast. Selbst mit Cursor oder Copilot hatte ich bei solchen kleinen Refactorings oft das Problem, ständig beaufsichtigen zu müssen.

  • LLMs helfen definitiv in manchen Bereichen. Heute Morgen habe ich zum Beispiel mit Unterstützung eines LLMs einen Bug in einem PDF-Metadata-Parser behoben, ohne tief in die PDF-Spezifikation eintauchen zu müssen. In den meisten Fällen ist das Ergebnis für mich aber weniger effizient, als es selbst zu machen. Früher ließ ich mit Codex Code Unit-Tests schreiben; ich hatte mehrere Setups vorbereitet, aber wollte es machen lassen, weil das Mocking der Daten lästig war. Ich musste es achtmal versuchen und anschließend manuell nacharbeiten, und es verstand nicht einmal, dass eine Entity obsolet geworden und im Service nicht mehr in Verwendung war. Das Ergebnis war enttäuschend. Für einen vollständigen Ersatz von Entwicklern reicht das nicht, aber wie früher Stack Overflow ist es ziemlich gut darin, bei unbekannten Themen Wissen zugänglich zu machen und Lösungswege anzustoßen.

    • Ich denke, selbst zum jetzigen Zeitpunkt haben LLMs an sich schon genügend Potenzial. Die eigentliche Magie entsteht aber in der Kombination mit Coding-Agenten. Wenn die richtigen Werkzeuge vorhanden sind und die Kopplung sowie Iteration mit dem Modell funktioniert, lässt sich auch copy-paste umsetzen, und die meisten heutigen Schwächen können durch guten Kontext, gute Anweisungen, iterative Verifikation und eine robuste Agentenarchitektur ausgeglichen werden. Schnelle Antworten, großer Kontext und Modelle mit hoher Instruktionsdisziplin verbessern das Erlebnis ebenfalls deutlich. Und auch menschliche Prompt-Skills sind meiner Meinung nach sehr wichtig. Letztlich braucht man gute Software-Engineering-Fähigkeiten, insbesondere die Fähigkeit, anderen Entwicklern Aufgaben zuzuweisen, sowie Dokumentation von Anweisungen und Best Practices im Codebestand, etwa in AGENTS.md (oder CLAUDE.md). Daher langweilt mich inzwischen die Debatte „Kann AI/LLM Entwickler ersetzen oder nicht?“. Die eigentliche Frage ist eher: „Was kann ich für mein LLM tun?“

  • Ich halte „Prompts, die dazu führen, dass Fragen präziser gestellt werden“ nicht für übertriebenes Prompt Engineering. Im Gegenteil: Es war sehr effektiv, Prompts so zu gestalten, dass bei Unklarheiten zuerst Rückfragen gestellt werden. Ein guter Programmierer weiß von selbst, ob eine Spezifikation vollständig vermittelt wurde oder zusätzliche Klärung nötig ist, und kann die AI dazu bringen, die nötigen Fragen im Vorfeld zu stellen.

    • Man kann sogar direkt festlegen, wie viele Fragen gestellt werden sollen. Bei komplexen Themen verlange ich im Voraus 20–30 Fragen, und die Ergebnisse sind ziemlich zufriedenstellend. Es ist auch nützlich, solche Q&A in einer separaten Datei zu speichern und in späteren Sessions oder mit anderen Agenten wiederzuverwenden.

    • Dank dieser Vorgehensweise schreibe ich keine Prompts mehr wie früher. Ich werfe nur noch eine Idee hin und füge hinzu: „Frag nach, wenn nötig“, und oft greift die AI genau Punkte auf, an die ich selbst nicht gedacht hatte.

  • Die Erwähnung von copy-paste im Haupttext hat mich dazu inspiriert, in clippy (einem macOS-Dienstprogramm) ein Agent-Buffer-Tool hinzuzufügen. clippy hat einen MCP-Server und interagiert mit der System-Clipboard; diesmal war aber ein separater privater Buffer passender. Die neu hinzugefügten Funktionen sind buffer_copy (kopiert einen bestimmten Zeilenbereich aus einer Datei und speichert ihn im privaten Buffer), buffer_paste (fügt die exakten Bytes aus dem Buffer in eine Zieldatei ein bzw. ersetzt sie dort) und buffer_list (zeigt den Inhalt des Buffers an). Wenn der Agent zum Beispiel anweist „Kopiere Zeile 50–75 aus auth.py“, führt der Server direkt nur Datei-I/O aus — es gibt weder Token-Generierung noch Halluzinationen. Auch die System-Clipboard bleibt unberührt. Bisher konnte man von AI generierten Code direkt in die Zwischenablage kopieren und so verwenden. Der Hauptzweck von clippy ist die Verbesserung von macOS pbcopy — also echte Dateiinhalte zu kopieren, damit man in einem Terminal in Slack oder E-Mails tatsächlich die Datei selbst einfügen kann. Wer auf macOS MCP-kompatible Agenten wie Claude verwendet, findet hier weitere Infos. Installation per brew install neilberkman/clippy/clippy.

  • Die meisten Entwickler sind oft auch nicht besonders gut darin, Fragen zu stellen. Sie setzen vieles als selbstverständlich voraus und lassen es weg. In 25 Jahren Entwicklungserfahrung hatten mehr als die Hälfte meiner Kollegen genau diese zweite Schwäche. Ich selbst war während der Hälfte meiner Karriere auch so, deshalb kann ich das gut nachvollziehen.

    • Andererseits ist es ein natürliches Phänomen, dass Menschen von autonomen Fahrzeugen oder AI eine höhere Zuverlässigkeit erwarten als von Menschen. Das Argument „Menschen können es auch nicht“ ist für Leute mit solchen Erwartungen kein besonders hilfreicher Einwand. Persönlich halte ich diese Haltung für völlig nachvollziehbar.

  • Wie im Haupttext behauptet wird, machen „LLMs kein copy-paste (oder cut-paste)“, sondern erinnern sich an Code, löschen ihn und schreiben ihn neu. Deshalb wirkt es, als würden sie jedes Mal nur neue write commands ausgeben. Beim Refactoring gibt es tatsächlich nicht so viel echtes copy/paste; oft wird mehr über kontextbasierten Recall gearbeitet. In der Praxis ist auch unklar, wie nützlich ein expliziter copy/paste-Befehl überhaupt wäre (zumindest in meinen Tests machte das keinen großen Unterschied). Für repetitive und kontextintensive Teile ist es oft effektiver, mit Tools wie fastmod Codex oder Claude bei Massenänderungen helfen zu lassen. Der Problemlösungsansatz unterscheidet sich von dem eines Menschen und wirkt daher ungewohnt, aber wenn man mit ausreichend Planung kommuniziert, kann sich schon die Herangehensweise selbst stark verändern.

    • IDEs können Funktionssignaturen oder Namen sofort über mehrere Dateien hinweg ändern, aber wenn LLM-Agenten das versuchen, brauchen sie oft Minuten und schaffen es trotzdem nicht zuverlässig. Ich denke, der Nutzen echter copy/paste-Unterstützung ist eindeutig.

    • copy/paste hilft auch stark dabei, eine Kontext-Explosion zu reduzieren. Das Modell muss sich den Inhalt eines Codeblocks dann nicht merken, sondern kann bei Bedarf jederzeit darauf zugreifen.