AI Coding in Practice: How a One-Person Team Uses LLMs to Fix Stubborn Bugs and Cut Development Costs

For solo developers and small teams, engineering productivity no longer depends simply on how fast you can write code. It shows up far more in the maintenance cost of legacy code, the ability to locate vague problems, and how quickly you adapt to a complex engineering environment. Over the past three months, working alone alongside multiple AI coding assistants, I delivered roughly 270,000 lines of code and made nearly 3,000 commits, while my total annual spending across all AI tool subscriptions came to about RMB 17,000. Behind this one-person delivery setup, I judge models on two ledgers: the direct cost of token billing, and the delivery success rate in real engineering troubleshooting. The second usually matters more than the first when deciding whether a tool deserves long-term reliance.

1. Selection Logic: A Dual Yardstick of Cost and Efficiency

For budget-constrained personal or small commercial projects, model selection shouldn’t blindly chase whatever is newest. If you only watch leaderboard scores and ignore actual token consumption and fix success rates, it’s easy to fall into a “high intelligence, low output” trap. My screening criteria come down to three dimensions:

1. Value per token: how much effective code logic or root-cause conclusion each unit of API spending actually buys;
2. Adaptability to an existing codebase: whether the model can quickly grasp established code style, dependency relationships, and implicit business constraints;
3. Long-context and tool-calling stability: whether it can maintain reasoning consistency when the context is packed with logs, stack traces, and cross-file references.

Recently, a cloud vendor released an LLM coding product built on a mixture-of-experts architecture, and its performance in long-context windows, code generation, and terminal operation tasks caught my attention. The product claims to accept context input at the million-token level, meaning an entire large code repository or a lengthy system log can be fed into the model in one piece, without constant segmentation or summarization. For complex defect investigation, this carries real engineering value: the root causes of many stubborn bugs hide in non-obvious interactions between modules, and only when the full context is preserved does the model get a chance to make an accurate call.

2. Cost Model in Practice: A Fine-Grained Breakdown of the API Bill

For a solo developer, the granularity of cost control directly determines whether the business model closes the loop. Take this product as an example: its public pricing shows the standard input price at roughly RMB 13 per million tokens, dropping to RMB 1.3 per million tokens on a cache hit, with output at RMB 68 per million tokens. Compared with the previous generation, overall invocation cost fell by about one third. That matters enormously for high-frequency iteration—when daily usage runs in the hundreds of thousands of tokens, the savings show up directly on the monthly bill.

In practice, I’ve distilled three key techniques for cutting token consumption:

• Cache-first strategy: For codebase fragments that are read frequently but rarely change (interface definitions, collections of utility functions), prefix caching or prompt reuse can dramatically reduce repeated billing.
• Staged task decomposition: Don’t submit a pile of unrelated tasks to the model at once. Splitting bug localization, solution generation, and code modification into three separate sessions, each carrying only the necessary context, meaningfully improves token utilization.
• Output length constraints: Telling the model to “output only the modified function” or “return only the key error log lines” keeps responses short and avoids redundant explanations.

Combined, these measures keep the token cost of a medium-complexity bug fix (scanning roughly 2,000 lines of code) to a few RMB up to a dozen or so—a decisive cost advantage over traditional outsourcing or hours of manual investigation.

3. Case Study: Fixing a Months-Old Bug in 9 Minutes

To probe the model’s limits in a real engineering environment, I handed it a stubborn defect that had been sitting in my self-built content distribution module for months. The symptom: under specific concurrency conditions, the task queue occasionally deadlocked, pushing distribution latency past 10 seconds. Several other models had failed to locate the root cause, and manual investigation had burned hours without a lead.

3.1 Task Submission and Context Preparation

I organized the core clues into a snippet of about 500 lines and pasted it into the session together with the exception logs, key variable definitions, and the comments related to concurrency control. No extra explanation, no prompt-engineering polish—I relied entirely on the model’s grasp of code semantics. From hitting Enter to the first actionable fix suggestion took about two minutes.

3.2 Root Cause Analysis and Solution Generation

The model didn’t jump straight to “change this line.” It first untangled the timing logic behind the deadlock, concluding that the problem likely lay in inconsistent acquisition order between two mutexes, combined with a condition variable whose wakeup signal could be lost under a particular race. That conclusion pointed in a completely different direction from earlier manual analysis, which had concentrated on connection-pool timeout settings. By cross-checking the timestamp sequence in the logs against the code’s execution paths, the model reconstructed the actual chain that triggers the deadlock.

3.3 Patch and Verification

The model then produced the fix: reorder the lock acquisitions and add a timeout-protected path for the condition variable. I applied the patch to a test branch and ran the concurrency stress-test script—three consecutive rounds with no recurrence of the deadlock. From submitting the task to completing verification took about nine minutes, and I wrote not a single line of code myself.

The core takeaway of this case: on complex engineering problems, an LLM’s value isn’t just “generating code”—it’s “offering a second perspective.” Unconstrained by existing mental ruts, it can leap across the data flow and control flow to reconstruct the full picture, which is especially precious when manual investigation has run out of steam.

4. Front-End Delivery: Building a Landing Page from Scratch

Beyond bug fixing, AI coding tools deliver comparable gains in front-end work. Take the landing page for a content distribution tool: I fed the model the design’s text descriptions, brand color values, and responsive breakpoint requirements. Without hand-writing any HTML, CSS, or JavaScript, the model generated a complete page skeleton including interaction effects, progressive loading, and basic SEO tags.

During generation, the model made two optimizations I never explicitly requested: it generated lazy-loading logic based on image asset dimensions, and it adopted a flexbox layout for consistency on mobile. These details weren’t my stated requirements—the model filled the gaps on its own, drawing on internalized engineering best practices.

5. Systematizing Efficiency: From One-Off Gains to Sustainable Delivery

A single successful task proves nothing about long-term efficiency. My conclusion: the real value of an LLM coding tool lies in whether it can be embedded into a repeatable engineering process. My workflow has shifted from “human writes, AI assists” to “AI writes, human reviews.” Before every commit, I ask the model to output a self-test record and a note on potential regression risks. Across nearly 3,000 commits, severe defects introduced by AI account for less than 2%.

At the same time, I stay deliberately disloyal to any model. Leaderboard positions, parameter counts, and marketing talk are not what matter. Only one question counts: within a fixed budget and a fixed timeline, does this model improve my delivery certainty. This product’s leading scores on long-horizon SWE tasks and terminal operation benchmarks broadly match the reasoning stability I’ve seen in practice. But I’m equally aware of how fast this field iterates—a better option appearing within a month is the norm—so keeping integrations lightweight and reserving abstraction interfaces is my core strategy for handling change.

6. Summary and Recommendations

For developers in one-person teams or small dev groups, my recommendations:

• Don’t be dazzled by “the largest parameter count.” Focus on task completion rate and unit cost.
• Build your own bug baseline library, and use historical stubborn bugs as the touchstone for a model’s capability.
• Make full use of caching and output constraints. These seemingly small settings save a surprising amount of budget.
• Always keep a human code review step, especially for code involving concurrency, security, and data consistency.

When AI can reliably take over the grind work, developers get to redirect their energy toward architecture design and business innovation—and that may be where “AI coding” truly pays off.