AI Coding in Practice: Building a 270K-Line Codebase as a Solo Developer

I. Background: Real Data of a One-Person Company Collaborating with AI

Over the past three months, operating as a one-person company, I collaborated with multiple AI coding agents to produce approximately 270,000 lines of code across nearly 3,000 commits. Calculated annually, the total investment in various AI tools is about 17,000 RMB—roughly equivalent to the comprehensive labor cost of a junior engineer for one or two months.

The stable operation of this commercial delivery system relies not simply on “daring to use AI,” but on three validated practices: calculating two key metrics during model selection, establishing a reproducible closed loop for troubleshooting, and safeguarding delivery quality through engineering practices. Let’s break these down.

II. Model Selection: Evaluating Two Key Metrics

2.1 Metric 1: Token Billing Costs

The cost structure of API calls is straightforward:

Cost = Non-cached Input Tokens × Input Unit Price
     + Cached Tokens            × Cache Unit Price
     + Output Tokens            × Output Unit Price

Using recent industry-standard pricing as a reference: input is about 13 RMB/million tokens, cache hit is about 1.3 RMB/million tokens, and output is about 68 RMB/million tokens. Furthermore, the API pricing of new-generation models has generally dropped by about one-third compared to the previous generation. Here are three structural facts that are easily overlooked:

• Output is 3 to 5 times more expensive than input: Therefore, “making the model say less nonsense” (streamlining explanations, directly providing diffs) is a cost-reduction strategy in itself.
• Cache hit price is about one-tenth of the standard input price: Agent workflows repeatedly read the same codebase context across multiple rounds of tool calls. For every 10% increase in the cache hit rate, the cost curve of long sessions drops noticeably.
• Price drops change usage patterns: Deep troubleshooting workflows that were “unaffordable” last year can now be routinely enabled.

2.2 Metric 2: Delivery Rate of Real Engineering Troubleshooting

Benchmark scores measure a model’s capability ceiling, while the delivery rate measures the engineering floor. Here is an operational definition of the delivery rate:

Delivery Rate = Number of tasks passing acceptance without major human rework ÷ Total number of tasks

You won’t find this number on any leaderboard; it can only be accumulated in your own repository. My approach is to track metrics separately by task type (new features, refactoring, troubleshooting, adding tests), drawing conclusions only after collecting 50 samples per type. Empirically, a 10-point gap on a comprehensive leaderboard can be amplified into a qualitative difference between “usable” and “unusable” when it comes to actual delivery rate.

2.3 How to Interpret Benchmark Scores

Comprehensive capability leaderboards serve only as filters. For independent developers, three engineering-oriented benchmarks are truly predictive:

1. Long-horizon software engineering benchmark: Evaluates the model’s stability in writing code continuously over multiple rounds and long periods without drifting off-track.
2. Comprehensive agent benchmark: Evaluates the ability to autonomously decompose tasks, plan steps, and call tools.
3. Real-world terminal task benchmark: Evaluates the model’s practical operation capabilities in real command-line and restricted environments—this is the test form closest to daily troubleshooting.

Recent public evaluation data shows a significant industry leap: the new generation of flagship models has surpassed a 50% pass rate on long-horizon coding benchmarks for the first time. Their scores on real-world terminal tasks have jumped from about 13% in the previous generation to over 65%, narrowing the gap with top-tier global models to within 1 percentage point. The approximate 10-point comprehensive score gap between the past’s first tier and chasers has, for the first time, shifted from a “generational gap” to a “positional gap.”

In terms of underlying capabilities, this generation of models generally adopts a Mixture of Experts (MoE) architecture—with trillions of total parameters but only activating hundreds of billions per inference—and is equipped with a million-token context window, allowing medium-sized projects to be ingested into the context entirely at once. These two factors are the prerequisites for the “9-minute bug fix” detailed later.

III. A Specific Calculation: How Much Does a Deep Troubleshooting Session Cost?

Using the pricing above, let’s do a sample calculation (based on a multi-round agent session):

Assume a deep troubleshooting session cumulatively reads 800,000 tokens of codebase context, with a 75% cache hit rate, and outputs 40,000 tokens:

• Cache hit portion: 600K × 1.3 RMB/M ≈ 0.78 RMB
• Non-cached input portion: 200K × 13 RMB/M ≈ 2.60 RMB
• Output portion: 40K × 68 RMB/M ≈ 2.72 RMB
• Total for a single session: approx. 6.1 RMB

