Low-Budget AI Coding: A Complete Guide to Fixing Stubborn Bugs in 9 Minutes

1. Solo AI Collaboration: The Only Two Metrics That Matter

Over the past 3 months, working solo with multiple AI models, I completed approximately 270,000 lines of code and nearly 3,000 commits. My annual budget for AI tool subscriptions and API calls was around 17,000 RMB. Behind these numbers, I rely on only two metrics to measure the true value of AI coding:

1. Token Billing Cost: How much it costs to run the same task end-to-end. This determines whether you “dare to use it freely.” If the cost model is unclear and you wince at every API call, collaboration efficiency will inevitably plummet.
2. Real-World Engineering Delivery Rate: Facing a vaguely described engineering problem, can the AI actually fix it without endless rework? This determines whether you “can trust it.” Generating code quickly means nothing if it can’t fix production issues; otherwise, it’s just demo material.

The best touchstone for the second metric isn’t having the AI write a new page, but fixing a legacy bug that defeated multiple models. In a recent troubleshooting session, from handing the prepared task package to the model, to reproducing, locating, modifying, and passing regression validation, the entire process took about 9 minutes. I didn’t write a single line of code manually.

Conclusion: During these 9 minutes, model capability matters, but what truly determines success is the organization of the task package and the validation loop. Let’s break down the entire chain.

2. Why Stubborn Bugs Are the Ultimate Test of AI Coding

• Writing new code is a “generation” problem; troubleshooting is a “solving” problem. Generation relies on common patterns. Troubleshooting requires reproducing, observing, hypothesizing, falsifying, and re-hypothesizing—a standard scientific method流程 that demands an order of magnitude higher reasoning chain and tool-calling capabilities.
• Troubleshooting has an objective referee. Whether tests pass or error logs disappear are machine-verifiable signals. They objectively distinguish “actual delivery” from “looks like delivery,” preventing you from being misled by fluent phrasing.
• Troubleshooting tests context management. Stubborn bugs often span multiple modules, requiring reviewing extensive historical code and logs. A long context window paired with a sound retrieval strategy directly dictates localization efficiency.

My legacy bug was a classic example: harsh reproduction conditions, error messages far from the root cause, and multiple modules involved. Previous models either treated the symptoms or made overly broad changes that triggered new issues. Achieving a 9-minute closure this time was half due to the model’s reasoning and terminal execution capabilities, and half due to the engineering quality of the task package.

3. Selection Methodology: Three Dimensions That Impact Delivery

Comprehensive scores from independent evaluation agencies are good for initial screening to weed out incapable models. However, as an independent developer, I recommend looking directly at three evaluation dimensions closer to real-world engineering:

1. Long-Cycle Continuous Coding: Does the model experience goal drift, forget constraints, or reintroduce previously fixed bugs during multi-turn continuous modifications? This is the baseline for the daily “change one thing, run, change the next” rhythm.
2. Agentic Autonomous Execution: Can the model decompose tasks independently, decide the next action, call tools (read files, execute commands, check logs), and adjust its strategy after failure, rather than stopping and waiting for human instructions upon encountering setbacks?
3. Real Terminal-Restricted Tasks: How accurately can the model execute commands, parse output, and correct commands in a restricted environment? This is the core capability for troubleshooting scenarios and the dimension where the gap between model generations is most apparent.

From a technical perspective, new flagship models generally adopt the Mixture of Experts (MoE) architecture: total parameters reach the trillion scale, but only a small fraction (often less than a tenth) is activated during a single inference. The engineering significance of this design is the decoupling of model capacity and inference cost—providing context windows of hundreds of thousands to millions of tokens at a controllable cost, making “whole-repository ingestion” possible.

However, two caveats must be noted:

• Long context does not equal good understanding. A million-token window solves “fitting it in,” not “finding it accurately.” Hierarchical retrieval and on-demand loading perform far better than blindly stuffing the entire repo.
• A few points difference on a leaderboard doesn’t mean a capability gap. Different evaluations have varying criteria. The most reliable method is to build a private benchmark task set using two or three real tasks from your own project.

4. Getting the Token Math Right: The Independent Developer’s Cost Model

An independent developer’s AI expenses usually consist of two bills: Subscription fees (fixed cost) + API pay-as-you-go (variable cost). The key to controllability lies in the latter. There are three universal industry rules for token billing:

1. Input and output are priced separately, with output typically costing several times more—because generating tokens token-by-token is far more compute-intensive than understanding them.
2. Cache hits significantly reduce prices—recurring system prompts and project context are usually billed at around a 10% discount.
3. Troubleshooting tasks have a much larger input volume than output volume—reading code and logs makes up the bulk of input, while the actual modification is often just a few lines.

