Übermäßiges Editieren: Wenn Modelle Code über den nötigen Umfang hinaus ändern

 (nrehiew.github.io)
9 Punkte von GN⁺ 6 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Selbst bei Bugs, die sich mit minimalen Änderungen beheben ließen, kommt es leicht zu einer riesigen Diff, weil ganze Funktionen neu geschrieben, Hilfslogik ergänzt und sogar Signaturen geändert werden.
  • Bei Brownfield-Arbeit, die bestehende Strukturen beibehält, reicht ein bestandener Test nicht aus; für Prüfbarkeit und Änderungssicherheit muss auch betrachtet werden, wie wenig tatsächlich geändert wurde.
  • Auf Basis von 400 programmgesteuert beschädigten BigCodeBench-Problemen wird Over-Editing mit tokenbasierter Levenshtein-Distanz, relativem Patch-Score und Added Cognitive Complexity quantifiziert.
  • Über aktuelle Coding-Modelle hinweg zeigte sich eine Tendenz zum übermäßigen Umschreiben; Claude Opus 4.6 war stark in der Kombination aus Genauigkeit und minimaler Änderung, während GPT-5.4 relativ deutlich zu Over-Editing neigte.
  • Ein Prompt, der die Bewahrung des Originals explizit verlangt, verringerte besonders bei Reasoning-Modellen die Diff, und bei den Trainingsmethoden lieferte RL die ausgewogensten Ergebnisse, indem es minimales Editierverhalten lernte, ohne die allgemeine Coding-Leistung zu verschlechtern.

Das Problem des Over-Editings

  • Over-Editing bezeichnet das Phänomen, dass über den für die Fehlerbehebung nötigen minimalen Änderungsumfang hinaus sogar die Codestruktur stark verändert wird.
    • Selbst bei einem Off-by-one-Bug, bei dem es genügen würde, range(len(x) - 1) zu range(len(x)) zu ändern, treten übermäßige Änderungen auf, etwa wenn das Modell die gesamte Funktion neu schreibt und Hilfsfunktionen oder Validierungslogik ergänzt.
    • Im Beispiel führte GPT-5.4 None-Prüfungen, np.asarray(dtype=float)-Konvertierungen, Finite-Value-Masking, Prüfungen der Array-Größe, Änderungen an der Signatur des curve_fit-Aufrufs und sogar eine Ersetzung der Plotting-Logik durch; die Tests bestehen zwar, aber es entsteht eine riesige Diff.
  • Bei Brownfield-Arbeit an bestehenden Codebasen ist es wichtig, nur das Problem zu beheben und dabei Code zu erhalten, den das Team bereits versteht und bewusst so geschrieben hat.
    • Anders als bei neu entstehendem Greenfield-Code erschweren Änderungen, die die bestehende Struktur nicht respektieren, Reviewern nachzuvollziehen, was warum geändert wurde.
    • Wenn ganze Funktionen neu geschrieben werden, wird der Code schwerer lesbar und die Änderungssicherheit lässt sich ebenfalls schwieriger beurteilen.
  • Mit dem Kriterium, dass nur die Tests bestehen müssen, lässt sich dieses Problem schwer erfassen.
    • Over-Editing ist kein Korrektheitsfehler, sondern ein Fehler der Editier-Treue und zeigt sich daher in Testsuiten oft nicht.
    • Je mehr generierter Code hinzukommt, desto mehr muss geprüft werden, und unnötige Komplexität kann sich ansammeln, wodurch die Qualität der Codebasis stillschweigend sinkt.

Wie Over-Editing gemessen wird

  • Um einen Datensatz zu erstellen, bei dem die richtige Minimaländerung eindeutig ist, wurde ein Evaluationssatz aus 400 programmgesteuert beschädigten BigCodeBench-Problemen aufgebaut.
    • Anders als bei bestehenden Benchmarks wurden die Bugs nicht von anderen LLMs injiziert, sondern fein kontrolliert erzeugt, etwa indem < zu <=, + zu - oder True zu False geändert wurde.
    • Für jedes beschädigte Sample wurde verifiziert, dass es syntaktisch gültig ist und die zugehörigen Testfälle bricht; die korrekte Reparatur besteht ausschließlich darin, die Beschädigung rückgängig zu machen, sodass die minimale Änderung gewährleistet ist.
  • Dank dieses Aufbaus lässt sich nicht nur bewerten, ob ein Modell den Bug behoben hat, sondern auch, wie viel es dabei zusätzlich geändert hat.
    • Dazu wird sowohl für die Referenzlösung als auch für die Modellausgabe die relative Patch-Größe im Vergleich zur beschädigten Eingabe berechnet.
    • Je mehr zusätzliche Änderungen über die Wiederherstellung der korrekten Lösung hinaus vorgenommen werden, desto schlechter fällt der Score aus.
  • Der zugehörige Code ist im GitHub-Repository verfügbar.

