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

This paper presents an exploratory study investigating whether rendered code—source code converted into visual image representations—can serve as effective operational context for repository-level coding agents, moving beyond prior work that evaluated rendered code only in static code-understanding settings.

The authors identify a practical gap in existing research: "existing studies mostly evaluate rendered code in static understanding settings, where the model is given code to 'read'. Agentic coding is different: real repair agents must search across files, localize relevant regions, edit code, run tests, and revise hypotheses over long interactive trajectories. They note that success in rendered-code understanding does not by itself show that visual representations can serve as effective working context for coding agents."

The paper makes three main contributions:

1. First systematic study of rendered code as operational context for agentic coding: "Prior work has mainly evaluated rendered code as static input for passive code understanding. We move this question into repository-level repair and find that rendered code can substantially reduce token cost, but its realized savings are constrained by code structure and readability, and therefore do not scale linearly with the nominal compression ratio."

2. A controlled evaluation framework: Beyond testing rendered code in mini SWE-agent workflows, the authors design "two controlled agent variants, PLB (Pre-Localized Bash Agent) and LET (Locator-Editor Tool Agent). These configurations progressively decouple repository exploration, localization, source inspection, and editing, allowing us to trace where the effects of rendered code are actually realized."

3. Identification of three mechanisms shaping agentic repair with rendered code: "First, initial context reshapes repair behavior by compressing unguided exploration into the early trajectory and shifting later actions toward focused test–edit repair. Second, visual compression is most useful when raw source reading remains a major cost, and its marginal benefit shrinks once structured repository information has already reduced source-reading demand. Third, downstream trial-and-error matters more than repository understanding alone: even with better localization, final resolution is often dominated by editing, testing, and patch refinement."

The paper identifies three intrinsic properties of the code rendering pipeline that affect cost behavior:

• Property 1 (Discrete realizability): Although the nominal budget varies continuously, the renderer searches over a discrete candidate set Θ. As a result, many nearby budgets collapse to the same rendered layout and hence the same realized cost.

• Property 2 (Piecewise-constant tokenization): "Image-token cost changes only when a rendered image crosses a patch or tile boundary. Once a layout falls into the minimum active token bucket, further changes in resolution may degrade readability without changing token cost."

• Property 3 (Code is visually sparse): Indentation, blank lines, and short statements leave substantial unused space in rendered code, while line-preserving pagination further limits page density.

The single-read rendering study shows that "visual rendering already reduces cost at r=1, suggesting that modality conversion itself provides a denser representation than raw text tokenization. However, increasing the nominal ratio does not produce smooth or proportional savings. For small windows, the visual cost quickly reaches a floor: for example, 10-line windows cost 54.0 tokens for all r≥2. Clearer savings appear only for larger windows, but the need to preserve code structure and readability imposes a practical ceiling, leading to diminishing marginal returns."

The study uses three agent configurations:

1. mini SWE-agent baseline: the official mini SWE-agent v2... runs a single-stage bash-first ReAct loop with the full mix of repository exploration, code reading, editing, and test execution.

2. PLB (Pre-Localized Bash Agent): "keeps the same bash-first interaction style as mini, but prepends an offline pre-localization pass before the online repair loop... The package is computed once per instance, shared across text and visual conditions, and provided as the agent's starting context."

3. LET (Locator-Editor Tool Agent): "adopts a two-stage decoupled design that separates repository exploration from the trial-and-error editing stage... In the locator phase, the agent operates with tools Localize, Package, view code, commit plan... The locator phase ends by emitting a committed plan Π(x)... The editor starts from plan Π(x) and operates with Localize, Package, view code, bash, submit."

The evaluation uses 100 instances sampled from SWE-bench Verified, evaluated under one text condition and four visual conditions indexed by r ∈ 1, 3, 5, 7, across two backbones (Kimi-K2.5 and Qwen3.5), with both normal and wide inspection scopes.

The paper observes that Pre-localization compresses unguided exploration into the early trajectory, allowing later behavior to shift toward focused test–edit repair. In Mini, read and search account for 40.1% and 31.0% of actions, whereas in PLB, the corresponding bash read and bash search shares drop to 19.2% and 16.7%; meanwhile, bash test becomes dominant at 54.8%.

For LET, the locator changes the editor's information boundary, but not its core repair dynamics. Final resolution still depends on whether the editor can effectively use this information within the focused repair loop.

Accuracy is mostly preserved: "Across both backbones, PLB and LET generally remain in the same accuracy band as mini. Since each condition contains 100 tasks, single-digit percentage-point fluctuations should be interpreted as task-level variation rather than a monotonic effect of visual compression. However, aggressive compression can weaken this stability: the main exception appears in the LET setting, where the lowest accuracy drops to 60.0%."

Visual compression is most beneficial when raw source reading remains a major cost: "The largest PLB reductions reach 2.81× on Qwen3.5 and 2.58× on Kimi-K2.5, both under the normal scope. By contrast, the gains are smaller under the wide scope, because broader inspection introduces more context beyond what is needed as repair evidence."

When structured repository information already reduces source-reading demand, visual compression has smaller marginal gains: "Compared with PLB, LET further reduces token usage, showing that structured localization and packaging already make repository navigation cheaper. Relative to mini, its largest reductions reach 2.52× on Qwen3.5 and 2.65× on Kimi-K2.5. However, because the LET text baseline is already compact, visualizing raw code brings smaller and less stable additional gains."

The paper finds that Trial-and-Error Matters More Than Understanding the Repository. Using Kimi-K2.5 as a representative case: "the locator accounts for only a small fraction of the total cost, while the editor consumes most of the tokens. This imbalance becomes even stronger on non-resolved tasks, where the editor accounts for 83.7% of the total token cost."

