🤖 AI

Can Coding Agents Solve Repository-Level Issues with Rendered Code? An Exploratory Study of Visual Representations

Diese Studie bewertet den Einsatz von gerenderten Code-Bildern als Strategie zur Token-Kompression für Repository-basierte Coding-Agenten und stellt fest, dass dies zwar die Prompt-Kosten effektiv reduziert und die Reparaturgenauigkeit beibehält, die Vorteile jedoch konditional sind und durch die Fähigkeiten des zugrunde liegenden Modells sowie die spezifischen Phasen des Reparatur-Workflows begrenzt werden.

Ursprüngliche Autoren: Weijie Liang, Yuanfeng Song, Xing Chen, Caleb Chen Cao, Sirui Han, Yike Guo

Veröffentlicht 2026-08-11

📖 7 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Weijie Liang, Yuanfeng Song, Xing Chen, Caleb Chen Cao, Sirui Han, Yike Guo

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 oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich eine Welt vor, in der Computer wie unglaublich schnelle, superintelligente Bibliothekare sind, die in der Sekunde Millionen von Büchern lesen können. Diese „KI-Agenten“ werden darauf trainiert, fehlerhaften Code in massiven Softwareprojekten zu reparieren – sie fungieren als digitale Mechaniker des Internets. Aber es gibt einen Haken: Diese Bibliothekare sind überfordert, wenn man ihnen eine ganze Bibliothek auf einmal überreicht. Sie müssen den Text Zeile für Zeile lesen, und je mehr Text sie verarbeiten müssen, desto mehr Zeit und Geld kostet es. Kürzlich entdeckten Wissenschaftler einen Trick: Anstatt dem Bibliothekaren eine Textwand zu geben, kann man ein Foto des Codes machen. Es ist, als würde man einen langen Roman in ein einziges, dichtes Bild verwandelt. Diese „visuelle Kompression“ spart Platz, aber hilft sie dem Bibliothekaren tatsächlich, das Buch zu reparieren, oder macht sie das Bild nur zu unscharf zum Lesen?

Diese Frage steht im Zentrum einer neuen Studie von Forschern der Hong Kong University of Science and Technology und ByteDance. Sie wollten wissen, ob das Umwandeln von Code in Bilder ein magischer Shortcut für KI-Agenten ist, die Software reparieren sollen, oder ob es nur ein netter Trick ist, der an seine Grenzen stößt, wenn die Arbeit ernst wird. Sie ließen die KI nicht einfach nur ein Bild „betrachten“; sie brachten die KI in ein realistisches Szenario, in dem sie durch ein unordentliches digitales Lagerhaus suchen, den defekten Teil finden, ihn reparieren und beweisen musste, dass es funktionierte. Ihre Ergebnisse legen nahe, dass die Verwendung von Bildern zwar viel Geld spart, die KI dadurch aber nicht klüger wird, und dass sie manchmal verwirrt ist, wenn man das Foto zu stark zusammendrückt.

Das Experiment: Von Text zu Pixeln

Um dies zu testen, bauten die Forscher einen digitalen Hindernisparcours auf, der auf einem berühmten Benchmark namens SWE-bench Verified basiert. Stellen Sie sich dies als ein riesiges, echtes Videospiel-Level vor, in dem die KI tatsächliche Bugs in echten Softwareprojekten beheben muss. Der KI-Agent musste drei Hauptaufgaben bewältigen:

Suchen (Search): Die richtige Datei in einer massiven Codebasis finden (wie das Finden einer bestimmten Nadel im Heuhaufen).
Editieren (Edit): Den Code ändern, um den Bug zu beheben.
Verifizieren (Verify): Tests durchführen, um sicherzustellen, dass die Reparatur tatsächlich funktioniert hat und nichts anderes beschädigt wurde.

Die Forscher verglichen zwei Wege, um der KI die benötigten „Hinweise“ zu geben:

