Fixing a Stubborn Bug in 9 Minutes with an AI Coding Assistant: A Full Breakdown

1. Background: An Intermittent, Long-Standing Bug

While maintaining an in-house content distribution tool, I encountered a classic legacy bug. It was intermittent, hard to trigger, and involved complex state interactions across multiple modules. Previous attempts to use various AI models to assist in troubleshooting had failed to resolve it completely. These types of bugs typically share the following characteristics:

• Difficult to reproduce consistently, with limited log information.
• Long call chains, making it hard to build a holistic understanding by reading code at a single point.
• Layers of compatibility logic from previous patches masking the true root cause.

Recently, I handed this long-pending task entirely to an AI coding assistant for a real-world test. From hitting enter to reproduction, modification, and final verification, the entire process took about 9 minutes, and I did not manually write a single line of code. This article provides a complete retrospective of this process, methodology, and cost assessment for developers facing similar challenges.

2. Preparation: Context Engineering is Key

The upper limit of an LLM’s ability to fix bugs depends heavily on the quality of the context provided. Before starting, I did three things:

1. Define the problem boundary: I organized the symptoms, trigger frequency, and impact scope into a clear description, specifying “what operation, under what conditions, what the expected behavior is, and what the actual behavior is.”
2. Gather key evidence: This included full error logs, stack traces, relevant configuration snippets, and the differences between the most recent successful and failed runs.
3. Specify code entry points: Instead of feeding the entire repository to the model, I only provided the module paths and function entry points most relevant to the problem, helping the model quickly narrow its search scope.

The essence of this phase is “context engineering.” The model cannot read minds; the developer’s structured expression of the problem directly determines the efficiency of root cause analysis.

3. The Workflow: A 4-Step Process

The 9-minute fix can be broken down into four phases:

1. Reproduction & Hypothesis Generation (approx. 2 minutes): Based on the logs and code context, the model provided two or three possible cause hypotheses. It also proactively asked about a boundary condition that had been previously overlooked—which later proved to be the key clue to solving the problem.
2. Root Cause Localization (approx. 3 minutes): The model traced the call chain layer by layer and finally pinpointed a state race condition in an asynchronous callback. A specific flag was not being reset under a certain timing sequence, causing the subsequent distribution logic to enter the wrong branch. These types of timing issues are exactly what human troubleshooting tends to miss most easily.
3. Patch Generation (approx. 2 minutes): The model’s modification was highly restrained. Instead of a massive refactor, it added timing guarantees for state resetting and included a defensive log. An example is shown below:

# Before fix: flag was only reset on the success path
if dispatch_ok:
    self.pending = False
# After fix: reset uniformly when exiting the dispatch flow, regardless of success or failure
try:
    self._do_dispatch(task)
finally:
    self.pending = False
    logger.debug("dispatch state reset, task_id=%s", task.id)

1. Verification Loop (approx. 2 minutes): I replayed the operation using the original trigger path, and the issue no longer occurred. After confirming that existing tests for related modules passed with no side effects, the code was merged.

4. Retrospective: Why It Succeeded This Time

The success of this fix was not accidental, but the result of three converging conditions:

• Highly accurate context: With clear goals and complete evidence, the model didn’t need to “guess” within a sea of irrelevant code.
• Model-led investigation, human-led confirmation: In past failed attempts, I often brought preset conclusions for the model to “validate,” which actually constrained the search space. This time, I used open-ended questioning, allowing the model to step outside conventional thinking patterns.
• Restrained modifications: An excellent patch minimizes the surface area of changes. This is a crucial standard for evaluating model output quality—the larger the change, the higher the risk of introducing new issues.

5. Cost-Benefit Analysis

Based on my usage intensity over the past three months, an AI coding assistant has helped generate and iterate approximately 270,000 lines of code, with an annual tool budget of about 17,000 RMB. Factoring this in, the time to fix these difficult bugs has been compressed from half a day to several days down to the minute level. For independent developers and small teams, this investment yields not just faster fixes, but the opportunity cost of redirecting focus toward architecture design and product refinement. Of course, budget planning should rationally evaluate your own codebase size and usage frequency, choosing on-demand rather than blindly pursuing high quotas.

6. Reusable Best Practices

Drawing from this and previous experiences, here are some key takeaways:

• Organize context before prompting; description quality dictates fix quality.
• For intermittent issues, guide the model to prioritize analyzing timing, state, and concurrency factors.
• Explicitly request minimal patches, supplemented with defensive logs and unit tests.
• Always retain a human verification step; automated testing is the last line of defense.
• Document the resolution process of typical bugs to feed back into the team’s knowledge base, preventing recurring efforts on the same issues.

7. Conclusion

AI coding assistants are freeing developers from tedious troubleshooting, but they ultimately amplify the user’s engineering judgment. Those who know how to ask questions, provide context, and verify results are the ones who truly capture this efficiency dividend. Stubborn bugs are not intimidating; what is intimidating is the lack of a structured problem-solving workflow. By solidifying this workflow, the continuous evolution of these tools will only make the process run faster and faster.