LLM Coding in Practice: An Engineering Workflow for Fixing a Stubborn Bug in 9 Minutes

Background: A Long-Standing Bug Puts the Method to the Test

As an independent developer, I maintain a self-built project that has grown to hundreds of thousands of lines of code over the past several months. One long-standing bug had resisted several rounds of fixes: the symptoms were subtle, the call chain was long, and every time it seemed to be fixed, it reappeared a few days later through a different entry point.

The goal of this test was straightforward: hand the entire problem to an LLM-powered coding assistant and time everything from task submission through reproduction, modification, and verification. From the moment I pressed Enter to the moment verification passed, about nine minutes elapsed—and I did not hand-write a single line of code.

Those nine minutes are not magic. They rest on an engineering method that can be broken down and reused. This article lays it out completely: first how to choose a model and calculate costs, then the hands-on workflow, and finally the boundaries and risks.

Model Selection: Read Coding Benchmarks, Not Just Headline Scores

1. What Three Benchmark Families Actually Measure

General-purpose leaderboards are useful for a first impression, but they are too coarse for coding scenarios. Three specialized benchmark families are far more informative:

• Software engineering benchmarks: simulate real issue fixing. The model must locate and modify code across files over multiple interaction rounds and pass the tests, which measures “long-horizon continuous coding” ability;
• Constrained terminal benchmarks: the model gets nothing but a command line and must autonomously install dependencies, run tests, and read logs, which measures an agent’s ability to survive in a real engineering environment;
• Agentic general-task benchmarks: examine tool calling, multi-step planning, and self-verification of results—the “let the AI do the work itself” scenario.

2. How to Read the Scores Without Being Misled

• Look at specialized scores, not total scores: if your daily work is fixing bugs and running terminal commands, terminal-family benchmarks should weigh far more than overall leaderboards;
• Look at gaps, not absolute values: if same-tier models differ by more than ten percentage points on a given task, that capability is far from saturated and the selection difference will show up directly in output quality; if everyone is near the ceiling, the difference hardly matters;
• Look at generational jumps: how much a new generation improves over its predecessor on a specific item often says more than side-by-side comparisons about whether an architectural improvement actually lands in your scenario;
• Scores are necessary, not sufficient: leaderboards use public task sets, while your codebase, tech stack, and coding conventions are a private distribution. The right approach: use the leaderboards to narrow the candidate list, then run small-sample tests on your own real tasks.

3. Architecture and Context: Two Easily Overlooked Variables

• Mixture-of-experts (MoE) architecture: total parameter count determines knowledge capacity, while the parameters activated per inference determine cost and speed. Evaluate “activated scale” together with pricing and latency, not just the headline total;
• Context window length: an extra-long window means a mid-sized module or a long API document can be read in one pass, eliminating manual slicing. But “can read it” is not “remembers it accurately”—key constraints still need to be stated explicitly in the prompt;
• Weight availability policy: whether weights are open determines whether you can deploy privately and fine-tune. Compliance-sensitive teams should confirm this early in the selection process.

The Math: A Token Cost Model for Independent Developers

1. What Costs Are Made Of

• Input tokens: prompt + code context + conversation history, usually the largest share;
• Output tokens: generated code and explanations;
• Cache hits: repeated prefixes served from cache can significantly dilute input costs;
• Hidden costs: failed retries and context re-sending during multi-turn debugging—the most commonly underestimated part.

2. A Formula You Can Apply Directly

# Illustrative estimate; unit prices are assumed values—refer to your platform's actual pricing
def monthly_cost(in_tok, out_tok, in_price, out_price, days=22):
    daily = in_tok / 1e6 * in_price + out_tok / 1e6 * out_price
    return daily * days
# Assumptions: 500K input tokens and 50K output tokens per day
# CNY 4 per million input tokens, CNY 16 per million output tokens (illustrative)
print(monthly_cost(500_000, 50_000, 4, 16))  # about CNY 61.6 per month

Light use costs only a few hundred yuan a year. Agent-style coding, however, repeatedly carries large chunks of context, and a 5–10x amplification of input volume is common, which pushes annual costs into the thousands-to-tens-of-thousands of yuan range—this is exactly how the oft-mentioned “five-figure annual budget” accumulates. Export a usage statement every month, group it by project, and optimize the steps with the heaviest “context re-sending.”

3. Four Cost-Reduction Levers

1. Control the context: pass only relevant files; replace full-file pastes with summaries;
2. Exploit prompt caching: keep the system prompt and project description fixed to raise cache hit rates;
3. Tier your models: hand formatting conversions and simple refactors to a lightweight model; bring in the flagship only for hard problems;
4. Set stop conditions: define output limits and “when to stop and ask me” so the model does not burn tokens sprinting down the wrong path.

Hands-On: The Complete Workflow Behind the 9-Minute Fix

1. Preparation Is Half the Work

The nine minutes were only possible because three things were already in place:

• Minimal reproduction: stable reproduction steps, input/output samples, key logs, environment versions;
• Constraint list: which public interfaces must not change, where the performance red lines are, which callers depend on current behavior;
• Test baseline: run the existing tests before starting and record the passing set, so results can be compared after the fix.

2. A Prompt Template You Can Reuse

[Background] The project is a content distribution tool; tech stack: XX; codebase size: ~XX hundred thousand lines
[Symptom] XX happens in scenario XX; expected behavior is XX
[Reproduction] 1. ... 2. ... 3. ... (attach logs and input samples)
[Already ruled out] Directions A and B have been excluded, for the following reasons...
[Constraints] Do not modify public interfaces; keep backward compatibility; do not introduce new dependencies
[Requirements] First present the 3 most likely root-cause hypotheses and how to verify each one;
              wait for my confirmation before touching the code; add regression tests after the fix

The key is the last line: hypotheses first, code later. Forcing the model to produce an evidence chain first dramatically reduces the “looks fixed” false positives.

3. Reproduce → Locate → Fix → Verify

• Reproduce: have the model restate the reproduction path first, to confirm that the problem it “sees” is the one you see and to avoid the two of you heading in different directions;
• Locate: ask for ranked hypotheses with evidence; when necessary, have it insert temporary logging and rerun, using runtime data to converge on the cause;
• Fix: commit in small steps—one hypothesis and one minimal change at a time, with every step reversible;
• Verify: run the full test suite, manually verify the original reproduction path, and add edge cases; finish by having the model generate regression tests that lock in the fix and prevent the same class of bug from coming back.

4. What “Not Writing a Single Line” Really Means

What you save is typing and searching time, not thinking time. The human judges whether a hypothesis holds and whether a change oversteps its bounds; the model executes and enumerates. The clearer the division of labor, the fewer trial-and-error rounds—and only then can nine minutes happen.

Second Hands-On: Generating and Accepting a Frontend Landing Page

The same method applies to page-building tasks with a few adjustments:

• Structured requirements: information hierarchy, color palette, responsive breakpoints, and interaction list, all stated up front;
• Component-based generation: have the model produce the layout skeleton first, confirm it, then fill in each section—so parts can be swapped without pulling the whole page apart;
• Acceptance checklist: semantic markup, accessibility (contrast, keyboard navigation), performance (image dimensions, asset weight), and behavior on mobile and with extreme content lengths.

Common pitfalls include long text breaking containers, duplicated event bindings, and missing empty and loading states. Put these three on the acceptance checklist and rework rates drop noticeably.

Boundaries and Risks: What Should Not Be Fully Delegated

• Hallucinated APIs: the model may reference functions or parameters that do not exist—always trust the compiler and the runtime, not the text;
• Regression risk: locally correct is not globally correct; the blast radius of a change must be covered by tests;
• Security and compliance: keys and user data never go into prompts; review the license of any code snippet you adopt;
• Architecture decisions: models are good at local optima; technology selection and evolution direction remain human calls.

Conclusion: Turn AI Coding into a Team Asset

Pick models by specialized benchmarks, track costs in detail, execute through a process, and guarantee quality through verification—those four sentences are the entire conclusion of this article. Turn the prompt template, the acceptance checklist, and the cost statements into team assets so that every hands-on session becomes reusable methodology. Developers can also combine the methods above with LLM services from major cloud platforms—such as the general-purpose model APIs offered by Baidu AI Cloud—to run small-sample tests on their own real tasks before deciding whether to fold them into the daily toolchain. Once the process is engineered enough, “fixing a stubborn bug in nine minutes” stops being luck and becomes the norm.