Der Text-Weg: Die KI liest den Code Zeile für Zeile, genau wie ein Mensch, der ein Buch liest.
Der visuelle Weg: Der Code wird in ein Bild umgewandelt (ein gerendertes Bildschirmfoto), und die KI betrachtet das Bild, um den Code zu verstehen.

Dies testeten sie mit verschiedenen Ebenen der „Kompression“. Stellen Sie sich vor, Sie machen ein Foto von einer Textseite. Sie können das Foto kleiner machen (das Bild komprimieren), um Platz zu sparen. Die Forscher versuchten, die Fotos immer kleiner zu machen (Kompressionsraten von 1, 3, 5 und 7), um zu sehen, wie viel Platz sie sparen konnten, bevor die KI aufhörte, den Code zu verstehen.

Die Ergebnisse: Ein gemischtes Bild aus Ersparnissen und Schwierigkeiten

Die Studie lieferte ein faszinierendes, etwas kompliziertes Bild. Dies fanden sie heraus:

1. Der Geldsparer (Aber kein Zauberstab)
Das Umwandeln von Code in Bilder spart definitiv Geld. Die Forscher fanden heraus, dass die Verwendung visueller Darstellungen konsistent die Anzahl der „Tokens“ (die Dateneinheiten, die die KI verarbeitet) reduzierte, die die KI lesen musste. In einigen Fällen sparte dies bis zu 2,8-mal so viele Daten im Vergleich zum Lesen von reinem Text. Diese Ersparnis verlief jedoch nicht geradlinig. Man könnte denken, wenn man das Bild um den Faktor 7 komprimiert, spart man 7-mal so viel Geld. Aber so funktioniert das nicht. Die Ersparnis erreichte sehr schnell einen „Boden“. Für kleine Code-Abschnitte schrumpfte die Bildgröße kaum noch, egal wie sehr man versuchte, sie zu komprimieren, da das Bild immer noch groß genug sein muss, um lesbar zu bleiben. Es ist, als würde man versuchen, eine Briefmarke zu schrumpfen; irgendwann kann man sie nicht mehr kleiner machen, ohne die Briefmarke unlesbar zu machen.

2. Die Genauigkeitsfalle
Die wichtigste Erkenntnis war, dass Geldsparen die KI nicht klüger gemacht hat. Die Fähigkeit der KI, die Bugs tatsächlich zu beheben (ihre Genauigkeit), blieb etwa gleich, egal ob sie Text las oder Bilder betrachtete.

Wenn die KI die gesamte Aufgabe von Grund auf erledigen musste (Suchen, Lesen, Fixen), funktionierte die visuelle Methode genauso gut wie die Textmethode, aber kostengünstiger.
Wenn die Forscher die KI jedoch dazu zwangen, die Bilder zu stark zu komprimieren (aggressive Kompression), begann die KI mehr Fehler zu machen. Die Bilder wurden zu unscharf oder zu gedrängt, und die KI konnte die Details, die sie zur Behebung des Codes benötigte, nicht mehr erkennen.

3. Das „Suchen“ vs. „Fixen“-Problem
Die Forscher unterteilten die Aufgabe der KI in zwei verschiedene Phasen, um genau zu sehen, wo der visuelle Trick half:

Der Locator (Der Sucher): Dieser Teil der KI sucht nach dem Ort, an dem der Bug liegt. Hier waren visuelle Bilder sehr hilfreich. Da die KI viel rohen Code lesen musste, um die Nadel im Heuhaufen zu finden, sparte das Umwandeln dieses Codes in ein kompaktes Bild eine enorme Menge an Daten.
Der Editor (Der Fixer): Sobald der Bug gefunden wurde, muss die KI den Code tatsächlich ändern und Tests durchführen. Hier half der visuelle Trick nicht viel. Die Forscher fanden heraus, dass selbst wenn die KI genau wusste, wo der Bug lag, der schwierigste Teil das „Versuch und Irrtum“ bei der Behebung war. Die KI musste editieren, testen, scheitern, erneut editieren und erneut testen. Dieser Prozess ist voller Hin-und-Her-Gespräche und Tests, wovon die Kompression des ursprünglichen Code-Bildes nicht viel profitiert. Tatsächlich wurde der Aufwand für diese „Fixing“-Schritte durch das Testen und Editieren dominiert, nicht durch das Lesen.

