Engineering LLM-Assisted Programming: From Cost Structure to Stubborn Bug Localization

Over the past months, one developer orchestrating multiple AI coding tools to deliver large-scale code has gradually evolved from an early-adopter experiment into a reusable way of organizing engineering work. Nearly three thousand commits over three months, a codebase in the hundreds of thousands of lines, and annual tool subscription spending kept under a defined budget—what is really worth discussing behind these numbers is not “whether AI can write code,” but how to embed model capabilities stably into a real delivery pipeline at a controllable cost.

This article does not recommend or benchmark any specific product. Instead, it abstracts this kind of practice into a methodology: which two cost calculations matter for tool selection, which dimensions to evaluate, how to design a localization workflow for stubborn defects, and how to quantify cost. It closes with a reusable troubleshooting paradigm.

1. The Two Calculations of Tool Selection: Token Cost and Bug-Fix Delivery Rate

When teams introduce AI coding tools, their first instinct is often to compare “who writes faster.” But in real commercial delivery, speed is only an intermediate variable. What actually determines profit and loss is two calculations.

1.1 The First Calculation: Token Billing Cost

LLM inference billing typically consists of three parts: input, output, and cache hits, with caching having an outsized impact in long-context scenarios. Using a common industry pricing structure as an example, this can be abstracted as:

Cost per task ≈ input tokens × input unit price
              + cache-hit tokens × cache unit price
              + output tokens × output unit price

The key insight: the input unit price and the cache-hit unit price often differ by an order of magnitude. When a codebase is referenced repeatedly, if the tool supports context caching, the effective cost is significantly diluted. Conversely, if the entire codebase is re-uploaded with every conversation, the bill quickly spirals out of control.

So when evaluating cost, don’t just look at a single number like “how much per million tokens.” Calculate the unit delivery cost:

Unit delivery cost = total monthly tool spending ÷ number of valid delivery tasks completed that month

A valid delivery task means a change that is actually merged and passes validation—not lines of code generated. Only this metric truly reflects return on investment.

1.2 The Second Calculation: Real-World Bug-Fix Delivery Rate

A high benchmark score does not mean the model can fix the bug in front of you. The real-world bug-fix delivery rate can be measured with a simple formula:

Bug-fix delivery rate = tasks fixed successfully on the first attempt and passing validation ÷ total bug-fix tasks

Here, “fixed successfully on the first attempt” means the model’s change passes tests without human correction. “Passing validation” means there is an executable means of verification, not just visual confirmation.

In practice, these two calculations often pull in opposite directions: low-cost models have a low delivery rate, and repeated retries push up total cost; high-cost models have a high delivery rate, but if the task itself is simple, budget is wasted. A reasonable strategy is routing by task complexity—simple changes go through the low-cost channel, complex troubleshooting goes through the strong-reasoning channel.

2. Evaluation Dimensions: What to Look at Beyond Composite Scores

Third-party composite benchmark leaderboards (such as common AA-style aggregate scores) are suitable for initial screening, but for developers, the dimensions that really differentiate models are the ones closer to engineering scenarios.

2.1 Long-Horizon Continuous Coding Ability

Real development is not a single-turn Q&A; it is a multi-turn loop of “change something, run tests, read the error, change again.” Benchmarks measuring this ability typically focus on maintaining context consistency across multiple turns of dialogue. If a model can still remember the original constraints after dozens of turns of interaction, its engineering value is far higher than a model that excels in single-turn performance but forgets.

Evaluation points:

• Whether regression defects are introduced after multiple rounds of modification;
• Whether relevant files can be accurately located within a long context;
• How well the existing code style is preserved.

2.2 Autonomous Task Execution Ability

An important direction of evolution for AI coding tools is “doing the work itself”—decomposing, executing, and verifying autonomously once a goal is given. This capability is usually measured by benchmarks that simulate real task environments, focusing on whether the model can complete a task loop without step-by-step human guidance.

2.3 Terminal-Constrained Task Ability

This is the most easily overlooked dimension, yet the one closest to daily work. Developers spend a lot of time in the terminal: troubleshooting build failures, analyzing logs, resolving dependency conflicts. The common trait of these tasks: observable information is limited, and reasoning must happen under constrained feedback.

Benchmarks measuring this ability typically include:

• Inferring root causes from error output;
• Planning troubleshooting steps in environments where commands cannot be executed freely;
• Handling vague or incomplete error messages.

If a model performs strongly here, it means it can handle real scenarios with “incomplete information,” rather than only excelling at well-structured problems.

2.4 Practical Usability of the Context Window

The nominal length of a context window and its practical usable length are two different things. When evaluating, pay attention to:

• Whether retrieval accuracy drops noticeably near the window limit;
• Whether the caching mechanism covers long documents;
• Whether latency and cost under very long contexts are acceptable.

3. Localizing Stubborn Defects: A Reusable Nine-Minute Paradigm

Now to the core of this article: how to compress the localization and fixing of a stubborn defect to the minute level. Here, “stubborn” means: multiple approaches have already been tried without success, reproduction conditions are unclear, and the defect involves cross-module interaction.