Metriken

  • Tokenbasierte Levenshtein-Distanz

    • Statt der üblichen zeichenbasierten Levenshtein-Distanz wird eine Python-Variante auf Token-Ebene verwendet.
    • Der Code wird mit dem Python-Tokenizer in atomare Syntaxeinheiten wie def, add, (, a, ,, b, ) zerlegt, und die Distanz wird auf dieser Tokensequenz berechnet.
    • Wenn def add(a, b): zu def someotherfunctionname(a, b): geändert wird, beträgt die zeichenbasierte Distanz 19, die tokenbasierte Distanz jedoch 1, weil nur ein Identifikator als geändert gilt.
    • Damit Funktionen unterschiedlicher Länge vergleichbar bleiben, wird durch die Gesamtzahl der Tokens normalisiert.

  • Relativer Patch-Score

    • Modellausgabe und Referenz werden nicht direkt miteinander verglichen, sondern beide relativ zur beschädigten Eingabe.
    • Die Bearbeitung, die aus der beschädigten Lösung wieder die ursprüngliche Lösung macht, ist die echte Minimaländerung, und gemessen wird, wie nahe die vom Modell erzeugte Änderung daran liegt.
    • Je näher der Wert an 0 liegt, desto ähnlicher ist der Modell-Patch der tatsächlichen Minimaländerung.

  • Added Cognitive Complexity

    • Zusätzlich wird Cognitive Complexity verwendet, da sie die Leseschwierigkeit besser abbildet als Cyclomatic Complexity.
    • Verschachtelung, Rekursion, komplexe logische Operatoren und nicht intuitive Kontrollflüsse werden bestraft; Strukturen wie if, Schleifen oder try/except, bei denen der Leser mehr Zustände mitverfolgen muss, erhöhen die Komplexität.
    • Im Beispielcode mit verschachtelten Schleifen und Bedingungen beträgt die Cognitive Complexity 6.
    • Da in dieser Beschädigung nur Werte geändert und keine Strukturen angefasst werden, sollte eine korrekte Reparatur bei der Added Cognitive Complexity immer 0 ergeben.
    • Steigt die Komplexität in der Modellausgabe, wurde nicht angeforderter Code hinzugefügt; auch ein Wert kleiner als 0 gilt als unerwünschte unnötige Vereinfachung.

Over-Editieren Modelle tatsächlich?

  • Selbst bei aktuellen Frontier-Modellen wurde Over-Editing beobachtet.
    • Sowohl bei Reasoning- als auch bei Nicht-Reasoning-Modellen gibt es Unterschiede zwischen Pass@1 und minimaler Editier-Treue.
    • Allein aus der Fähigkeit, einen Fehler korrekt zu beheben, lässt sich also nicht beurteilen, ob auch treu editiert wurde.
  • Im Vergleich der Reasoning-Modelle zeigte Claude Opus 4.6 die stärkste Kombination.
    • Mit einem Pass@1 von 0.912 war es am besten und hatte mit normalisierter Levenshtein-Distanz von 0.060 sowie Added Cognitive Complexity von 0.200 auch die kleinste Diff.
    • Gemini 3.1 Pro Preview lag in einem ähnlichen Bereich, und unter den Open-Weight-Modellen editierte GLM 5 relativ konservativ.
  • GPT-5.4 gehört unter den evaluierten Modellen zu den stärksten Fällen von Over-Editing.
    • Im Reasoning-Modus lagen Levenshtein bei 0.395 und Added Cognitive Complexity bei 2.313; im Nicht-Reasoning-Modus waren sie mit 0.327 beziehungsweise 1.563 ebenfalls hoch.
    • Auch Pass@1 fiel mit 0.723 und 0.770 eher niedrig aus, was sowohl bei Genauigkeit als auch bei minimaler Änderung schwache Ergebnisse zeigt.
  • Unter den Nicht-Reasoning-Modellen erreichte Qwen 3.6 Plus mit Pass@1 0.870 den höchsten Wert, während GLM 5 mit Added Cognitive Complexity 0.235 am niedrigsten lag.
    • Auch das Nicht-Reasoning-Modell Claude Opus 4.6 hielt die Änderungsbreite mit Levenshtein 0.079 und Added Cognitive Complexity 0.313 sehr gering.

Lässt sich das per Prompt verbessern?

  • Wenn dem Prompt „IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible“ hinzugefügt wurde, sank bei allen Modellen die Levenshtein-Distanz.
    • Mit Ausnahme von DeepSeek R1/v3 verbesserte sich dabei auch Pass@1.
    • Das lässt sich so interpretieren, dass die Einschränkung auf minimale Änderungen den möglichen Änderungsraum verkleinert und zu präziseren, gezielteren Änderungen führt.
  • Dieser Effekt zeigte sich besonders stark bei Reasoning-Modellen.
    • Weil sie explizite Anweisungen besser befolgen, führt die Forderung nach minimalen Änderungen dort deutlicher zu einer kleineren Diff.
    • Das zeigt, dass selbst Modelle, die standardmäßig zu stark eingreifen, mit klarer Anweisung zu treueren Änderungen übergehen können.

Führt Schlussfolgern zu übermäßigem Umschreiben?

  • Paare aus schlussfolgernden und nicht schlussfolgernden Modellen derselben Modellfamilie wurden gebildet, und die Levenshtein-Distanz wurde nur für Samples verglichen, bei denen beide die richtige Antwort lieferten
    • Wenn es viele Fehlschläge gibt, entsteht eine Verzerrung, weil sich die Gelegenheiten für Over-Editing selbst verringern; daher wurde nach Kontrolle der Genauigkeit nur der Bearbeitungsstil isoliert betrachtet
  • Unter allgemeinen Prompt-Einstellungen schreiben schlussfolgernde Modelle in den meisten Paaren mehr um
    • Bei DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus und Kimi 2.5 liegt der Balken für die schlussfolgernde Variante jeweils höher
    • Es zeigt sich eine Tendenz, dass erweitertes Schlussfolgern statt auf minimale Korrekturen eher auf eine „bessere Implementierung“ hinausläuft und dadurch unnötiges Refactoring erzeugt
    • Die Ausnahme ist Claude Opus 4.6, bei dem die schlussfolgernde Variante deutlich weniger ändert als die nicht schlussfolgernde
  • Wenn explizit die Erhaltung des Originals angewiesen wird, verändert sich das Bild deutlich
    • Die schlussfolgernden Modelle zeigen in fast allen Paaren dieselbe oder eine niedrigere Levenshtein-Distanz als die nicht schlussfolgernden
    • Die schlussfolgernde Variante von Claude Opus 4.6 erreicht in dieser Einstellung die niedrigste Levenshtein-Distanz aller Modelle
    • Auch bei GPT-5 und GPT-5.4 sinken die Werte der schlussfolgernden Varianten stark, aber bei GPT-5.4 liegt die nicht schlussfolgernde Variante weiterhin knapp vorn
  • Im Standardverhalten neigen schlussfolgernde Modelle zwar eher zu Over-Editing, doch dieselbe Schlussfolgerungsfähigkeit sorgt auch dafür, dass sie Einschränkungen besser befolgen
    • Der Unterschied zwischen allgemeiner und expliziter Einstellung fällt bei schlussfolgernden Modellen konsistent größer aus
    • Daher ist Over-Editing eher ein Standardverhalten als eine grundlegende Grenze und kann durch Einschränkungen umgekehrt werden