Das Urteil: Ein nützliches Werkzeug, aber keine Allheilmittel

Können also Coding-Agenten Probleme auf Repository-Ebene mit gerendertem Code lösen? Ja, aber unter Bedingungen.

Die Studie legt nahe, dass das Umwandeln von Code in Bilder eine praktikable Strategie ist, um Kosten zu senken, insbesondere wenn die KI viel Zeit damit verbringt, lediglich riesige Mengen an Text zu lesen und zu suchen. Es ist, als würde man dem Bibliothekaren ein Foto des Buchindexes geben, anstatt das ganze Buch, um eine Seitenzahl zu finden. Es ist schneller und billiger.

Es ist jedoch keine magische Lösung, die die KI unendlich klüger macht.

Es behebt nicht die zugrunde liegende Intelligenz der KI; wenn eine KI schlecht darin ist, Bugs zu fixen, wird sie auch dann noch schlecht darin sein, wenn sie ein Bild sieht.
Es hat eine Grenze. Wenn man versucht, das Bild zu stark zusammenzustauchen, um noch mehr Geld zu sparen, wird die KI verwirrt und die Genauigkeit sinkt.
Es hilft am meisten in der „Suchphase“. Sob wenn die KI weiß, wo das Problem liegt, wird die eigentliche Arbeit des Reparierens (Editieren und Testen) zum Flaschenhals, und die visuelle Kompression hilft dort nicht mehr viel.

Kurz gesagt, die Forscher kommen zu dem Schluss, dass visueller Code ein großartiges „bedingtes“ Werkzeug ist. Es ist eine kluge Art, Geld bei der mühsamen, schweren Arbeit des Codelesens zu sparen, aber es ersetzt nicht die Notwendigkeit eines klugen, sorgfältigen Editors, der die eigentliche Reparaturarbeit leistet. Die Zukunft der KI-Programmierung besteht nicht nur darin, den Input kleiner zu machen; es geht darum, zu wissen, wann man ein Bild verwendet und wann man beim Text bleiben sollte.

Technisches Resümee: Können Coding-Agenten Repository-weite Probleme mit gerendertem Code lösen?

Problemstellung

Jüngste Fortschritte bei Long-Context-Modellen und agentischen Systemen haben den rechnerischen Engpass bei der Verarbeitung großer Mengen textueller Informationen verdeutlicht. Während die vorangegangene Forschung untersucht hat, wie textuelle Informationen in visuelle Formen umgewandelt werden können (z. B. das Rendern von Code als Bilder), um den Kontext für das statische Verständnis von Code zu komprimieren, bleibt eine kritische Lücke bestehen: Es ist unklar, ob diese visuellen Repräsentationen als effektiver operativer Kontext für das agentische Programmieren dienen können.

Im Gegensatz zu Aufgaben des statischen Verständnisses, bei denen ein Modell Code passiv „liest“, müssen agentische Repair-Systeme auf Repository-Ebene aktiv Dateisysteme navigieren, relevante Regionen lokalisieren, Quelldateien bearbeiten, Tests ausführen und Hypothesen iterativ verfeinern. Die zentrale Forschungsfrage ist, ob das Rendern von Code als Bild die Token-Kosten senken und die Genauigkeit innerhalb dieser komplexen, interaktiven Repository-Workflows aufrecht erhalten kann, und wo die Vorteile einer solchen Kompression tatsächlich realisiert werden.

Methodik

Die Autoren führen eine systematische explorative Studie unter Verwendung des SWE-bench Verified Benchmarks durch, wobei sie gerenderten Code über drei verschiedene Agenten-Konfigurationen hinweg evaluieren, um die Effekte der visuellen Modalität von anderen Variablen zu isolieren.