3.1 Stage One: Describe the Problem in a Verifiable Form (About 2 Minutes)

Models that look capable but fall short often fail on input quality. A low-quality question is “this feature has a bug, take a look.” A high-quality problem description should include:

[Symptom] Specific behavior, including error text or abnormal behavior
[Reproduction] Minimal reproduction path, or explicitly "cannot reproduce reliably"
[Environment] Version, configuration, dependency scope
[Expected] What the correct behavior should be
[Attempted] What troubleshooting has been done, which possibilities have been ruled out
[Constraints] Which parts must not be changed

Give this description to the model all at once, rather than supplementing it bit by bit. Do this step solidly, and subsequent fix efficiency improves many times over.

3.2 Stage Two: Have the Model Reproduce First, Then Act (About 3 Minutes)

This is the step most easily skipped and the most critical. Ask the model to first provide a reproduction plan or reproduction reasoning, rather than directly giving a patch. The reason is simple: a patch that has not been confirmed by reproduction is essentially a guess.

An effective prompt structure:

Before giving the modification, please first:
1. Analyze the possible trigger conditions of this defect;
2. Provide a minimal verification method that can reproduce it reliably;
3. Explain your reasoning basis.
After confirming the reproduction path, then give the modification plan.

If the model’s reproduction reasoning does not match your observations, the problem description is still ambiguous—go back to Stage One and add information.

3.3 Stage Three: Constrain the Scope of Modification, Make the Minimal Change (About 2 Minutes)

The most common pitfall when fixing stubborn defects is “refactoring along the way.” Explicitly constrain this in the prompt:

• Only change code directly related to the root cause;
• Do not introduce new dependencies;
• Do not change public interface signatures;
• Preserve the existing error-handling style.

The value of a minimal change is that it is verifiable, rollback-friendly, and reviewable. A patch spanning a dozen files, even if it fixes the bug, places a huge burden on code review.

3.4 Stage Four: Close the Verification Loop (About 2 Minutes)

After the modification is complete, verification must be performed. Verification methods ranked by reliability:

1. Automated tests pass (highest reliability);
2. The reproduction script no longer triggers the problem;
3. Regression tests for related modules pass;
4. Manual confirmation of boundary scenarios.

Feed the verification results back to the model. If verification fails, attach the error output and let it continue iterating. This loop usually converges within one or two rounds.

3.5 Paradigm Summary

Stage	Goal	Time Share	Failure Signal
Problem formalization	Eliminate ambiguity	20%	Model repeatedly asks for details
Reproduction reasoning	Confirm root-cause direction	30%	Reproduction path mismatches observations
Minimal change	Control risk	25%	Changes touch unrelated modules
Verification loop	Confirm the fix	25%	Regression tests fail

The value of this paradigm is not “speed” but turning an uncontrollable troubleshooting process into a repeatable workflow. Once the workflow is solidified, delivery quality is more stable regardless of which model is used.

4. Front-End Landing Page Scenarios: From Description to Runnable Code

Besides troubleshooting, another high-frequency scenario is rapidly producing runnable front-end pages. The evaluation criteria for these tasks differ from those above, focusing on:

• Structural completeness: is there a clear layout hierarchy;
• Responsive handling: behavior across different viewports;
• Maintainability: are styles and logic separated.

In practice, breaking requirements into three layers—“structure, style, interaction”—and presenting them separately works better than describing the entire page effect at once. Example prompt structure:

Please generate a landing page with the following requirements:
Structure: top navigation + hero section + three feature cards + footer
Style: use flexbox layout, cards stack on narrow screens
Interaction: navigation bar fixed on scroll
Output: a single HTML file with inline styles and scripts

The benefit of layered description: the model won’t get stuck on style details prematurely before the structure is settled, making output quality more controllable.

5. Three Practical Principles for Cost Control

Returning to the two calculations from the beginning, there are three actionable principles for implementation.

Principle One: Route by complexity. Divide tasks into three categories—formatting adjustments, logic modifications, and root-cause troubleshooting. The first two go through the low-cost channel; only the third consumes strong-reasoning resources.

Principle Two: Use caching to dilute long-context costs. For frequently referenced codebases, prioritize solutions that support context caching to avoid full re-uploads every time. The optimization potential here is often greater than switching models.

Principle Three: Maintain a unit delivery cost ledger. Track tool spending and valid deliveries monthly to form a trend curve. When the curve flattens or rises, the current configuration has hit a bottleneck—then consider adjusting strategy.

6. Conclusion

The real value of AI coding tools is not how much code they can generate, but whether they can be embedded into an engineering process that is measurable, reproducible, and cost-controllable. Long-context capability makes it possible to “hand the entire codebase to the model,” terminal-constrained task ability makes it possible to “locate problems when information is incomplete,” and a reasonable billing structure makes all of this sustainable within a limited budget.

For developers, mastering this methodology has more long-term value than chasing the parameters of any single tool. Because tools will change, but workflows and judgment will accumulate.