The analysis shows that "localization mainly helps by increasing the chance that a task enters the low-cost 'high-evidence and resolved' regime. In difficult cases, the remaining cost is driven by repeated verification, error correction, and patch refinement within the patch–test loop."

The paper concludes: "rendered code is a viable compression mechanism for coding agents, but its benefit is conditional on whether raw source reading remains a real bottleneck. For repository-level repair, the central challenge is therefore not only how to compress code, but how to place that compression inside the broader edit workflow."

The authors acknowledge: "While this exploratory study spans multiple multimodal backbones and a wide array of repository types, the findings reflect a controlled evaluation environment. Therefore, these initial insights warrant further validation in production-grade enterprise environments before extending these findings to definitive implementations of large-scale production solutions. They also note that Our evaluation relies on PLB and LET as controlled, rigorous abstractions designed for clean attribution, rather than exhaustive production-grade configurations."

Improvement 1: Adaptive Context-Modality Selection for Coding Agents

The AI system can dynamically choose between raw text code and rendered visual code based on the current task phase and cost-benefit analysis. During early exploration and localization, it uses text-based search and structured repository metadata (e.g., file trees, package summaries) to minimize token usage. Once a specific file region is identified as relevant, it switches to rendered code for dense, compressed reading of that region, but only when the source is sufficiently structured (e.g., low indentation, few blank lines) to avoid readability degradation. The system monitors its own token consumption per action and adjusts the rendering ratio (r) in real time—using higher ratios for large, dense code blocks and lower ratios for small or sparse ones—to avoid the piecewise-constant cost floor where resolution increases yield no token savings.

Improvement 2: Cost-Aware Repair Loop with Early-Stage Compression

The AI system can restructure its agentic workflow to front-load compression during unguided exploration and defer expensive trial-and-error to later stages. It begins with a pre-localization pass that compresses repository-wide search into a compact package (file paths, function signatures, and relevant snippets) before entering the repair loop. This shifts the action distribution from read/search-heavy (40%+ of actions) to test-edit-heavy (55%+), reducing token waste on redundant file browsing. The system then allocates its visual compression budget primarily to the editor phase, where raw source reading is a bottleneck, rather than the locator phase, which already benefits from structured metadata. This ensures that the largest token reductions (up to 2.8×) are realized without sacrificing accuracy, as the system avoids aggressive compression during critical patch refinement steps.

Improvement 3: Failure-Aware Token Allocation for Non-Resolved Tasks

The AI system can detect when a task is trending toward non-resolution (e.g., repeated test failures, multiple patch edits without progress) and automatically reallocate its token budget. Since the editor consumes 83.7% of total tokens on non-resolved tasks, the system switches to a more conservative compression strategy during this phase—using lower rendering ratios or reverting to raw text for critical code sections—to preserve readability and reduce the risk of misinterpretation. It also limits the number of trial-and-error iterations by introducing a checkpoint mechanism: after each failed test, it summarizes the error and the modified code region into a compact visual snippet, forcing the system to re-evaluate its hypothesis before spending additional tokens on full-file re-reads. This prevents runaway token consumption on difficult instances while maintaining a stable accuracy band (e.g., avoiding the 60% accuracy drop seen in aggressive LET compression).

Improvement 4: Structure-Aware Rendering with Readability Presets

The AI system can pre-analyze code files to determine their visual sparsity (indentation depth, blank line frequency, statement length) and select an optimal rendering configuration that maximizes token density without harming readability. For code with high visual sparsity (e.g., heavily indented or sparse), it uses line-preserving pagination and avoids increasing resolution beyond the minimum active token bucket, since further changes yield no cost benefit. For dense, compact code, it applies higher rendering ratios to achieve proportional savings. The system also maintains a readability score for each rendered image, computed from token cost and layout stability, and automatically falls back to raw text if the score drops below a threshold—preventing the diminishing marginal returns observed at high r values for small windows (e.g., 10-line windows costing 54 tokens for all r≥2).

Improvement 5: Two-Phase Agent with Decoupled Localization and Editing

The AI system can adopt a locator-editor architecture where the locator phase uses only text-based tools (Localize, Package, view code) to produce a committed repair plan, and the editor phase uses a mix of text and rendered code for focused test-edit loops. The locator is optimized for minimal token usage (using structured metadata instead of raw file reads), while the editor receives the plan and selectively renders only the code regions referenced in the plan. This decoupling allows the system to trace where compression is most effective: if the editor's token consumption remains high despite good localization, the system knows the bottleneck is trial-and-error, not repository understanding, and can adjust its rendering strategy accordingly (e.g., compressing test outputs or error logs rather than source code). The system also uses the locator's plan to pre-filter which files are candidates for visual rendering, avoiding the wide-scope context bloat that reduces compression gains from 2.8× to smaller margins.

Visual modality has recently been explored as a way to compress textual tokens, including rendering code as images for static code understanding. We study whether this representation can serve as operational context for agentic coding, where an agent must navigate repositories, edit source files, and verify executable patches. Using SWE-bench Verified, we evaluate rendered code in repository-level repair workflows and introduce controlled agent settings to separate unguided repository exploration from more structured repair stages. Our results show a mixed picture. Rendered code consistently reduces prompt-token cost, but the savings do not increase linearly with the nominal visual compression ratio. It largely preserves end-to-end repair accuracy, but does not overcome the performance limits of the underlying model or agent architecture, and can become unstable under aggressive compression. Further analysis suggests that visual code is most useful when raw source reading is a major bottleneck; once repository localization is structured, much of the remaining cost comes from patch--test trial-and-error, where visual compression has limited leverage. Overall, our study positions rendered code as a viable but conditional compression mechanism for realistic coding agents.