1. Agenten-Konfigurationen

Um die „Attributionsproblematik“ (die Unterscheidung zwischen Modalitätseffekten und Trajektorienvarianz) zu adressieren, führt die Studie eine kontrollierte Progression von Agenten-Designs ein:

Mini SWE-agent (Baseline): Ein standardmäßiger, einstufiger Bash-orientierter Agent, der Repository-Exploration, Code-Lesen, Editieren und Testen verzahnt. Dies repräsentiert den ungesteuerten, nativen Workflow.
Pre-Localized Bash Agent (PLB): Dieser Agent führt vor der Repair-Schleife einen Offline-Durchgang zur strukturierten Lokalisierung durch (unter Verwendung eines statischen Repository-Index und Graphen). Dies entkoppelt die ungesteuerte Exploration von der Repair-Phase, was es ermöglicht, die Vorteile der visuellen Kompression zu messen, wenn der Agent mit einem bereits bekannten Kontext startet.
Locator–Editor Tool Agent (LET): Dieser Agent trennt den Workflow explizit in zwei Phasen:
- Locator: Verwendet strukturierte Tools (Localize, Package, view_code), um relevante Dateien und Symbole zu identifizieren und einen strukturierten Plan festzulegen.
- Editor: Erhält den Plan und konzentriert sich auf das Trial-and-Error-Editieren, Testen und die Verfeinerung des Patches.
- Hinweis: In den visuellen LET-Experimenten wird das Rendering nur auf die Locator-Phase angewendet, um zu testen, ob die visuelle Kompression noch Wert besitzt, sobald strukturierte Informationen bereits die Notwendigkeit des Lesens von Roh-Quelltext reduziert haben.

2. Experimentelles Setup

Backbones: Die Experimente nutzen zwei multimodale Modelle: Qwen3.5 und Kimi-K2.5.
Bedingungen: Die Agenten operieren unter einer Text-Bedingung und vier visuellen Bedingungen mit nominalen Kompressionsraten ( $r \in \{1, 3, 5, 7\}$ ).
Rendering-Pipeline: Ein maßgeschneiderter Renderer bildet Code-Fenster auf Bilder ab, wobei er über diskrete Layout-Konfigurationen (Auflösung, Schriftgröße, Paginierung) sucht, um ein Ziel-Token-Budget einzuhalten und gleichzeitig die Lesbarkeit zu bewahren.
Metriken: Die Evaluierung konzentriert sich auf die End-to-End-Repair-Genauigkeit (pass@1) und den Prompt-Token-Verbrauch.

Zentrale Erkenntnisse

1. Reduktion der Token-Kosten vs. lineare Skalierung

Gerenderter Code reduziert die Prompt-Token-Kosten konsistent im Vergleich zu Roh-Text. Die Einsparungen skalieren jedoch nicht linear mit der nominalen Kompressionsrate ( $r$ ).

Diskrete Kostengrenze: Kleine Code-Fenster erreichen schnell eine visuelle Kostengrenze, da sie unabhängig von $r$ auf dieselbe Rendering-Konfiguration kollabieren.
Abnehmende Grenzerträge: Bei größeren Fenstern liefern höhere Kompressionsraten zwar Einsparungen, jedoch mit abnehmenden Grenzerträgen.
Readability Trade-off: Aggressive Kompression (hohes $r$ ) kann die Lesbarkeit verschlechtern, was zu instabiler Performance oder erhöhtem Token-Verbrauch durch wiederholte Versuche des Lesens führt.

2. Erhalt der Genauigkeit und Stabilität

Allgemeine Stabilität: Über beide PLB- und LET-Konfigurationen hinweg bewahrt gerenderter Code weitgehend die End-to-End-Repair-Genauigkeit im Vergleich zur Text-Baseline.
Instabilität bei hoher Kompression: In der LET-Einstellung verursachte aggressive Kompression (z. B. $r=7$ ) einen spürbaren Abfall der Genauigkeit (auf 60,0 % bei Kimi-K2.5), während PLB stabiler blieb. Dies deutet darauf hin, dass die Lesbarkeit kritischer wird, wenn der Agent für die gesamte Repair-Schleife stark auf visuellem Kontext basiert.

