LLM Coding in Action: Fixing a Stubborn Bug in 9 Minutes with Long Context Windows

1. Background: When Codebases Exceed Manual Review Capacity

Over the past quarter, working as an independent developer, I leveraged multiple AI coding tools to iterate on a content distribution system. The scale of output over three months was substantial:

• Approximately 270,000 lines of code added or modified.
• Nearly 3,000 commits.
• The primary development model was a “solo developer + multiple AI assistants” collaboration.

The bottleneck in this model is not writing new code, but rather handling stubborn bugs in existing code. The system had a long-standing legacy bug: its trigger conditions were hidden, the reproduction path depended on specific data states, and previous attempts with various models failed to fix it reliably. It was not a syntax error or a simple null pointer, but a classic “multi-module state coupling + boundary condition” problem—exactly the type of issue that consumes the most manual effort.

This article uses this case as an entry point to discuss a broader technical proposition: When a model’s context window reaches the million-token level, how does the engineering pipeline for bug localization and repair change? It also provides a cost estimation method and a reusable workflow design.

---

2. The Foundation: Long Contexts and Sparse Activation Architecture

To understand why this practice is feasible, we must first examine the changes in underlying capabilities.

Current state-of-the-art LLMs widely adopt the Mixture of Experts (MoE) architecture. Its core idea is that the total parameter count of the model can be massive, but each forward pass only activates a subset of expert networks. For example, in a model with a trillion-level total parameter count, the active parameters during a single inference might only be in the hundred-billion range. The direct benefits of this approach are:

1. Decoupling inference cost from total parameters. Parameter scale determines knowledge capacity, while activation determines computational overhead.
2. Making long context more viable. With the context window expanded to the million-token level, an entire medium-sized codebase, accompanying documentation, and issue records can be loaded at once.
3. Amortizing costs via caching mechanisms. For recurring context prefixes (such as the same codebase), the input billing upon a cache hit is typically much lower than standard input.

From an engineering perspective, the combination of these three points is significant: the past RAG-style workflow of “retrieve-slice-stitch” can now be simplified to “whole-repo direct read.” A inherent flaw of RAG is that slicing boundaries sever cross-file call chains, whereas direct whole-repo reading preserves complete symbol reference relationships. For the type of state-coupled bugs mentioned earlier, this is often the decisive factor.

---

3. The Bug Fix Pipeline: What Happened in 9 Minutes

From assigning the task to the model to passing verification, the entire process took about 9 minutes, during which no human wrote any code. This pipeline can be broken down into five stages.

3.1 Stage 1: Context Loading

The repository structure, relevant module source code, dependency declarations, and historical commit information are input together as context. The value of the million-token context window here is: no manual judgment is needed regarding “which file is relevant.” The model can independently traverse the call chain to retrieve information.

3.2 Stage 2: Bug Reproduction

Based on the bug description and code logic, the model deduces the minimal reproduction path and generates an executable reproduction script or test case. This step is a crucial watershed—whether it can be reproduced determines if the subsequent fix is verifiable.

# Example: Skeleton of the reproduction case generated by the model
def test_reproduce_bug():
    state = build_initial_state()
    state = apply_edge_case(state)   # Trigger condition
    result = process(state)
    assert result.status == "expected", f"got {result.status}"

3.3 Stage 3: Root Cause Localization

With full context, the model outputs an explanation at the call chain level, rather than just pinpointing “a specific line is wrong.” Typical output formats include: cross-module state transition paths, coverage gaps in conditional branches, and race windows under asynchronous timing.

3.4 Stage 4: Patch Generation and Self-Verification

After providing a fix, the model runs tests and checks for regressions. If it fails on the first attempt, it iterates based on the error output. This “generate-execute-feedback” closed loop is the core mechanism for compressing fix time from hours to minutes.

3.5 Stage 5: Human Review

The manual phase converges to reviewing the diff and confirming semantic correctness, rather than writing code line by line. This represents a shift in role: from implementer to acceptor.

---

4. Cost Accounting: The Numbers Independent Developers Care About

No matter how capable the tool is, the math must work out. Below is a reusable estimation framework, with specific unit prices subject to public pricing on various platforms.

4.1 Billing Dimensions

Mainstream API billing typically includes three components:

Dimension	Description	Engineering Implication
Standard Input	Input tokens not hitting the cache	Incurred during the initial codebase load
Cache Hit Input	Input hitting a cached prefix	Multi-turn conversations, recurring context scenarios
Output	Tokens generated by the model	Positively correlated with inference depth

4.2 Cache Hit Rate is the Key Variable

In the “whole-repo direct read” mode, the same codebase will appear repeatedly across multi-turn interactions. If the cache hit price is roughly one-tenth of the standard input price, the actual cost is primarily determined by the initial load + output. This explains a counterintuitive phenomenon: the longer the context, the lower the unit task cost may actually be, because it eliminates the need for repeated retrieval and manual slicing.

4.3 Annual Budget Projection

Taking an annual budget of roughly $2,500 USD as an example, we can reverse-calculate the supported workload:

• If the average consumption of input and output tokens per bug fix task remains within a controllable range;
• And daily development focuses mainly on incremental modifications with a high cache hit rate;

Then the annual budget can cover hundreds of medium-complexity fix and generation tasks. For independent developers, the ROI at this investment level is practically viable.

---

5. Reusable Workflow Design

Abstracting the above practice into a universal process yields four steps.

5.1 Establish a Stable Context Baseline

Organize the codebase into a model-readable stable structure, maintaining directory and file naming consistency. A stable prefix implies a higher cache hit rate, directly reducing costs.

5.2 Enforce Reproduction Before Fix

Require the model to produce an executable reproduction case before providing a patch. This step filters out a massive number of pseudo-fixes that “look correct but don’t actually solve the problem.”

5.3 Use Tests as Acceptance Contracts

Patches must pass both existing test suites and newly added reproduction cases. This is the only reliable means to transform model output into trusted engineering artifacts.

5.4 Separate “Exploration” and “Implementation”

• Exploration phase: Allow the model to read context extensively and propose multiple hypotheses.
• Implementation phase: Restrict the diff scope and review line by line to avoid introducing unrelated changes.

---

6. Limitations and Risk Warnings

A few constraints must be objectively noted:

1. Long context does not equal infinite attention. Under extremely long inputs, the effective utilization of mid-sequence information may still degrade; key constraints should be placed prominently and repeatedly emphasized.
2. Model self-verification relies on an executable test environment. If a project lacks testing infrastructure, fix quality will significantly decline.
3. Cost predictability relies on caching strategies. Frequently changing contexts will diminish cache benefits.
4. Security and Compliance. Before sending private code to external services, evaluate data boundaries and access control strategies. In controlled environments, consider leveraging private inference capabilities provided by enterprise-grade cloud platforms.

---

7. Conclusion

The combination of million-token context windows and sparse activation architectures is changing how large codebases are maintained. Its value lies not in “replacing developers,” but in freeing human effort from retrieval and trial-and-error, allowing focus on semantic review and architectural decisions.

From an engineering practice perspective, the actionable takeaways are threefold: replace fragmented retrieval with whole-repo direct reading; enforce a reproduction-before-fix workflow; and use test suites as acceptance contracts. Paired with a sensible caching strategy, annual budgets can be kept within an affordable range, while bug fix response times are compressed from hours to minutes. For independent developers and small teams, this is a technical path worth serious evaluation.