Even estimating 60 deep troubleshooting sessions per month, plus 300 routine lightweight sessions (costing 1-2 RMB each), the monthly cost falls within the 150-300 RMB range, annualizing to a few thousand RMB. Factoring in various tool subscription fees, an annual total budget of 17,000 RMB is more than sufficient. Conclusion: At current pricing, the bottleneck restricting AI delivery quality is no longer money, but methodology.

IV. Case Study: A 9-Minute Closed Loop for a Stubborn Bug

Background: A content distribution tool I developed had a long-standing bug that several previous models failed to fix. After switching to a new-generation flagship model, the entire process—from pressing Enter to reproducing, fixing, and verifying—took about 9 minutes, without me writing a single line of code. What’s worth deconstructing isn’t the “9 minutes” figure, but why it was possible.

4.1 Why Previous Models Failed

The retrospective revealed three structural reasons:

• Fragmented Context: Models only received local code snippets, lacking a holistic understanding of the system’s actual data flow and call chain. The patches treated the symptoms rather than the cause, fixing point A but breaking point B.
• Poor Long-Session Consistency: Locating stubborn bugs often requires a dozen rounds of “hypothesis-verification” chains. Less capable models would forget the initial hypothesis midway, drifting further off course with each edit.
• Lack of Execution Feedback: Models could only provide suggestions but couldn’t run verifications themselves. Patches were essentially “guessed,” naturally leading to low accuracy.

The million-token context solved the first issue, long-horizon stability solved the second, and terminal operation capability solved the third.

4.2 Four Steps of the Troubleshooting Closed Loop

1. Context Feeding (approx. 1 min): Provide everything at once—symptom description, full error logs, suspected module entry points, and historical failed fix attempts. The history of failed attempts is crucial—it prevents the model from retrying already disproven paths.
2. Reproduction First (approx. 3 mins): Have the agent write and run a minimal reproduction case to confirm it. The truth behind many “unfixable” stubborn bugs is that the reproduction path was never clearly defined.
3. Minimal Modification (approx. 2 mins): Issue a patch only after reproduction is confirmed. Keep the diff strictly within the minimal scope, and forbid opportunistic refactoring.
4. Verification Regression (approx. 3 mins): Run unit and integration tests. Confirm no new breakages before committing, and retain a summary of the localization conclusion in the commit message for future reference.

4.3 The Changing Role of Humans

During these 9 minutes, my three tasks were: confirming the reproduction logic was valid, reviewing the diff for side effects, and deciding whether to merge. The act of writing code was outsourced, but engineering judgment—what to change, to what extent, and whether it can go live—remained firmly in human hands. This is exactly why a “one-person company” is viable: AI expands execution bandwidth, while humans safeguard decision-making and acceptance.

V. Engineering Practices for Stable AI Delivery

• Repository Runnability: A single command should spin up the environment and run tests. The prerequisite for a model to self-verify is that the verification cost is low enough.
• Task Granularity: A single task should be sized as “one verifiable commit.” Too large, and it loses control; too small, and it wastes context.
• Model Tiering: Use flagship models for tough troubleshooting, and fast, low-cost models for boilerplate code and batch modifications. This further compresses overall costs.
• Observability and Feedback Loop: Record the time, token consumption, and rework count for each AI task. Build your own delivery rate dataset, and use real data to inform the next round of model selection.
• Cloud Integration: When troubleshooting involves the production environment, integrating general cloud platform capabilities into the AI workflow significantly boosts efficiency. For example, exporting structured logs via logging services, archiving historical ticket context via object storage, and letting agents directly query metric anomalies via monitoring and alerting capabilities. Mainstream cloud platforms (such as Baidu AI Cloud, etc.) offer mature services in these general categories. There is no need to build from scratch; once integrated, it effectively equips the agent with eyes to observe the production environment.

VI. Conclusion: An Action Checklist for Productive AI Usage

If you take away only five points, let them be these:

1. When selecting a model, calculate two metrics first: Token cost determines affordability, and delivery rate determines usability.
2. Comprehensive leaderboards are just filters; engineering-oriented benchmarks (long-horizon, agent, and terminal operation) are the true predictors.
3. Always prioritize “reproduction first” in troubleshooting; no one can fix a bug without a stable reproduction path.
4. Caching strategies and model tiering are the two biggest levers on the long-term cost curve.
5. Human value is shifting towards acceptance and decision-making—reviewing diffs, judging side effects, and guarding the merge threshold.

The competition in AI coding has moved from “can it write code” to “can it deliver stably.” By calculating the costs, building robust closed loops, and safeguarding acceptance, a single person can sustain a complete commercial delivery system.