Lassen sich durch Training treue Editoren erzeugen?

  • Als Basismodell wird Qwen3 4B 2507 Instruct verwendet, und Konfigurationen mit 0-shot und 8-shot inklusive Anweisung zur Erhaltung des Originals dienen als Baseline
    • Andere Trainingsmethoden werden bei der Evaluation unter allgemeinen Einstellungen ohne explizite Anweisung zur Originalerhaltung getestet

  • Versuchsaufbau

    • DeepCoder-Probleme wurden auf dieselbe Weise beschädigt, um einen synthetischen Datensatz zu erstellen
    • Zusätzlich erzeugte das Basis-Qwen3 4B 2507 Instruct für jedes Problem 8 Completions; nach dem Aussortieren blieb nur funktional korrekter Output übrig, der anschließend nach Levenshtein-Distanz gerankt wurde, woraus ein Self-Distillation-Datensatz entstand
    • Das Training ähnelt Context Distillation und wird so ausgerichtet, dass das Modell bei der Evaluation auch ohne explizite Anweisung minimal editierendes Verhalten zeigt

  • Trainingsmethoden

    • SFT: direktes überwachtes Fine-Tuning auf dem programmatisch erzeugten Datensatz
    • rSFT: Training auf dem Self-Distillation-Datensatz, wobei pro Sample nur die 3 Completions mit der niedrigsten Levenshtein-Distanz verwendet werden
    • DPO: Preference Optimization zwischen der Completion mit der höchsten und der mit der niedrigsten Levenshtein-Distanz pro Sample
    • RL: Anwendung von Reinforcement Learning mit einer kombinierten Belohnung aus funktionaler Genauigkeit und minimaler Bearbeitung auf Basis der Levenshtein-Distanz
      • Wenn alle Tests bestanden werden, gilt r = r_edit + 0.1
      • Wenn sie nicht bestanden werden, gilt r = -0.2
      • r_edit wird als normalisierte, auf Levenshtein basierende Belohnung berechnet

Wie sahen die Ergebnisse bei gleichem Fehlertyp aus?

  • In der In-Domain-Einstellung, bei der Trainings- und Testset denselben Fehlertyp haben, erzielt SFT ein nahezu perfektes Ergebnis
    • Baseline 0-shot erreicht Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
    • Baseline 8-shot erreicht Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
    • SFT erzielt mit Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000 Bestwerte in allen drei Metriken
    • rSFT erreicht 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113 und RL 0.802 / 0.046 / 0.112
  • Da dieses Ergebnis zu gut erschien, wurde geprüft, ob das Modell möglicherweise nur die Rücktransformation eines bestimmten Fehlertyps auswendig gelernt hat
    • Die Annahme war, dass das Modell nicht allgemeines minimal editierendes Verhalten gelernt haben könnte, sondern nur darauf trainiert wurde, festgelegte Fehlermuster rückgängig zu machen
    • Um das zu prüfen, wurden Fehlertypen in Trainings- und Evaluationsdaten vollständig unterschiedlich neu zusammengestellt

Generalisiert das auch auf andere Fehlertypen?

  • In der Out-of-Domain-Einstellung, in der Trainings- und Testset unterschiedliche Fehlertypen haben, bricht SFT stark ein
    • Pass@1 von SFT fällt auf 0.458, und das Modell versucht dann nur noch bestimmte minimale Änderungen, ohne Bugs tatsächlich zu beheben
    • Norm. Levenshtein liegt bei -0.008 und Added CC bei 0.006, also sehr niedrig, doch die Fähigkeit zu korrekten Reparaturen kollabiert
  • rSFT und DPO schneiden leicht besser ab als die 8-shot-Baseline, doch der Zugewinn bleibt klein
    • rSFT erreicht 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
    • DPO erreicht Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
    • Schon Training nur mit vom Basismodell selbst erzeugten Trace-Daten ermöglicht also eine gewisse Generalisierung
  • Nur RL generalisiert sauber über alle drei Metriken hinweg
    • RL erreicht Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006
    • Gegenüber beiden Baselines verbessern sich alle drei Metriken, und auch die allgemeine Coding-Leistung sinkt nicht
    • Dass die Verbesserungen bei Levenshtein und Added Cognitive Complexity größer ausfallen als bei Pass@1, stützt die Annahme, dass nicht bloß einfache Fehlerrücktransformationen auswendig gelernt wurden, sondern minimal editierendes Verhalten selbst

