LLM-Assisted Debugging in Practice: An Engineering Path to Fixing a Stubborn Defect in Nine Minutes

1. Background and Problem Breakdown

A self-developed content distribution tool had a long-standing defect that was difficult to locate. It only appeared under specific data patterns and specific scheduling timing, manifesting as intermittent dispatch interruptions without any clear exception stack in the logs. Earlier attempts using general-purpose code assistants and conversational models mostly produced patches that looked reasonable but did not actually work — either the fix was applied at the wrong call layer, or it introduced new null-pointer risks under boundary conditions.

The core of this type of problem is not whether a model can write code. It comes down to whether three engineering conditions are met at the same time:

1. Is the context complete? The defect spanned three modules: data parsing, task scheduling, and state persistence. Any single-file snippet was insufficient to reconstruct the real call chain.
2. Are the constraints explicit? The prompt had to specify immutable interface contracts, existing error-handling conventions, and the acceptance criteria for regression verification.
3. Is verification executable? The fix had to be validated by scripts rather than manual inspection.

Long-context capability addresses the first condition, while structured prompting and executable verification address the second and third. The following sections follow the actual execution order.

2. Task Framing: How to Structure a High-Precision Fix Request

2.1 Layered Context Provisioning

Do not dump the entire repository into the prompt at once. A more effective approach is to organize the context into three layers: contract, implementation, and verification.

• Contract layer: external interface signatures, data structure definitions, and configuration descriptions.
• Implementation layer: the files likely involved in the call chain, ordered by call sequence.
• Verification layer: existing unit tests, minimal reproducible input samples, and expected outputs.

With models that support context windows in the million-token range, this layered provisioning can be done in a single pass without repeated trimming. In practice, it helps to explicitly mark the boundary of each layer in the prompt, for example by using comment separators:

# === Contract layer ===
# Data structures: TaskSpec / DispatchResult
# Immutable: dispatch(task: TaskSpec) -> DispatchResult
# === Implementation layer ===
# Call order: parser -> scheduler -> state_store
# Focus: scheduler branches for empty queue and retry state
# === Verification layer ===
# Repro input: fixtures/edge_case_07.json
# Acceptance criteria: dispatch returns status=OK and state_store has no leftover PENDING records

The purpose of layering is to reduce attention drift in the model, ensuring it respects the contract first, then locates deviations in the implementation, and finally cross-checks against the verification layer.

2.2 Write Down What Not to Do

For fix-oriented tasks, negative constraints are often more important than positive descriptions. It is worth explicitly listing:

• Do not modify external interface signatures or serialization formats.
• Do not swallow exceptions; preserve the existing error-code system.
• Do not introduce new third-party dependencies.
• Limit changes to the specified modules; any cross-module change must be justified separately.

These constraints significantly reduce the common failure mode of refactoring half a module just to fix one defect.

3. The Actual Execution Path Within Nine Minutes

From pressing enter to passing verification, the whole process can be divided into four stages, with the approximate time distribution as follows:

Stage 1: Defect reproduction and attribution (about 2 minutes)

The model reads the reproduction sample from the verification layer, cross-references it with the implementation-layer call chain, and produces a causal description of the trigger condition: after the retry counter reaches the threshold, the scheduler writes the task state back to pending, but the state storage layer uses a non-idempotent write operation, causing the same task to be enqueued repeatedly and creating a race with the queue-empty check. The output of this stage is not code but a verifiable causal chain — the basis for all subsequent changes.

Stage 2: Patch generation (about 3 minutes)

Based on the attribution, the model proposes two changes: first, make the state write-back idempotent with a version-number check; second, add deduplication of repeated task identifiers at the scheduling entry point. The changes are presented as a minimal diff, with each modification annotated against the corresponding constraint item for easy review.

Stage 3: Regression verification (about 3 minutes)

Run the existing unit tests and the reproduction sample, and add two boundary cases: concurrent duplicate enqueueing and rollback after a state-write failure. The acceptance criteria for the verification script were already defined in Stage 1, so this step is purely mechanical execution without human judgment.

