LLM-Assisted Programming in Practice: Engineering Lessons from Fixing a Stubborn Bug

1. Background: How One Person Coordinates Multiple AIs for Scaled Delivery

Over the past quarter, I worked as a solo developer and used multiple large models collaboratively to write roughly 270,000 lines of code, with close to 3,000 commits in total. Annual spending on various AI coding tools stayed around 17,000 RMB. What makes this “one-person delivery system” work comes down to two calculations that must be done properly:

• Token billing cost: Input, output, and cache-hit prices differ significantly across models, directly affecting the marginal cost per unit of functionality.
• Delivery rate on real engineering troubleshooting: No matter how high a benchmark score is, if the model cannot locate the problem in a real codebase and fix it cleanly, it produces no practical value.

Recently, a cloud vendor released a new-generation model optimized for coding scenarios. It uses a mixture-of-experts architecture with a total parameter scale in the trillions, roughly one hundred billion activated parameters per pass, support for a million-token context window, and a commitment to open full model weights for a period going forward. Taking advantage of this version iteration, I handed a long-standing stubborn defect in a self-built content distribution tool to the model for a real test. From pressing Enter to reproducing, modifying, and verifying the fix, the whole process took about nine minutes, and I did not hand-write a single line of code. Below I break down the entire workflow.

2. Capability Assessment: Benchmarks Are Just the Entry Ticket; Hands-On Coding Is the Real Test

On a third-party composite evaluation leaderboard, the model scored 55 points, placing it in the global top tier and about 11 points higher than the previous generation of the same series. More noteworthy are its granular results on coding and terminal tasks:

• Long-horizon continuous coding benchmark: 51.7%, a leading position on this item and clearly above the 40%–47% range of other mainstream models in the same period.
• Real terminal constrained-task benchmark: 65.7%, compared with only 13% for the previous generation of the same series—an improvement of more than 50 percentage points and a gap of less than 1 percentage point from the top score.
• Autonomous task execution benchmark: Also in the front rank, indicating usable capability in multi-step tool invocation and environment interaction.

These data point to one conclusion: only when the context window is large enough and terminal-task capability is strong enough can a model take on troubleshooting work in real engineering environments. Benchmarks are the entry ticket; whether the model can pinpoint the lesion in noisy legacy code is the real dividing line.

3. Cost Model: Three Calculations a Solo Developer Must Get Right

The token bill is an unavoidable real-world constraint. The model’s API pricing is about one-third lower than the previous generation. The standard domestic version is roughly: 13 RMB per million input tokens, 1.3 RMB per million cached tokens, and 68 RMB per million output tokens. From this we can build a simple cost estimation model:

# Token cost estimate for a single troubleshooting task (illustrative)
INPUT_PRICE = 13 / 1_000_000      # RMB/token, standard input
CACHE_PRICE = 1.3 / 1_000_000     # RMB/token, cache hit
OUTPUT_PRICE = 68 / 1_000_000     # RMB/token, output
def estimate_cost(input_tokens, cached_tokens, output_tokens):
    return (input_tokens - cached_tokens) * INPUT_PRICE \
         + cached_tokens * CACHE_PRICE \
         + output_tokens * OUTPUT_PRICE
# Assume a codebase-level troubleshooting run: 80k tokens read in, 60k cache hits, 4k tokens output
print(estimate_cost(80_000, 60_000, 4_000))  # about 0.62 RMB

The key variable is the cache hit rate. When a large codebase is read repeatedly, the cached price is only one-tenth of standard input, which means pre-warming commonly used code context into the cache can push the cost of a single troubleshooting run below one RMB. For a solo developer with an annual budget of 17,000 RMB, this magnitude is entirely affordable.

4. Hands-On Review: The Full Chain of Fixing a Stubborn Defect in Nine Minutes

4.1 Defect Background and Prior Attempts

The defect was located in the scheduled-task module of the content distribution tool, manifesting as repeated task triggering and a state machine deadlock under specific conditions. Several models had been tried previously to fix it, none of which resolved it thoroughly—either the localization was wrong, or the change introduced regressions. The typical signature of such a “stubborn defect” is: the symptom is at point A, the root cause is at point B, and the issue involves cross-module state transitions.

4.2 Breakdown of the Fix Workflow

1. Context feeding: Pass in the relevant module source code, log fragments, and state machine definitions all at once. The value of the million-token context window shows here—no manual code trimming is needed, and the model can see the complete call chain.
2. Defect reproduction description: Describe the trigger conditions, expected behavior, and actual behavior in natural language, avoiding leading phrasing so the model reasons on its own.
3. Root cause localization: The model gives suspicious points along with its reasoning basis. This step is the key to judging whether the model “really understands”—look at whether it can explain the causal chain clearly, not just give a change location.
4. Fix proposal generation: Output a patch, along with an explanation of why the change is made and how large the impact surface is.
5. Verification loop: Run test cases and check state machine transition logs to confirm the fix and the absence of regressions.

4.3 Why It Worked This Time

Compared with the reasons for earlier failures, the differences come down to three points:

• Context completeness: Previously the model could only see fragments and tended to reason on wrong assumptions; this time the complete context let the cross-module causal chain emerge.
• Terminal-task capability: The model could understand runtime logs, test commands, and state output, rather than only processing plain-text code.
• Controllable reasoning chain: The model gave an explicit causal explanation rather than simply throwing out a change, which let the verification step be targeted.

5. Extended Scenario: Generative Engineering Practice for Frontend Landing Pages

Beyond troubleshooting, the model is also usable for generating frontend landing pages. A typical workflow is:

1. Provide structured inputs such as product positioning, target audience, and core selling points.
2. The model produces the page structure, component breakdown, and styling approach.
3. A human reviews the information hierarchy and interaction logic, and the model iterates accordingly.
4. Output runnable code and integrate it into the build pipeline.

Note here that the core of generative frontend engineering is not “a page from one sentence” but breaking design intent into verifiable intermediate artifacts (structure tree, component contracts, style variables) and then landing them layer by layer. Otherwise the generated result looks complete but is in fact unmaintainable.

6. Methodology: Four Principles for Landing LLM-Assisted Engineering

1. Capability-matching principle: Composite benchmark scores serve only as an initial screen; coding and terminal-task sub-benchmarks are the basis for model selection.
2. Cost-front-loading principle: Build token budgets, caching strategy, and context length into the architecture design rather than optimizing after the fact.
3. Closed-loop verification principle: Any patch produced by a model must go through the three steps of reproduction, testing, and regression verification.
4. Human-machine division principle: Humans define problems, review causality, and gatekeep architecture; the model retrieves, reasons, and generates. The clearer the division, the higher the delivery rate.

7. Summary

Trillion-level parameters, million-level context, and continuously falling token unit prices are turning “one person coordinating multiple AIs for scaled delivery” from a concept into a replicable engineering practice. But tool capability is only a necessary condition; the real moat lies in: whether engineering problems can be decomposed into context a model can handle, whether a cost model can constrain technology selection, and whether a verification loop can guarantee delivery quality. Get these three right, and fixing a stubborn defect in nine minutes is no longer an isolated case but a predictable engineering norm.