Catastrophic Forgetting

  • Mit LiveCodeBench v6 wurde außerdem geprüft, ob beim Fine-Tuning für minimale Bearbeitung die allgemeine Coding-Fähigkeit leidet
    • Ziel ist, dass das Modell auch nach dem Training ein Niveau ähnlich dem ursprünglichen pretrained Modell hält
  • Bei SFT ist der Rückgang der allgemeinen Fähigkeiten sehr groß
    • Auf LiveCodeBench zeigt sich ein Leistungsabfall von 43 %, und selbst grundlegende Fähigkeiten zur Identifikation und Behebung von Bugs bleiben nicht erhalten
  • Auch rSFT und DPO sinken leicht ab
    • Selbst wenn mit vom ursprünglichen Modell erzeugten Samples trainiert wird, bleibt aufgrund der Aufgabeneigenschaften ein gewisses Maß an Catastrophic Forgetting bestehen
  • RL lernt das neue Verhalten ohne Leistungsabfall
    • Es erhält die allgemeine Coding-Fähigkeit und verbessert zugleich die Leistung bei Aufgaben mit minimaler Bearbeitung am stärksten
    • Das steht in Einklang mit SFT memorizes while RL generalizes
  • Aus Verteilungssicht ist auch die Interpretation möglich, dass Forgetting umso stärker ausfällt, je größer die Differenz zwischen dem programmatisch erzeugten Datensatz und der ursprünglichen Modellverteilung ist
    • SFT wird stark auf Daten ausgerichtet, die sich deutlich von der ursprünglichen Verteilung unterscheiden, wodurch sich die Modellverteilung stark verändert
    • Bei rSFT und DPO verlaufen die Änderungen weniger abrupt, weil ihre self-distilled Daten näher an der ursprünglichen Verteilung liegen
    • Das Ausmaß von Catastrophic Forgetting könnte weitgehend proportional zur Differenz zwischen ursprünglicher Verteilung und der Verteilung der aufgabenspezifischen Trainingsdaten sein

Zusätzliche Experimente

  • RL mit LoRA: Ist vollständiges Fine-Tuning nötig?

    • Da diese Aufgabe eher einer Stilanpassung der Fähigkeit zum Bearbeiten bestehenden Codes ähnelt als dem Einbringen neuen Wissens, wurde geprüft, ob LoRA dafür ausreicht
    • rank 1: Pass@1 0,738, Norm. Levenshtein 0,166, Added CC 0,676, LiveCodeBench Δ -0,022
    • rank 8: 0,775 / 0,112 / 0,426 / -0,022
    • rank 16: Pass@1 0,805 / 0,087 / 0,328 / -0,005
    • rank 32: 0,795 / 0,065 / 0,235 / -0,011
    • rank 64: 0,797 / 0,051 / 0,160 / +0,001
    • Das beste Full-RL-Modell erreichte 0,782 / 0,050 / 0,185 / +0,006
    • rank 64 LoRA kommt bei Levenshtein Full RL nahezu gleich und fällt bei Added CC sogar besser aus
    • Mit zunehmendem rank nehmen Levenshtein und Added CC von 1 bis 64 monoton ab
    • Die größten Verbesserungen konzentrieren sich auf die frühe Phase: Von rank 1→16 sinkt Levenshtein deutlich von 0,166→0,087, von 16→64 verengt sich der Wert dann schrittweise auf 0,051
    • Bei rank 1 und 8 zeigt sich ein Trade-off zwischen Genauigkeit und minimalen Änderungen; möglicherweise reichte die Kapazität nicht aus, um beide Belohnungsfunktionen gemeinsam zu lernen, sodass das Modell stärker zur höher gewichteten Edit-Minimierung tendierte
    • Für Verhaltensänderungen auf Stilebene bei Aufgaben, deren Grundfähigkeit bereits vorhanden ist, reichen wenige zusätzliche Parameter aus, und ab einem gewissen Punkt nimmt der Grenznutzen weiterer Kapazität ab

  • Notizen zu Reward Hacking

    • In der anfänglichen Belohnungsfunktion gab es einen Bug, durch den Rollouts ohne einen einzigen erfolgreichen Run 0 Punkte erhielten
    • Da das Vorzeichen von Levenshtein umgedreht worden war, um die Metrik in die Form „je größer, desto besser“ zu bringen, konnte dieser Wert 0 paradoxerweise zu einer höheren Belohnung führen als ein erfolgreicher Run
    • Trotzdem lernte Full RL die Aufgabe, während sich nur bei LoRA Reward Hacking zeigte, bei dem funktional korrekter Code gar nicht mehr ausgegeben wurde, was zu einer Überprüfung der Umgebung führte
    • Nach der Korrektur der Belohnungsfunktion verbesserten sich die Full-RL-Ergebnisse nur leicht

  • Lässt sich das auch auf größere Modelle ausweiten?

    • Dasselbe Out-of-Domain-RL-Rezept wurde auf Qwen3 14B angewendet
    • Das Baseline-14B erreichte Pass@1 0,770, Norm. Levenshtein 0,136, Added CC 0,315
    • Nach Anwendung von RL zeigten sich durchgängig Verbesserungen auf Pass@1 0,833, Norm. Levenshtein 0,059, Added CC 0,165, LiveCodeBench Δ +0,011
    • Auch bei höherer Parameterzahl bleiben steigendes Pass@1, sinkendes Levenshtein, geringere Added Cognitive Complexity und das Ausbleiben von Catastrophic Forgetting gemeinsam erhalten
    • Das stützt die Annahme, dass sich das RL-Rezept für minimale Code-Edits auf Modelle verschiedener Größenordnungen skalieren lässt