Stage 4: Change review (about 1 minute)

A quick manual review of the diff focuses on three points: whether the contract layer was touched, whether exceptions were swallowed, and whether dependencies were introduced. Because the constraints were established up front, this step usually requires confirmation rather than rework.

It should be emphasized that “nine minutes” does not mean skipping review. What it saves is time spent on localization and trial-and-error. The review step is the necessary cost of making the fix trustworthy.

4. Cost Structure: How to Make Trade-offs on a Limited Budget

With an annual budget in the range of roughly 17,000 RMB, the key to cost control is not the unit price of a single call, but the product of call frequency and context size. Several practical strategies are available:

First, choose model tiers by task type. Defect localization and cross-module refactoring are high-complexity tasks that justify a long-context, strong-reasoning configuration. Formatting, comment completion, and unit-test boilerplate generation are low-complexity tasks that can use a lightweight configuration. Concentrating premium resources where they are truly needed is the first principle of budget allocation.

Second, cache and reuse context. Multiple interactions on the same module should reuse an established context prefix rather than repeatedly feeding the same files. Most service-side interfaces have optimization potential for repeated prefix computation, and engineering should take advantage of this.

Third, measure efficiency by verification pass rate rather than call count. One high-quality long-context call often outperforms five short-context trial-and-error attempts. It is worth tracking the ratio of “calls per verified pass” for each task and using it to refine prompting strategy.

Fourth, move automated verification earlier in the process. The more complete the verification scripts, the higher the probability that the model succeeds on the first attempt and the less rework is needed. This investment is one-time, but the return grows linearly with the number of tasks.

5. Extending from Defect Fixes to Page Delivery

The same methodology can be applied to delivery-oriented tasks such as front-end landing pages, but with a different emphasis:

• Defect fixing focuses on causal attribution and minimal changes. Prompts should reinforce constraints and verification.
• Page delivery focuses on structure and maintainability. Prompts should specify component boundaries, style conventions, responsive breakpoints, and accessibility requirements.

For example, when generating a page skeleton, first require a structural description and component breakdown, then generate the implementation block by block, and finally run build and static checks uniformly. This “structure first, implementation second” sequence effectively avoids generating a large volume of hard-to-maintain code in one shot.

# Example of staged constraints for a page task
Stage 1: Output the information architecture and component tree; no implementation
Stage 2: Generate each block by component tree, with style conventions attached
Stage 3: Run build and static checks; output a list of issues
Stage 4: Make targeted fixes only for the issue list

The value of staging is that it breaks a large generation task into reviewable small steps, each with a clear completion criterion.

6. Quality Verification: A Step That Cannot Be Skipped

Regardless of model performance, the following checks should be part of the fixed process:

1. Contract check: whether interface signatures, data formats, or error codes have changed.
2. Behavior check: whether reproduction samples and boundary cases pass.
3. Dependency check: whether undeclared dependencies or version changes were introduced.
4. Security check: whether inputs are unvalidated or sensitive fields leak into logs.
5. Readability check: whether the changes include necessary comments and change descriptions.

These five checks can be scripted or turned into a review checklist. Their shared purpose is to turn the model’s probabilistic output into deterministic engineering delivery.

7. Summary

The value of large language models in programming scenarios is not to replace developer judgment, but to compress the cycle of “localization, trial-and-error, and verification.” For that compression to happen reliably, three preconditions are required: complete context organized in layers, explicitly declared positive and negative constraints, and automatable verification criteria. When all three are in place, a defect that has lingered for weeks can complete the fix loop within ten minutes. When any one is missing, even the strongest model can only produce patches that look plausible.

For independent developers with limited budgets, the sensible approach is to reserve premium resources for high-complexity tasks, treat verification scripts as long-term assets that deserve ongoing investment, and measure tool-chain efficiency by verification pass rate rather than call count. This methodology does not depend on a specific product or a specific leaderboard score — it depends on engineering discipline itself.