3. Mechanismen des Nutzens

Die Studie identifiziert drei Mechanismen, welche die Nützlichkeit von gerendertem Code prägen:

Verhaltensänderung (Reshaping Behavior): Visuelle Kompression formt das Repair-Verhalten um, indem sie die ungesteuerte Exploration in die frühe Trajektorie komprimiert und spätere Aktionen hin zu einem fokussierten Test–Edit–Repair verschiebt.
Kontextabhängigkeit: Visuelle Kompression ist am vorteilhaftesten, wenn das Lesen des Roh-Quellcodes ein wesentlicher Engpass ist. In der PLB-Einstellung (wo die Exploration strukturiert, aber das Lesen noch roh erfolgt) erzielte die visuelle Kompression die höchsten Token-Reduktionen (bis zu 2,81x).
Grenznutzen-Limits: Sobald strukturierte Repository-Informationen (wie in der LET-Locator-Phase) den Bedarf an Roh-Quelltext-Lesen reduzieren, sinkt der Grenznutzen der visuellen Kompression. In LET verschiebt sich der dominante Kostenfaktor auf die Editor-Phase (Editieren, Testen und Patch-Iterationen), in der die visuelle Kompression nur begrenzten Hebel bietet.

4. Die Rolle von Trial-and-Error

Die Analyse der LET-Dekomposition zeigt, dass Trial-and-Error wichtiger ist als das alleinige Verständnis des Repositories.

Selbst bei präziser Lokalisierung verbraucht die Editor-Phase den Großteil der Tokens (bis zu 83,7 % bei nicht gelösten Aufgaben).
Eine bessere Lokalisierung verbessert die Anfangsbedingungen für den Editor, garantiert aber keinen erfolgreichen Patch. Die finale Lösung wird oft durch die Kosten des Editierens, Testens und Verfeinerung der Patches dominiert – ein Prozess, bei dem die visuelle Kompression nur geringen Einfluss hat.

Bedeutung und Behauptungen

Das Paper positioniert gerenderten Code als einen viablen, aber bedingten Kompressionsmechanismus für realistische Coding-Agenten.

Bedingte Viabilität: Der Vorteil der visuellen Repräsentation ist nicht universell; er hängt stark von der Phase des Workflows ab. Er ist am effektivsten, wenn der Agent aktiv Roh-Quellcode liest, um Probleme zu lokalisieren.
Workflow-Integration: Die zentrale Herausforderung für das Repository-weite Repair besteht nicht nur darin, wie man Code komprimiert, sondern wo man diese Kompression innerhalb des breiteren Edit-Workflows platziert. Sobald der Workflow darauf ausgelegt ist, das direkte Lesen zu minimieren (z. B. durch Offline-Lokalisierung), werden die verbleibenden Kosten durch die iterative Patch-Verfeinerung getrieben, einem Bereich, in dem die visuelle Kompression abnehmende Erträge liefert.
Praktische Implikationen: Für produktionsreife agentische Systeme sollte visuelle Kompression strategisch während der Explorations- und Lokalisierungsphasen eingesetzt werden, statt als pauschaler Ersatz für den gesamten textuellen Kontext zu dienen, insbesondere angesichts der nicht-glatten Kostenoberfläche und der Risiken für die Lesbarkeit bei aggressiver Kompression.

Die Autoren kommen zu dem Schluss, dass die visuelle Modalität zwar einen vielversprechenden Weg zur Token-Effizienz bietet, ihr Erfolg im agentischen Programmieren jedoch durch die spezifischen Mechanismen der Repair-Schleife und die inhärenten Trade-offs zwischen Kompressionsdichte und der Lesbarkeit von Code begrenzt ist.