Here is an illustrative estimate (numbers are hypothetical, purely demonstrating the algorithm, and do not represent any product pricing): Assume a model charges 10 RMB/million tokens for input, 1 RMB/million for cache hits, and 60 RMB/million for output. A medium-scale troubleshooting task accumulates about 800,000 input tokens (700,000 hitting the cache) and 30,000 output tokens. The cost would be:

Cost ≈ 0.7M × 1 RMB + 0.1M × 10 RMB + 0.03M × 60 RMB
     ≈ 0.7 + 1.0 + 1.8 ≈ 3.5 RMB / session

Running this 10 times a day results in a monthly cost in the thousand-RMB range, and thousands annually. This is why an annual budget in the ten-thousand-RMB range is sufficient to support high-intensity solo collaboration.

Three practical tips for saving money:

• Stable Prefixes: Place system prompts, project descriptions, and coding standards at the very beginning of the session and keep them unchanged to maximize cache hits.
• Control Output: Explicitly request “output only the diff” or “output only the key function.” Output is the most expensive part of the bill.
• Hierarchical Scheduling: Delegate simple completions and format conversions to lightweight models. Only invoke flagship models for complex troubleshooting and architectural decisions.

Additionally, if regression tests and build pipelines need to run in the cloud, you can utilize container platforms, logging, and general monitoring services from public cloud providers (e.g., Baidu AI Cloud offers corresponding general categories) to factor environment costs into the total bill.

5. The Six-Step Engineering Loop for a 9-Minute Closure

Step 1: Prepare a Reproducible Environment. A minimal reproduction script is the prerequisite for everything:

# scripts/repro.sh — Stably reproduce the target bug
./scripts/repro.sh   # Expected: Error X occurs, non-zero exit code

If the bug cannot be stably reproduced, solve that first. This isn’t AI’s job; it’s engineering debt you must clear yourself.

Step 2: Package the Task (The Most Critical Step). Recommended template:

[Symptom] Performing operation A results in error B. Full error in logs/error.log
[Expected] Correct behavior should be C
[Reproduce] Run ./scripts/repro.sh
[Validation] Run ./scripts/test.sh. Passing all tests means fixed
[Relevant Files] src/module_a, src/module_b (attach key snippets)
[Constraints] Only minimal modifications allowed; refactoring unrelated code is prohibited

Step 3: Restate Before Acting. Require the model to output its “understanding of the problem + three candidate hypotheses + required validation evidence for each.” Authorize execution only after confirming there is no deviation in understanding. This step filters out 80% of directional errors.

Step 4: Authorize Execution and Bisection Localization. Allow the model to run the reproduction script, check logs, and execute tests. Encourage it to use bisection to narrow down the suspicious interval. Observe whether it “systematically eliminates” or “randomly guesses.” This is the most intuitive signal of a model’s troubleshooting capability.

Step 5: Minimal Modification + Regression Validation. Require a minimal diff output. Run targeted tests first, then full regression. Validation relies solely on test results, never on “the model said it’s fixed.”

Step 6: Review and Archive. Write the root cause, fix strategy, and impact scope into commit messages and project documentation. This archiving acts as cache-friendly context in future sessions, further driving down costs.

6. Five Common Pitfalls and Countermeasures

1. Needle in a Haystack Failure: Cramming the context too full makes it harder to find key information. Countermeasure: Hierarchical loading. Provide directory structures and interface signatures first, and load implementation details on demand.
2. Overly Broad Changes: The AI “optimizes” unrelated code along the way. Countermeasure: Hardcode the modification boundaries in the task template and only review the diff.
3. Hallucinated Interfaces: The model calls non-existent APIs. Countermeasure: Put real API documentation snippets into the task package; don’t let the model guess from memory.
4. Missing Referee: Without automated tests, the AI self-validates. Countermeasure: Write a failing test for the bug first; turning it green after the fix is the anchor of the entire loop.
5. Cost Overrun: A task runs for dozens of rounds. Countermeasure: Set limits on rounds and token budgets. If exceeded, intervene manually and decompose the task again.

7. Conclusion: From “Writing Code” to “Delivering Engineering”

The evaluation standard for AI coding is shifting from “generation speed” to “delivery rate.” Pushing a vague engineering problem to “all tests green, minimal changes, complete documentation” is what counts as true delivery. I recommend every developer build their own private benchmark task set—two or three stubborn bugs from real projects, paired with auto-runnable validation scripts. This is the most honest evaluation, and the closest to your business needs. A small budget is never the limit, provided you truly think through the cost model and engineering loop.