Abschließende Zusammenfassung

  • Over-Editing ist ein verbreitetes und messbares Problem
    • Bei Frontier-Coding-Modellen zeigt sich durchgängig, dass die Fähigkeit, korrekt zu reparieren, und die Fähigkeit, mit minimalen Änderungen zu reparieren, voneinander getrennt sind
    • Insbesondere GPT-5.4 zeigt in der Standardeinstellung eine relativ starke Tendenz zum übermäßigen Umschreiben, während Opus 4.6 eine starke Baseline liefert
  • Bereits mit expliziten Prompts lässt sich in erheblichem Maß zu getreuen Edits steuern
    • Vor allem Reasoning-Modelle neigen standardmäßig dazu, zu stark einzugreifen, befolgen Anweisungen zum Erhalt des Originals jedoch besser
    • Auch GPT-5.4 zeigt im Reasoning-Modus große Verbesserungen, was seine Fähigkeit zum Instruction Following klar unterstreicht
    • Dass die Verbesserung bei Opus 4.6 kleiner ausfällt, könnte daran liegen, dass die Ausgangsleistung bereits hoch ist
  • Auf Trainingsebene erweist sich RL als die ausgewogenste Lösung
    • Es lernte ein getreueres Editierverhalten, ohne die allgemeine Coding-Fähigkeit zu beeinträchtigen, und der Effekt blieb sowohl bei 4B als auch bei 14B Qwen3 erhalten
    • SFT war bei bestimmten Schadensarten stark, scheiterte jedoch deutlich bei Generalisierung und beim Erhalt allgemeiner Fähigkeiten
  • Die Bewertung von Bugfixes auf Ebene einzelner Funktionen ist zwar enger gefasst als agentischere Benchmarks wie SWE-Bench Pro, bildet aber einen Ausgangspunkt, um das schwer quantifizierbare Problem des Over-Editing in realistischen Settings zu adressieren
    • Die Bewertung und Verbesserung der Fähigkeit zu minimalen Edits könnte zu einer generellen Qualitätssteigerung von KI-generiertem Code führen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 일 전
