← Neueste Arbeiten
🤖 machine learning

What Context Does a Coding Agent Actually Need to Act?

Diese Arbeit zeigt auf, dass für Coding-Agenten, die Code editieren, der essenzielle Kontext strikt auf die spezifischen zu modifizierenden Dateien beschränkt ist, da natürlichsprachliche Zusammenfassungen und der umgebende Dateiinhalt im Vergleich zum Quellcode selbst vernachlässigbar wenig zur Problemlösung beitragen, während sie gleichzeitig eine signifikante Rauschuntergrenze in Benchmark-Ergebnissen offenlegt, die durch nicht-deterministische API-Inferenz verursacht wird.

Ursprüngliche Autoren: Brian Sam-Bodden

Veröffentlicht 2026-07-14✓ Author reviewed
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

Ursprüngliche Autoren: Brian Sam-Bodden

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, einen tropfenden Wasserhahn in einem riesigen, 100-stöckigen Wolkenkratzer zu reparieren. Sie müssen nicht die Baupläne des gesamten Gebäudes, das Menü der Kantine oder die Sicherheitsprotokolle lesen, um den Schraubenschlüssel zu finden. Sie müssen nur genau wissen, welches Rohr tropft, und das unmittelbare Umfeld sehen.

Das ist die überraschende Lektion aus dieser neuen Studie über „Coding Agents“ – KI-Bots, die Software schreiben und reparieren. Lange Zeit nahm die Tech-Welt an, dass diese Bots das gesamte Code-Repository eines Projekts (manchmal Millionen von Zeilen) in ihren „Geist“ aufsaugen müssten, um ihre Aufgabe zu erfüllen. Die Denkweise war: „Mehr Kontext ist immer besser.“

Aber dieses Paper sagt: Hör auf, das Gehirn vollzustopfen. Es stellt sich heraus, dass die KI für den eigentlichen Akt des Codens fast nichts braucht außer den spezifischen Zeilen, die sie gleich ändern wird.

Das „Finden“ vs. das „Handeln“

Die Forscher unterteilten das Problem in zwei Teile:

  1. Das Finden: Das Auffinden des fehlerhaften Codes.
  2. Das Handeln: Das eigentliche Reparieren, sobald man es gefunden hat.

Um dies zu testen, verwendeten sie eine „magische Karte“ (ein Oracle), um der KI genau zu sagen, wo der fehlerhafte Code lag. Das bedeutete, die KI musste nicht raten, wo sie suchen sollte; sie musste sich nur darauf konzentrieren, wie sie den Fehler behebt. Sie gaben der KI dann verschiedene „Ansichten“ dieses Codes, um zu sehen, was am besten funktioniert.

Die große Enttäuschung: Zusammenfassungen funktionieren nicht

Eine populäre Idee war: „Lassen Sie uns der KI einfach eine natürliche Sprachzusammenfassung des Codes geben, wie einen Klappentext eines Buches.“

  • Der Test: Sie baten die KI, knifflige Fragen darüber zu beantworten, wie der Code sich verhält, indem sie entweder den vollständigen Quellcode oder eine von einer extrem intelligenten KI geschriebene Zusammenfassung (einem „Frontier Model“) nutzte.
  • Das Ergebnis: Der vollständige Quellcode beantwortete 25 von 45 Fragen richtig. Die Zusammenfassungen? Sie kamen nur auf 4 von 45 richtigen Antworten.
  • Der Twist: Es spielte keine Rolle, ob die Zusammenfassung von der klügsten KI der Welt oder einem winzigen, einfachen Modell geschrieben wurde. Beide scheiterten gleichermaßen. Das Problem war nicht der Schreiber; das Problem war das Format. Eine Zusammenfassung kann einfach nicht die spezifischen „Verhaltensdetails“ transportieren, die zur Behebung eines Bugs nötig sind. Es ist, als würde man versuchen, einen Automotor zu reparieren, indem man eine Reisebroschüre über das Auto liest; die Broschüre ist nett, aber sie sagt einem nicht, welche Schraube locker ist.

Das „Skelett“ vs. der „ganze Körper“

Als Nächstes testeten sie, ob die KI den vollen, „fleischigen“ Code brauchte oder nur das „Skelett“ (die Struktur, wie Funktionsnamen und Signaturen).

  • Das Setup: Sie nahmen 70 reale Programmierprobleme. Für einige gaben sie der KI die vollständigen Dateien. Für andere gaben sie ihr nur das „Skelett“ (UML-Diagramme und Signaturen) oder eine „Keep/Drop“-Version (bei der nur die wesentlichen Teile behalten und der Rest gelöscht wurde).
  • Das Ergebnis: Die „Skelett“- und „Keep/Drop“-Versionen lösten genauso viele Probleme wie die vollständigen Dateien. Tatsächlich löste die „Keep/Drop“-Methode etwas mehr (25 von 70) als die vollständigen Dateien (19 von 70), obwohl der Unterschied gering genug war, um auch bloß Glück zu sein.
  • Die Kosten: Hier ist der entscheidende Punkt. Das Lösen eines Problems mit den vollständigen Dateien kostete die KI 94.000 Token (eine Texteinheit). Das Lösen mit der komprimierten „Keep/Drop“-Methode kostete nur 19.000 Token. Das ist eine massive Ersparnis – etwa 3- bis 3,7-mal günstiger – bei gleichbleibender Leistung.

Die Warnung vor dem „Rauschen“

Die Forscher fanden auch etwas Seltsames und Wichtiges heraus: Selbst wenn sie exakt denselben Test mit exakt denselben Einstellungen durchführten, lieferte die KI manchmal unterschiedliche Antworten. Etwa 9 % der Zeit kehrte sich das Ergebnis zwischen den Durchläufen um. Das bedeutet, wenn man einen winzigen Unterschied zwischen zwei Methoden sieht (wie eine Verbesserung von 2 %), könnte dies einfach nur zufälliges Rauschen sein und kein echter Durchbruch.

Das Fazste

Das Paper kommt zu dem Schluss, dass für die spezifische Aufgabe des Code-Reparierens weniger mehr ist.

  • Was funktioniert: Der KI genau die Zeilen Code zu geben, die sie bearbeiten muss, reduziert auf das Wesentliche.
  • Was nicht funktioniert: Die KI mit Zusammenfassungen, vollständigen Datei-Historien oder komplexen Strukturdiagrammen zu überfluten.
  • Das Urteil: Das „Signal“ lebt im Code selbst, nicht in der Geschichte, die wir über den Code erzählen. Indem wir den unnötigen Ballast abschneiden, können wir Bugs für einen Bruchteil der Kosten beheben, ohne den ganzen Wolkenkratzer lesen zu müssen, um einen einzigen tropfenden Wasserhahn zu reparieren.

Die Autoren betonen sehr vorsichtig, dass dies für „Single-Shot“-Fixes gilt (bei denen die KI nur einmal versucht, den Fehler zu beheben, und nicht die Möglichkeit hat, erneut nachzulesen oder um Hilfe zu bitten). Aber für diesen spezifischen, hochsensiblen Moment der Bearbeitung ist die Datenlage klar: Man braucht nicht die ganze Bibliothek; man braucht nur die richtige Seite.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →