Engineering LLM-Assisted Coding in Practice: From Model Selection to Fixing Stubborn Bugs in Ten Minutes

Over the past three months, I have coordinated multiple AI coding tools as a solo developer, producing approximately 270,000 lines of code and close to 3,000 commits. The annual subscription budget for this “one-person delivery system” is on the order of 17,000 RMB (roughly 2,350 USD). At this scale, I evaluate models on just two criteria: the per-token billing cost, and the real-world defect-fix delivery rate—meaning whether the model can actually repair a genuine bug within a limited number of interaction turns, rather than producing a patch that only looks correct.

This article skips the hype and focuses on the engineering chain. I will walk through how to interpret benchmark scores, how to calculate API costs, how to automate verification in restricted terminal environments, and how a long-standing defect was reproduced, modified, and verified in about nine minutes. I did not write a single line of code during the entire process.

1. Why “Overall Benchmark Scores” Are Not Enough for Model Selection

Third-party evaluation agencies publish composite rankings (such as well-known AA-style aggregate scores) that give a holistic picture of model capability. A recent batch of new-generation models has entered the global top four, narrowing the gap with leading closed-source models to 2–3 points, while some domestic models still cluster around 45, creating roughly a 10-point generational gap.

But composite scores have limited value for independent developers. The reason is that they weight and average multiple dimensions—mathematical reasoning, multilingual understanding, commonsense QA, code generation—whereas our daily work is heavily skewed toward three scenarios: long-duration continuous coding, autonomous task execution, and operations in restricted terminal environments.

A more sensible approach: treat the composite score as an “entry ticket,” then apply three vertical benchmarks for a second pass.

1.1 Long-Duration Continuous Coding

This measures whether a model can maintain context consistency across long, multi-file coding chains without “forgetting halfway.” Industry benchmarks like SWE Marathon fall into this category. The current top tier reaches around 51%, leading closed-source models around 46%, and another mainstream class around 42%. In real projects, this gap widens into the difference between “can complete a five-file refactor in one pass” and “cannot.”

1.2 Autonomous Task Execution

This measures whether, given a goal, a model can plan its own steps, invoke tools, read error output, and roll back and retry. Benchmarks in this space (such as Agents’ Last Exam) focus on the stability of agentic behavior, not the quality of a single-turn answer.

1.3 Restricted Terminal Tasks

This is the most underrated yet most critical category for engineering delivery. Benchmarks like Terminal-Bench simulate environments with only a command line—no GUI, no unrestricted network access—requiring the model to perform file operations, dependency installation, builds, and tests via shell. The previous generation scored around 13%; the new generation reaches 65% or higher, less than 1 percentage point behind the strongest closed-source model and more than 7 points above another mainstream class.

This leap means the model has evolved from “can write code snippets” to “can run code in a real terminal.” For solo developers, that is the difference between needing a separate ops/debugging assistant and not.

2. Getting the Token Bill Right: Unit Cost Determines Affordable Interaction Turns

The second calculation is money. Many developers compare only “price per million input tokens” and overlook cache-hit pricing and actual interaction structure, leading to budget estimates off by several times.

Using the current mainstream pricing structure for a typical coding-assist model as an example:

Billing Item	Price Range
Input (standard)	~$1.80 / 1M tokens
Input (cache hit)	~$0.18 / 1M tokens
Output	~$9.50 / 1M tokens

The key is the second row. In coding scenarios, most input is repetitive: the same codebase, the same requirements document, the same error log get sent repeatedly across turns. If the model supports context caching, this portion drops to one-tenth of the standard price. Compared to previous-generation models, overall API costs fall by roughly one-third.

A Practical Cost Estimation Formula

Single-task cost ≈ (first-turn input × input price
                    + subsequent turns × cached-input price)
                  + cumulative output tokens × output price

Assume a defect-fix task: first-turn input of 200K tokens (full codebase + docs), 8 subsequent turns averaging 50K tokens each (90% cache hit), and 30K cumulative output tokens. Using the table above:

• First-turn input: 0.2 × 1.80 = $0.36
• Subsequent cached input: 8 × 0.05 × 0.9 × 0.18 ≈ $0.06
• Subsequent non-cached input: 8 × 0.05 × 0.1 × 1.80 ≈ $0.07
• Output: 0.03 × 9.50 ≈ $0.29
• Total ≈ $0.78

Fixing a real engineering defect costs single-digit dollars. That is the arithmetic foundation behind “a 17,000 RMB annual budget supporting 270,000 lines of code.”

Context window size directly affects whether the first-turn input can “fit everything at once.” The current top-tier models support roughly 1M tokens of context, meaning a medium-sized codebase plus technical documentation can be read in one shot—avoiding the information loss and turn inflation caused by repeated slicing and retrieval.

3. Fixing a Stubborn Bug in Nine Minutes: Full Chain Walkthrough

Now for the hands-on test. In a self-built content distribution tool, I had a long-standing defect: under specific data-flow conditions, content was being distributed duplicately. Previous model attempts had failed—either producing patches that “looked reasonable but didn’t work,” or going off track during the diagnosis phase.

Step 0: Task Packaging (Manual, ~1 minute)

This is the only step requiring human judgment. I wrote the task in a three-part format:

[Symptom] Under condition X, result Y appears duplicated.
[Reproduction] Run command: <minimal reproducible command>
[Constraints] Do not modify the external interface of module A; add regression tests.

The key: provide an executable reproduction path, not just a description of the symptom. Whether the model can run and verify on its own is the dividing line for fix efficiency.

Step 1: Reproduction (Model-Autonomous, ~2 minutes)

The model executes the reproduction command directly in the terminal, reads the output, and confirms the defect exists. The value of this step is severely underestimated—many “unfixable” cases fail because the model never actually reproduces the problem; it just guesses.

Step 2: Diagnosis (Model-Autonomous, ~3 minutes)

Within the full codebase context already loaded, the model traces the data flow:

Entry → Queue Distribution → Deduplication Check → Consumption & Persistence

It identifies a race-condition window in the deduplication key construction: under concurrent consumption, the same content can be judged “unprocessed” twice.

Step 3: Patching (Model-Autonomous, ~1 minute)

The model generates a patch: changing the deduplication check from “read-then-judge” to “atomic placeholder-then-judge,” with a rollback-safe failure path. The change scope is kept to two files.

Step 4: Verification (Model-Autonomous, ~2 minutes)

• Re-run the reproduction command to confirm the defect is gone;
• Execute the regression test suite to confirm no existing behavior is broken;
• Add a targeted test for the specific race condition.

From pressing Enter to completing reproduction, patch, and verification: approximately nine minutes. I wrote zero lines of code.

Why It Worked This Time

Three conditions, all necessary:

1. Full context: A million-token window let the model see cross-module call relationships, not just local fragments.
2. Terminal execution capability: The model could run reproduction commands, read errors, and run tests, forming a closed loop.
3. Minimal reproducible test case: The only “leverage” I provided as a human.

4. A Reusable Engineering Methodology

Abstracting the above flow yields a method applicable to solo developers and small teams.

4.1 Task Packaging Template

Context: <one-sentence description of module responsibility>
Symptom: <observable error behavior>
Reproduction: <directly executable command or script>
Constraints: <interfaces that must not change / prerequisites that must hold>
Acceptance: <automatically executable verification method>

“Acceptance” is a blind spot for many. Tasks without an automated acceptance criterion are not suitable for independent model execution.

4.2 Three Cost-Control Principles

• Leverage context caching first: Place stable, unchanging codebase and documentation early in the conversation; put changing content later.
• Control interaction turns: The more turns, the more cache savings depend on implementation quality. Describe the task completely in a single turn.
• Tier your tasks: Use high-capability models for exploratory refactoring; use lower-cost models for deterministic tasks like formatting and unit-test completion. Allocate budget on demand.

4.3 Minimal Verification Loop

Reproduction script → Fix patch → Regression tests → Targeted test

Missing any of the four steps risks a “false fix.” Special note: regression tests must be run by machine—human judgment is unreliable at this stage.

4.4 A Note on Landing-Page Construction

Beyond bug fixes, I have applied a similar verification approach to landing-page builds. The reusable pattern: have the model produce the structural and style skeleton first, then inject real copy and data block by block, and finally use a headless browser for visual regression screenshots. This gives each round a comparable baseline and prevents “changes getting messier over time.”

5. Conclusion

Engineering LLM-assisted coding boils down to the product of three things:

• Context completeness—determines whether the model can see the full picture of the problem;
• Terminal execution capability—determines whether the model can verify its own conclusions;
• Per-token cost—determines whether this workflow can run sustainably.

Composite scores are the entry ticket, vertical benchmarks are the filter, and the token bill is the sustainability floor. When all three align, a solo developer coordinating multiple AI tools to deliver 270,000 lines of code is not an exaggerated figure—it is a decomposable, reusable, verifiable engineering method.

That long-standing defect cost single-digit dollars and nine minutes to fix. The real value is not the result itself, but the repeatable method behind it.