AI Coding Methodology: Low-Cost Strategies for Fixing Stubborn Bugs

1. The Reality of AI Coding for a Solo Developer

Over the past three months, acting as a solo developer, I collaborated with multiple AI models to write 270,000 lines of code and complete nearly 3,000 commits, with an annual spend of about 17,000 RMB on various AI tool subscriptions. Operating this “one-person company” delivery system has led me to a core principle: evaluate models based on two ledgers.

The first is the token billing cost. Subscription fees and API bills are explicit expenses that directly determine the break-even point of this system.

The second is the actual delivery rate of engineering troubleshooting. No matter how high a model scores in benchmarks, if it repeatedly provides patches that “look correct” but fail to fix a persistent bug, the money saved on tokens will be lost in troubleshooting time.

In other words, independent developers do not need the “strongest model”; they need the “model with the highest delivery rate per unit cost.” Centered on this goal, the following sections break down the methodology into four dimensions: selection, troubleshooting, delivery, and cost.

2. Selection Methodology: Evaluating Coding LLMs from an Engineering Perspective

2.1 Comprehensive Benchmarks are Entry Tickets, Specialized Coding Benchmarks are the Main Test

Comprehensive benchmark lists from third-party evaluation institutions reflect a model’s overall proficiency, but for developers, the specialized capabilities in coding and command-line operations dictate the daily experience. When evaluating, it is recommended to focus on three types of benchmarks:

• Long-horizon continuous coding: Simulates writing code continuously in a real repository over a long period, testing cross-file understanding and stability after multiple rounds of modifications. This is a direct indicator of whether a model will “make things messier the more it edits.”
• Terminal-constrained tasks: Places the model in a real command-line environment with only terminal access, testing its ability to locate problems, execute commands, and self-correct based on feedback. This corresponds to daily Ops and troubleshooting scenarios.
• Comprehensive agentic tasks: Tests the model’s closed-loop capability to autonomously plan, call tools, and verify results, corresponding to automated workflow scenarios.

New generation models generally adopt the Mixture of Experts (MoE) architecture, activating only a portion of parameters each time to trade for stronger capabilities while controlling inference costs. Some vendors also promise open-source full weights, which serves as a bonus point if private deployment is required.

However, it must be emphasized: benchmark scores are just entry tickets. Domain terminology, architectural conventions, and historical legacy of private codebases cannot be covered by any public benchmark. Use the lists to narrow down candidates, but the final decision must be based on real-world testing with your own project.

2.2 Calculating the Three-Part Token Bill

Regardless of which model service you choose—including model services provided by domestic cloud platforms like Baidu AI Cloud—the API billing structure is largely similar and consists of three parts:

Total Cost ≈ Input Tokens × Input Unit Price
           + Output Tokens × Output Unit Price
           + Cache Hit Tokens × Cache Unit Price

Using typical magnitudes as an illustration (not an actual quote for any specific product): assume Input at 10/1M Tokens, Output at 60/1M Tokens, and Cache Hit at 1/1M Tokens. If a session consumes 100,000 input tokens (of which 80,000 hit the cache) and 20,000 output tokens, the cost would be approximately: 0.2 + 0.08 + 1.2 ≈ 1.48. Two conclusions can be drawn:

1. Output is the bulk of the cost; making the model “say less nonsense and give the diff directly” saves money.
2. The cache hit price is usually about one-tenth of the input price; how you organize the context directly determines the thickness of your bill.

Regarding procurement models: capped subscriptions suit heavy daily use, while pay-as-you-go APIs suit sudden batch tasks. A hybrid of the two is often the optimal solution for independent developers.

2.3 Long Context: From “Pasting Snippets” to “Reading the Whole Repo”

Current mainstream models generally possess context windows ranging from hundreds of thousands to millions of tokens, bringing a qualitative change to coding workflows:

• Whole-repo reading: Small to medium repositories can be fed in at once, allowing the model to understand module dependencies from a global perspective rather than guessing from fragments.
• Cross-file tracing: The root cause of a bug might be scattered across configurations, middleware, and utility functions across three layers. Long context allows the model to “see” multiple evidence points simultaneously.
• Docs and code in the same window: API documentation and design specs can be reasoned alongside the code, reducing misunderstandings.

However, be aware of the “effective context” issue: a large nominal window does not mean evenly distributed attention. In practice, place the most critical information (error stacks, reproduction steps, core files) at the beginning or end of the context, fill the middle with secondary materials, and regularly prune irrelevant historical dialogue.

3. Case Study 1: Fixing a Persistent Bug in Nine Minutes

3.1 Scenario and Difficulties

A self-developed content distribution tool had a persistent bug: tasks would silently fail under specific conditions, with no explicit exceptions thrown in the logs. Previously, I tried several models, which all provided localized patches like adding null checks or wrapping exception catches, but the problem kept recurring.

3.2 Four-Step Chain: From Hitting Enter to Passing Validation