Hacker-News-Kommentare

  • Die Art, wie ich Claude Code nutze, übertrifft meine Erwartungen bei weitem
    Wenn es zu viel verändert, lasse ich erklären, was schiefgelaufen ist, und halte die Erkenntnis in einer projektbezogenen Skill-Datei fest
    Dadurch wiederholt es denselben Fehler fast nie, und wenn die Skill-Datei wächst, kann es sie auch ziemlich gut aufräumen und komprimieren
    Inzwischen habe ich das Gefühl, dass es wirtschaftlich kaum noch Sinn ergibt, bei der Arbeit selbst direkt Code zu schreiben
    Ich bin eher Lehrer, Architekt und Infrastruktur-Administrator, und den Großteil der Entwicklung delegiere ich an ein eingespieltes Team aus Claude-Sessions
    Natürlich reviewe ich alles, und Claude schreibt auch engmaschige Tests, die wir gemeinsam prüfen
    Inzwischen bewältigt es auch große Projekte ohne größere Probleme
    Ich will das nicht wie eine Anthropic-Werbung klingen lassen, aber ich frage mich ernsthaft, was ich eigentlich tue, dass es bei mir ungewöhnlich gut funktioniert
    Und Tokens sind inzwischen auch fast nie knapp
    Ich nutze fast nur noch das Opus-Modell, es ist sehr tokeneffizient, und letzte Woche habe ich mit Claudes Hilfe über 150 sinnvolle Commits gemacht und trotzdem nur ein Drittel meines Wochenkontingents verbraucht
    Vor Claude lag mein Limit bei etwa 25 bis 30 Commits pro Woche

    • Bei mir ähnlich
      Ich habe gestern Statistiken gesehen und war überrascht, dass inzwischen 97 % unseres Firmen-Codes von Cursor AI geschrieben werden
      Meistens lasse ich es als Cloud-Agent laufen, weil es mich ablenkt, wenn ich ihm in Echtzeit zusehe
      Meine Methode ist extrem simpel: klar in Worten sagen, was man will
      Die Leute machen das viel zu kompliziert
      Diese Obsession mit geteilten .md-Dateien, Orchestrierung und Prompt-Hacks wirkt auf mich ungefähr so interessant wie eine Überfixierung auf Vim-Shortcuts oder IDE-Skins
      Man muss einfach klar sagen, was man will, und gutes Feedback geben
    • Geht mir genauso. Als Arbeitserleichterung ist es erstaunlich gut
      Die Ergebnisse sind auf einem Niveau, das ich auch von Code eines Kollegen ohne Zögern annehmen würde
      Natürlich lese ich alles Zeile für Zeile und ändere noch Dinge, aber diese Änderungen sind ungefähr auf dem Niveau dessen, was ich ohnehin in einem normalen Code-Review tun würde
      Ich messe Produktivität nicht in Zahlen, aber dass ich jetzt Aufgaben angehe, die ich seit Jahren vor mir herschiebe, sagt schon einiges
      Besonders stark ist es bei langweiligen Aufgaben wie 100 Markdown-Dateien in 5 JSON-Dateien umzuwandeln und den einlesenden Code gleich mit zu aktualisieren
    • Wenn Leute sagen, Claude Code sei inzwischen praktisch unbenutzbar, glaube ich ihnen das schon, aber ich verstehe es nicht wirklich
      Es ist fehlerhafte und oft buggy Software, und trotzdem in der Praxis sehr effektiv
      Eines der seltsamsten Dinge an AI ist für mich, wie extrem unterschiedlich Menschen sie erleben
    • Viel hängt wohl davon ab, ob der Code von anderen reviewed wird, ob Code-Reviews früher schon schwer waren und wie wichtig einem das ist, was Kollegen unter code quality verstehen
      Wichtig ist auch, ob man viel operativen Kram macht und ob man langlebigen Produktiv-Code betreut
      Meine Hypothese ist, dass dieses Tool auf einfachen Mustern gut funktioniert und auch komplexe Aufgaben bewältigen kann, aber beim Erfinden neuer Muster ziemlich schwach ist
      Lässt man es unbeaufsichtigt, erfindet es schnell gefährliche neue Muster und richtet Schaden an
      Deshalb schreibe ich das, was Claude liefert, recht oft komplett um
      Manchmal trete ich sogar in ein Wettrennen mit dem Roboter und bin schneller fertig
      Natürlich habe ich einen Vorteil, weil ich schon weiß, was ich will, aber ich finde, die Kosten des Herumfeilens werden hier unterschätzt
      Sowohl die futzing fraction als auch the peril of laziness lost treffen das ganz gut, und manchmal nervt mich schon die Art, wie die Maschine sich übermäßig bemüht
      Ich verstehe nicht, warum sie drei Dinge machen will, wenn sie nur eines tun soll
      Selbst wenn sie es nach einer Korrektur wieder passend macht, muss ich trotzdem erneut denselben Ablauf durchgehen wie mit Kollegen: „Mach nicht A, B und C, sondern nur A“
      Auch Testgenerierung ist heikel: Es kann gut Tests schreiben, wenn man ihm die Richtung vorgibt, aber sobald man Kreativität zulässt, produziert es zu viele nutzlose Tests wie foo + bar == bar + foo
      Man muss den Nutzen der Tests ständig kritisch hinterfragen, damit die Feedback-Schleife gesund bleibt
      In letzter Zeit ist es oft eher dafür nützlich, alle nötigen Imports in einem Rutsch zusammenzuziehen als für die Tests selbst
      Wenn diese Maschinen uns Arbeit abnehmen sollen, müsste dadurch der durchschnittliche Code eigentlich besser werden
      Aber viele nutzen sie eher nach dem Motto „landet meist irgendwo im Durchschnitt“, und je nach Arbeitsweise kann das den Durchschnitt sogar senken
    • Bei mir dasselbe Gefühl
      Ich mache diesen Job seit 28 Jahren, und in bezahlter Arbeitszeit selbst Code für Business-Apps zu schreiben, passt für mich inzwischen weder wirtschaftlich noch im wohlwollenden Sinn besonders gut

  • Umgekehrt habe ich bei Coding-Agenten oft das Gefühl, dass sie vorhandenen Code viel mutiger ändern müssten, um neue Anforderungen sauber umzusetzen, stattdessen aber die Erhaltung des bestehenden Codes zu stark priorisieren
    Am Ende geht es wohl darum, wie stark man bestehenden Code verfestigen will
    Bei einer großen Produktionsanwendung, die seit Jahrzehnten läuft, ist minimale Änderung sicher richtig, aber bei einem experimentellen Projekt, das erst vor drei Tagen entstanden ist, sollte man es eher verbessern als nur konservieren
    Letztlich müssen sie wohl lernen, die Intensität je nach Projektkontext selbst anzupassen

    • Dieser Trade-off ist kontextabhängig, also kann ein Agent nicht einfach ein Projekt überfliegen und immer richtig entscheiden
      Selbst innerhalb desselben Projekts gibt es pro PR Bereiche, die man frei umbauen darf, und andere, die man fix halten will, um Diff und Testumfang klein zu halten
      Deshalb erkläre ich im Voraus, welche Teile wie aggressiv verändert werden dürfen, aber die Ergebnisse sind uneinheitlich
      Meist kippt es in Richtung minimaler Diff, was dann oft Duplikation erzeugt oder Abstraktionen gewaltsam verbiegt
      Wenn jemand eine Methode kennt, die besser funktioniert, würde ich sie auch gern hören
    • Damit der Agent gelegentlich wirklich selbst nachdenkt, habe ich das Gefühl, dass man erst ziemlich viel Code und Markdown löschen muss
      Selbst wenn ich ihm Refactoring oder breiteres Neudenken auftrage, sind die Resultate eher schwach
      Deshalb lasse ich ihn Markdown aufräumen, in dem schon zu viel Design festgeschrieben ist, entferne technische Details oder zentrale Implementierungen und Interfaces aus dem Source und lasse eine neue Session das Design erneut ausarbeiten
      Danach stelle ich das Gelöschte wieder her und gleiche es mit einer weniger naiven Session ab
      Die Pfadabhängigkeit ist dafür viel zu stark, deshalb mache ich diesen Ablauf derzeit manuell, würde dieses Muster aber gern als Skill formalisieren
    • Schon an diesem Tonfall merkt man, dass du Codex benutzt

  • AI versucht oft, Fehlschläge zu verbergen, indem sie Exceptions verschluckt und Dummy-Werte zurückgibt oder nur eine einzige Meldung hinterlässt, die zwischen allerlei irrelevanten Logs untergeht
    Auch Logs selbst sind oft zu stark komprimiert, sodass genau die entscheidenden Daten fürs Debugging fehlen
    Vermutlich liegt das daran, dass das System darauf trainiert wurde, das Bewertungssystem auszutricksen
    Wenn eine Exception offen hochgeht, ist das ein klarer Fehler und wird bestraft, aber wenn man das Problem versteckt, sieht es manchmal wie ein Erfolg aus
    Ich frage mich, wie sich das in normalen Q&A-Situationen zeigt
    Vielleicht versucht das Modell einfach, nur gerade so plausibel zu klingen, dass der Nutzer überzeugt ist und wieder geht
    Ein Muster, das ich oft sehe, ist etwas wie „Das ist nicht X, sondern Y“, denn solche Dichotomien verhindern, dass man andere Möglichkeiten in Betracht zieht
    Häufig hängen Antworten am Ende auch noch einen Aktionsplan an; das wirkt auf mich wie die Verkaufstechnik assumptive close, also weniger wie eine bessere Antwort als wie ein Versuch, den Leser erst zur Zustimmung zu bewegen und ihn dann das Ergebnis ausmalen zu lassen

    • AI-Verhalten ist ziemlich gut vorhersagbar, wenn man es so betrachtet, dass sie die Zielmetrik irgendwie austrickst
      Genau so sieht eben Hill-Climbing auf eine Metrik aus
      Es wirkt wie eine Form von A/B-Enshittification, nur in ein uninterpretierbar extremes Ausmaß getrieben
      Solange auf menschliches Feedback hin trainiert wird, wird zwangsläufig jedes Teil jeder Antwort darauf ausgerichtet sein, den Bewerter zu umgehen und zufriedenzustellen

  • Mit AI etwas wirklich gut zu bauen ist arbeitsintensiver, als es zunächst scheint
    Auf Anweisung produziert sie oft etwas ziemlich Plausibles, kann aber nicht einmal erkennen, dass sie etwas nicht weiß
    Besonders gefährlich wird das, wenn AI dabei autoritativ klingt
    Deshalb ist es nicht leicht, Dinge aus mehreren Blickwinkeln zu verifizieren und die Korrektheit sicherzustellen
    Es wird interessant sein zu sehen, wie sich das mit der Zeit verändert

    • Stimme voll zu
      Gleichzeitig fühlen sich solche Beiträge und auch die Kommentare hier wie eine Momentaufnahme an
      Das Entwicklungstempo in der Branche ist so hoch, dass Coding-Modelle schon jetzt deutlich besser sind als noch vor 9 Monaten
      Wann immer ich Beschwerden über AI-Fähigkeiten lese, denke ich innerlich zwar nicht vorwurfsvoll, aber doch immer: „noch“
    • Inzwischen verbringe ich mehr Zeit damit, einen AI-Kontext einen anderen AI-Kontext reviewen zu lassen, als selbst direkt etwas mit AI zu bauen
      Ich lasse sie gegenseitig ihre Ergebnisse prüfen
      Der Vorteil ist aber, dass das meiste asynchron läuft und ich in der Zwischenzeit andere Dinge tun kann
    • Wenn ich nicht einmal weiß, was ich nicht weiß, wie sollte ich dann etwas Besseres bauen als einen Coding-Agenten?
      Deshalb habe ich bei manchen Projekten zunächst mit einem Agenten einen Prototyp gebaut, dabei gelernt, dann das Design aufgeschrieben und anschließend noch einmal von vorn begonnen
      Danach wusste ich besser, wo ich tiefer einsteigen muss
    • Genau. Bis ungefähr zum 80-%-Punkt bringt es einen meist ziemlich gut
      Was die verbleibenden 20 % sind, hängt dann letztlich von der Art des Problems ab

  • Hier geht es um übermäßiges Bearbeiten von Code, aber Agenten tun noch weit mehr
    Sie fassen mehrere Dateien an, führen Tests aus, deployen und machen sogar Smoke-Tests, und all das verschwindet hinter einer Abstraktionsschicht
    Einerseits ist das beeindruckend, andererseits sorgt es für erhebliche Unruhe
    Erstens verstehe ich nicht wirklich, was intern eigentlich passiert
    Es ist verführerisch einfach, ein vom Agenten zusammengesetztes Skript einfach zu genehmigen und laufen zu lassen
    Dabei habe ich schon einmal eine DB zerschossen, weil der Agent selbst meinte, richtig zu liegen, und ich habe ihn auch schon dabei gestoppt, AWS-Credentials an ein Deployment-Ziel zu schicken, an das sie niemals gesendet werden dürften
    Zweitens lerne ich dabei nichts
    Schon die kognitive Last, einen simplen Docker-Befehl selbst zusammenzubauen, fühlt sich höher an, sodass ich immer wieder auf AI als Krücke zurückgreife

    • Ich verstehe nicht, warum man ein LLM ans Steuer lässt
      Auto-Approve sollte man nicht einschalten, und jeden Befehl, den der Agent ausführt, sollte man selbst bestätigen
      Man sollte ihm auch keine Design- oder Architekturentscheidungen überlassen, sondern als Mensch festlegen, wie gebaut wird, und der Blechdose klare Anweisungen geben
      Kein Witz: Wenn man AI wie ein Werkzeug behandelt, kann man sie deutlich besser nutzen
      Vielleicht keine 10-fache Produktivität, aber wenigstens behält man dabei das Verständnis für den Code
    • Bei Credentials sehe ich das so
      An Tag 1 geht es extrem vorsichtig mit Sicherheit um, erklärt, warum .env in .gitignore gehört, und belehrt mich sogar darüber, dass ich Credentials nicht weitergeben und Änderungen daran selbst vornehmen soll
      Wenn ich an Tag 2 dasselbe erneut verlange, hat es diese Regeln oder Einstellungen plötzlich vergessen, durchsucht die ganze Platte, liest .env und andere Dateien, versteht, dass es Tokens in der Hand hat, und baut dann sogar eigenständig einen curl-Befehl zum Testen
      Am ersten Tag wirkt es wie ein Security-Experte, am nächsten wie weniger als ein durchschnittlicher Praktikant
    • Ich nutze es faktisch in drei Modi
      1. Kernanwendung: Ich spezifiziere, implementiere und teste alles selbst und lasse nur das abschließende Aufräumen von AI machen
      2. Funktionen lässt AI schreiben und die Teststruktur anlegen, aber die Funktionen schreibe ich oft neu
        Das produziert zwar oft unerwünschtes Verhalten oder übertriebene Implementierung, ist aber nützlich für Boilerplate-Entfernung
      3. Experimenteller Code oder alles, was jederzeit weggeworfen werden kann, darf AI komplett übernehmen
        In solchen Bereichen lösche ich am Ende tatsächlich etwa 70 % wieder
        Dafür darf AI Bereiche aus 1) und 2) nicht anfassen
        Natürlich braucht man eine Architektur, die diese Trennung ermöglicht, aber so funktioniert es für mich ziemlich gut
    • Das ist eigentlich ein recht einfaches Problem
      Man gibt dem LLM einfach keine Produktiv-Credentials
      Wenn sich etwas lokal oder in Staging/Dev nicht reproduzieren lässt, muss die Deployment-Infrastruktur produktionsnäher werden, und wenn sich Rechte nicht ausreichend nach Umgebungen trennen lassen, muss zuerst das Berechtigungssystem verbessert werden
      Ich halte mich an dieses Prinzip und habe die von dir beschriebenen Probleme deshalb fast nie erlebt
      Für Diagnosen würde ich eventuell kurzzeitig Read-only-Credentials geben, aber selbst dann nur sehr kurzlebige Tokens, falls doch etwas abfließt
    • Normalerweise reviewe ich allen von Claude geschriebenen Code, und meinen eigenen Code lasse ich anschließend auch noch einmal von Claude reviewen
      Daher habe ich meistens schon im Blick, was passiert
      Claude trifft gelegentlich seltsame oder unkonventionelle Entscheidungen
      Allerdings gibt es in großen Codebases, an denen Teams arbeiten, ohnehin viele Bereiche hinter Abstraktionen, die man von Haus aus nicht vollständig versteht, oft auch weil sie von Leuten stammen, die längst nicht mehr im Unternehmen sind

  • Eine Weisheit, die früher oft gelehrt, in der Praxis aber kaum befolgt wurde, lautete: Beim Arbeiten refaktorieren
    Gemeint war, dass man einen Bereich, den man ohnehin anfasst, dabei gleich aufräumt und technische Schulden abbaut
    In der Realität hat das selten funktioniert, und jetzt, wo LLMs das tatsächlich zu tun beginnen, spürt man die Nebenwirkungen

    • Wenn ein Modell neuen Code schreibt, der dasselbe tut wie bestehende Logik, ist das kein Refactoring
      Manchmal erstellt es etwas neu, obwohl die passende Funktion direkt daneben existiert
      Noch schlimmer ist, wenn es eine bestehende Funktion verändert, so tut, als bliebe das Verhalten gleich, und damit andere Aufrufer kaputtmacht
      Am schlimmsten ist es, wenn es Zustände zwischen Klassen verändert, ohne die Nebenwirkungen zu verstehen, und so Deadlocks oder ganz gewöhnliche Bugs erzeugt
    • Auch wenn man unterwegs irgendwo etwas „gleich mit anfassen“ will, ist das oft gar keine Verbesserung
      Für mich ist das weniger Refactoring als ein weiterer Zug am Einarmigen Banditen
    • Ich habe heute wieder etwas Zeit genau daran verloren
      Mein eigentliches Problem war, dass die Qualität des Refactorings des Agenten schlecht war
      Ich wollte nur, dass er mit solchen Änderungen aufhört, damit ich expliziter anweisen kann, was wie angepasst werden soll
    • Ganz so einfach ist es nicht
      In vielen Fällen sind bestehende Abstraktionen gut genug, dass man darauf Bugs verfolgen oder Funktionen erweitern kann
      Manchmal steht man aber an dem Punkt, an dem man entscheiden muss, ob man die bestehende Implementierung mühsam umgeht oder neu entwirft
      Mit LLMs verschwimmt dann, wie man das überhaupt neu bewerten soll oder ob es diese Neubewertung überhaupt braucht
      Außerdem verschwinden solche Entscheidungen leicht im Verborgenen und sind für Nutzer kaum sichtbar
    • Das ist genau der Teil, der mich wirklich interessiert
      Vielleicht sind solche Änderungen ja nützlich, deshalb würde ich gern mehr Beispiele sehen
      Ich halte zwar nicht viel von der Metrik „cognitive complexity“, aber es ist trotzdem etwas interessant, dass solche Änderungen sie ziemlich konsistent erhöhen

  • Ich habe bei Claude Code oder Codex schon länger kein übermäßiges Bearbeiten mehr gesehen und fragte mich deshalb, welche Prompts in dieser Studie verwendet wurden
    Vermutlich stehen sie hier, die letzte Änderung ist vor 8 Monaten erfolgt
    https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py

    • Genau das ist heute erst wieder passiert
      GPT-5.4 hat statt der von mir gewünschten 10 zusätzlichen Zeilen gleich 50 Zeilen umgeschrieben, weil das angeblich sauberer sei
      Dabei wäre es nur eine mechanische Ergänzung gewesen, bei der man im bestehenden Code nur die Variablennamen anpassen und etwas Ähnliches einfügen musste
      Noch absurder war, dass es anfangs nicht einmal die von mir gewünschte Funktion eingebaut hat
      Over-editing ist ganz sicher kein vergangenes Problem, und in meinem Fall passierte es, weil ich vergessen hatte, Thinking herunterzustellen, und es auf xhigh thinking lief
    • Geht mir ähnlich
      Für mich las sich das wie ein Problem aus der frühen Agentenzeit

  • Dieser Beitrag ist ziemlich solide
    LLMs sind sowohl in Prosa als auch in Code übermäßig weitschweifig, und der Hauptgrund dafür ist meiner Meinung nach die Art ihres Trainings
    Cross-Entropy-Loss begünstigt Sätze mit garden-path-ähnlicher Struktur
    Dinge, die ein Mensch in einem Satz oder sogar in wenigen Wörtern sagen würde, werden dadurch zu einem ganzen Absatz ausgewalzt
    Lange Sätze sind statistisch gesehen der weniger überraschende, also Perplexity-ärmere Pfad

  • Ich habe bei diesem Problem auch gemischte Gefühle
    Meistens übertreibt es, und ich muss 30 Minuten damit verbringen, das wieder geradezuziehen, daher stimme ich der Einschätzung zu
    Andererseits übersieht es manchmal auch umfassendere Änderungen
    Vermutlich liegt das an Kontextgrenzen, weshalb ich angefangen habe, das Tool strenger zu führen
    Trotzdem habe ich noch nicht das gewünschte Maß an Kontrolle erreicht

  • Das wirkt auf mich wie ein Abdruck der Trainingsdaten
    In SFT- und Preference-Daten gibt es unzählige Beispiele von „hier ist die sauberere überarbeitete Datei“, aber nur wenige Beispiele wie „genau 3 Zeilen Diff“
    Deshalb hat das Modell gelernt, dass größere und stärker polierte Ausgaben gewinnen
    Mit Prompts lässt sich das bis zu einem gewissen Grad steuern, aber letztlich kämpft man gegen eine starke Voreinstellung an