Practical LLM Programming: An Engineering Methodology for Tracing Legacy Bugs in 9 Minutes

1. The Problem: Why “Switching Models” Rarely Fixes Legacy Bugs

In systems maintained over the long term, there are always a few “legacy bugs”: sporadic occurrences, sparse logging, spanning multiple modules, and difficult to reproduce locally. Developers repeatedly investigate, switch tools, and adjust prompts, often ending up unresolved. The difficulty of such bugs lies not in the code itself, but in the lack of context—the root causes are scattered across multiple files, historical commits, and runtime states, while traditional interactive methods can only feed limited fragments into the model’s view at a time.

Recently, a class of large models with ultra-long context and strong reasoning capabilities has begun to change this. This article is not a review of any specific product, but rather abstracts a real bug-fixing process into a reusable engineering methodology: How to use large-context models to complete the closed loop from reproduction to verification at a controllable cost. For ease of narration, the following refers to this practice as “a field test.”

2. Calculating the Ledger: Capability Boundaries and Cost Models

Before assigning a task to a model, two prerequisites must be clear: how much it can read and how much each call costs. These two points directly determine the granularity of task splitting.

2.1 Context Window Determines “How Much to Feed at Once”

Current state-of-the-art Mixture of Experts (MoE) architecture models have reached a total parameter scale in the trillions, with only a few percent of parameters activated during a single inference. The direct benefit of this design is that inference cost scales with activated parameters, not total parameters. At the same time, a context window of millions of tokens means that a medium-sized code repository, related documentation, and recent commit records can be incorporated into a single inference.

For bug fixing, this is crucial. The root cause of a bug is often not in the line that threw the error, but in upstream data contracts, intermediate state passing, or downstream exception handling. By reading in a sufficiently large scope at once, the model can establish a cross-module causal chain instead of making “guess-based patches” locally.

2.2 Cost Accounting: Converting Budgets into “Fixable Bug Count”

Independent developers and small teams are most concerned about the cost per unit of output. Using standard API pricing as a reference, input costs are roughly a few dollars per million tokens, dropping to about a tenth when cache hits occur, and output costs are tens of dollars per million tokens. This magnitude means:

• A complete “read repo + locate + generate patch” call, with input in the hundreds of thousands of tokens and output in the thousands of tokens, costs roughly single-digit dollars per call.
• If caching is fully utilized (reusing stable context from the same repository), the marginal cost drops significantly.
• Based on an estimated annual budget of a few thousand dollars, the number of deep fixes supported ranges from hundreds to thousands, far exceeding the time cost equivalent of “manual line-by-line investigation.”

The key takeaway here is not the exact figure, but the cost structure: input is cheap, output is relatively expensive, and caching is extremely cheap. Therefore, the optimal engineering strategy is “read more, write less”—let the model fully read the context, and keep the output as concise, executable patches and verification steps.

2.3 How to Read Benchmarks Correctly

Aggregate scores on public leaderboards can be misleading. For engineering practices, several specific capabilities are more valuable references:

• Long-range continuous coding capability: Measures the model’s consistency level over long, multi-step tasks, corresponding to the risk of “fixing one thing and breaking three others.”
• Terminal-constrained task capability: Measures the model’s ability to execute, observe, and correct errors in a real command-line environment, corresponding to “whether it can run and verify by itself.”
• Autonomous task completion: Measures the model’s planning and convergence capabilities in multi-round tool calls, corresponding to “whether it requires constant human correction.”

It must be emphasized that benchmarks are only used for screening candidates and cannot replace real testing. The same model may perform vastly differently under different code styles and dependency versions; the final judgment must be based on your own repository.

3. Methodology: Six Stages of a Nine-Minute Closed Loop

Below, a complete bug fix is broken down into six stages. It should be noted that “nine minutes” refers to the wall-clock time from task assignment to verification passing, not the manual investment time; manual investment is mainly in early context preparation and late result review.

Stage 1: Construct a “Minimal Reproducible Environment”

No matter how strong the model is, it cannot fix a problem it cannot reproduce. Therefore, before submitting the task, three things must be prepared:

1. Reproduction script or command: A command that can stably trigger the bug locally, including necessary environment variables and input data.
2. Failure scene: Complete error stack, relevant log fragments, and key state snapshots at the time of triggering.
3. Boundary specifications: Explicitly inform the model “which modules can be modified, which are third-party dependencies that cannot be touched, and which behaviors are expected.”

This step is the环节 with the highest manual value. The experience in practice is: the quality of the reproduction script directly determines the success rate of the fix. A ten-line script that stably reproduces the issue beats a thousand-word description of the phenomenon.

Stage 2: Load Context All at Once