This time, I handed the task entirely to a tier-one coding model. The whole process took about nine minutes, during which I did not write a single line of code. The workflow breaks down into four steps:

Step 1: Feed sufficient context. Do not just throw “help me fix this bug.” Provide four types of materials: reproduction steps, complete error logs and call stacks, suspected related module files, and the expected correct behavior.

Step 2: Translate the repair task into executable instructions. An example template is as follows:

[Role] You are a senior engineer responsible for this repository.
[Background] This is a historical bug in <module name>: <one-sentence description of the phenomenon>.
[Materials] Attached: reproduction steps, complete logs, related files <path list>.
[Requirements]
1. First, provide a root cause hypothesis and point out the code evidence supporting the hypothesis (file + line number);
2. Write a minimal reproduction case that fails on the current code;
3. Provide a minimal change fix; do not refactor opportunistically;
4. Run the reproduction case and related regression tests; output the diff only after all pass.

Step 3: Reproduce first, then locate, then modify. Forcing the model to write a reproduction case first is a critical step: it turns “verbal analysis” into “executable evidence,” mechanically preventing the model from directly altering code based on a misjudged root cause.

Step 4: Small-step modifications plus regression validation. The fix lands as a minimal diff. Commit only after the reproduction case and existing tests pass, keeping the whole process rollbackable.

3.3 Retrospective: Why It Worked This Time

In retrospect, the fundamental reason for previous failures was not that the “model wasn’t smart enough,” but the task structure: this bug’s root cause spanned three files—an unrestored state in an asynchronous callback, an inconsistency between a configuration default and the documentation, and a silent error swallowing during a failed retry. With short context, each view only saw a part, naturally leading to localized patches. The combination of long context and strong reasoning allowed the model to see all three evidence points simultaneously for the first time, shifting root cause localization from guesswork to deduction. This validates the earlier judgment: the upper limit of troubleshooting delivery rate often depends on the quality of context organization, rather than simply piling on model parameters.

4. Case Study 2: Rapid Delivery of a Frontend Landing Page

Beyond troubleshooting, frontend landing pages are another high-frequency task. The output quality of AI equally depends on how the task is organized:

1. Structured requirement description: Translate “make a landing page” into information architecture—target audience, conversion goals, section list, brand colors, and font constraints. The model receives a specification, not a wish.
2. Component-based splitting: Have the model generate blocks sequentially—Navbar/Hero/Features/Testimonials/FAQ/Footer—instead of generating the entire page at once, facilitating block-by-block acceptance and rework.
3. Screenshot feedback loop: Feed the rendered screenshot back to the model for a visual walkthrough, pointing out spacing, alignment, and hierarchy issues. Usually, two to three rounds achieve a deliverable standard.
4. Delivery baseline self-check: Responsive breakpoints, accessibility (semantic tags, contrast ratio), and above-the-fold bundle size. These three items must be on the fixed acceptance checklist to prevent “seemingly working pages” from going live with issues.

5. Engineering Guardrails: Making Generated Code Controllable and Rollbackable

Once AI reduces coding costs to an extreme low, the bottleneck shifts to engineering discipline. Three guardrails are indispensable:

• Version control discipline: Every AI modification gets its own branch, small-step commits, and complete commit messages, ensuring any generation can be independently rolled back.
• Testing guardrails: Do not let AI make major changes to a codebase without tests. Have the model first supplement unit tests for core paths, then open up refactoring and bug-fixing tasks, letting the regression suite act as the “judge of generated code.”
• Human review fallback: Security-related logic, authentication and payments, and data deletion operations must be confirmed line-by-line by a human. The model is responsible for output; humans are responsible for the boundary of accountability.

Furthermore, precipitate prompts for high-frequency tasks into team assets—task templates, acceptance checklists, and code specification documents. This way, even if a new generation of models is adopted in the future, the migration cost is merely “swapping the engine” itself.

6. Cost Control: Making the Most of a Modest Budget

• Task grading: Assign scaffolding, boilerplate code, and unit test generation to cost-effective tier models; assign architectural design, difficult troubleshooting, and security reviews to tier-one models.
• Cache-friendly: Place stable system prompts and code standards at the front of the context and keep them unchanged. The higher the cache hit ratio, the thinner the bill.
• Say it clearly once: Multiple rounds of low-quality back-and-forth are the biggest cost black holes. Spending two extra minutes on task description can save ten rounds of exchanges.
• Budget monitoring: Set up token usage tracking and alerts by project, making every expense attributable and optimizable.

7. Conclusion

Model capabilities leap forward with every generation, but the methodology remains stable: use specialized coding benchmarks and private code testing for selection, structured tasks and verification loops for execution, testing and reviews for guardrails, and caching plus task grading for costs. Once these elements are in place, “fixing a stubborn bug in nine minutes” is no longer an occasional surprise, but a reproducible daily delivery standard for a solo developer.