Incorporate the repository structure, related module source code, reproduction script, logs, and dependency list into the context all at once. To allow the model to quickly build an index, it is recommended to provide an explicit “map” in the prompt:

Repository Structure (Excerpt)
├── core/            # Main data processing pipeline
│   ├── pipeline.py  # Bug suspected in stage 3
│   └── schema.py    # Data contract definition
├── adapters/        # External input adaptation layer
└── tests/           # Regression cases
Reproduction command: <command>
Failure phenomenon: <stack summary>
Constraints: Do not modify any files under adapters/; do not introduce new dependencies.

This combination of “structured context + explicit constraints” significantly reduces the probability of the model providing “seemingly reasonable but out-of-bounds” patches.

Stage 3: Require Hypotheses First, Patches Second

If you ask for a patch directly, the model tends to output “symptom-level fixes.” A more reliable approach is a two-step process:

• Step 1: Require the model to output a list of root cause hypotheses, each with supporting evidence (which code snippet, which log, which commit).
• Step 2: Manually scan the hypotheses quickly, remove the obviously unreasonable ones, and then ask the model to provide patches and verification plans based on the retained hypotheses.

This step combines the model’s “breadth search” with human “domain judgment.” In practice, this often requires only one or two rounds of interaction but avoids a large amount of invalid code generation.

Stage 4: Patches Must Include Verification

A qualified patch output should contain three parts:

1) Change description: What changed, why it changed, impact scope
2) Patch content: Minimal diff, avoid incidental refactoring
3) Verification steps: Reproduction command should pass; regression cases to add

Specifically requiring a “minimal diff” is crucial. Models tend to optimize surrounding code along the way, which is high-risk behavior in legacy systems. With explicit constraints, the reviewability of the patch improves significantly.

Stage 5: Execute Verification in a Real Terminal

Verification must run in a real environment, rather than the model “claiming it passed.” Hand over the reproduction command, regression tests, and necessary static checks to the model for execution in the terminal, observe its output, and decide if another round of correction is needed. This step is where “terminal-constrained task capability” truly shines: the model needs to read command output, judge the cause of failure, and adjust the patch.

Stage 6: Archive and Document

After the fix is complete, organize “phenomenon—root cause—patch—verification” into a structured record and incorporate it into project documentation. The value of this record lies in the fact that the next time a similar problem is encountered, it can be directly fed to the model as part of the context, forming organizational-level experience reuse. This is also one of the most underestimated uses of long-context models.

4. From Bug Fixes to Frontend Prototypes: Migrating the Same Methodology

The same workflow can be migrated to the rapid prototyping of frontend landing pages. The difference is that the “verification standard” changes from “tests pass” to “visual and interactive expectations are met.” Key practices include:

• Structure first, style later: Let the model produce semantic page structure and component division first, and iterate on styles only after confirmation.
• Constrain the tech stack: Specify the range of available frameworks and component libraries to prevent the model from introducing uncontrollable dependencies.
• Use screenshots or descriptions for acceptance: Provide the expected layout as a structured description, converging round by round.
• Control iteration count: Frontend adjustments easily fall into infinite fine-tuning; it is recommended to set a hard constraint of “converge within three rounds.”

The essence of this workflow is consistent with bug fixing: define the scene, load context, converge step-by-step, verify in reality.

5. Risks and Boundaries: What Should Not Be Handed Over to Models

Objectively speaking, large-context models are not omnipotent. The following scenarios require caution:

1. Core logic involving security and compliance: The model can suggest, but the final judgment must be made by a human.
2. Concurrency bugs heavily dependent on runtime state: No matter how long the context is, it cannot replace real stress testing and observability.
3. Large-scale refactoring: Long context is suitable for “precise fixes,” not “complete rewrites,” as the latter carries uncontrollable risks.
4. Batch tasks with runaway costs: Always estimate with a small sample first before deciding whether to scale up.

6. Conclusion: Treat Models as “High-Bandwidth Collaborators”

Returning to the original question: why can switching to a large-context model fix legacy bugs? The answer is not that a certain model is “smarter,” but rather context bandwidth. When a model can read a sufficiently large scope of code and logs at once, it has the opportunity to establish cross-module causal chains; when the cost structure allows for “read more, write less,” this capability can be used stably and frequently.

The practical advice for developers can be summarized in four points:

• Build the scene first, then talk about fixing: A minimal reproducible environment is the prerequisite for efficiency.
• Structured context + explicit constraints: Significantly improves patch reviewability.
• Hypotheses first, patches with verification: Treat the model as a collaborator rather than a code generator.
• Archive each fix as a reusable context asset: Let experience grow alongside the repository.

Under this framework, “fixing a legacy bug in nine minutes” is not magic—it is the product of methodology, not chance.