LLM Coding in Practice: How a One-Person Team Wrote 270,000 Lines of Code in Three Months on a Lean Budget

In solo development and micro-team workflows, both headcount and funding are scarce resources. Over the past three months, working entirely on my own and supported by several LLM tools, I wrote 270,000 lines of code across nearly 3,000 commits. My total annual spending on AI tool subscriptions came to about CNY 17,000 (roughly USD 2,400). What made this one-person-company delivery model viable was not the number of tools stacked together, but a rational methodology for model selection and engineering troubleshooting. When I evaluate a model, I look at only two ledgers: what it costs in tokens, and how often it delivers in real debugging work. I recently ran into a long-standing bug that several models had failed to fix, so I used it as a stress test for a newly released model. From instruction to reproduction, fix, and verified resolution, the entire run took about nine minutes — without me writing a single line of code. This article walks through model capability benchmarks, API cost accounting, and one complete fix pipeline, breaking the experience down into a reusable AI collaboration playbook.

1. The Core Logic of Model Selection: Cost and Delivery Rate Together

For an independent developer, choosing an LLM cannot be a matter of marketing specs; it has to come down to concrete engineering cost versus output. My evaluation framework has two core dimensions:

1. Token billing cost. This is the most direct economic account. Prices differ enormously across models and tiers. For projects with heavy iteration and frequent commits, cache hit rates and output unit prices largely determine monthly spend. Under a limited budget (about CNY 17,000 per year), you need the best price-performance option plus an on-demand routing strategy: cheap models for simple tasks, high-performance models reserved for complex ones.

2. Real-world troubleshooting delivery rate. This is the more critical but implicit metric. What matters is not how much demo code a model can produce, but whether — when you hit a deep bug, need cross-file context understanding, or face complex terminal operations — it can hand you a workable solution instead of burning through rounds of ineffective dialogue. Delivery rate measures a model’s survival ability in real projects; it is more informative than any standardized test score.

Guided by this framework, I recently tested a new-generation model built on a Mixture-of-Experts (MoE) architecture. Its total parameter count reaches the trillion scale, roughly 100 billion parameters are activated per inference, and it supports a context window of about one million tokens. A large codebase or long document can be read in full in a single pass, with no manual chunking. Just as important, the vendor has committed to open-sourcing the model weights by a specified date, leaving room for private deployment later. On a recent third-party leaderboard, the model’s composite score has entered the global top five, with strong results on several segment benchmarks — particularly long-horizon coding and terminal-operation tasks.

2. From Benchmarks to Practice: Reading the Data

Benchmark scores are the first window into a model’s capability, but they need to be read against what each test actually measures. I focus on three types of metrics:

• Long-horizon continuous coding. The model scored 51.7% here, ranking first. This test simulates an AI writing cross-file code over an extended session; a high score means the model maintains state consistency and logical coherence across large, multi-module projects instead of getting lost partway through.
• Agentic autonomous operation. The model also ranks near the top in agent-style evaluations. These tests require more than answering questions: the model must plan tasks, call tools, execute commands, and process feedback. For developers, this determines whether a model can run compile, test, and log-inspection loops on its own in a terminal environment.
• Restricted terminal operation. The model scored 65.7%. This test simulates constrained tasks in a realistic terminal environment, with factors like file permissions, resource limits, and command complexity in play. It is the best proxy for how well a model handles real operational problems.

Notably, the model already outperforms several leading international flagship models in the first two categories, trails the leader by just 0.7 percentage points in the third, and leads another well-known model by 7.5 points. The takeaway: the capability gap among top-tier coding models is closing rapidly, and models from Chinese labs are now very close to the global first tier.

3. The Cost Model: An Item-by-Item Account for Developers

API pricing directly shapes how often — and how freely — you use a model day to day. This model was priced noticeably lower than its predecessor, a cut of roughly one-third overall. Taking the China-market standard tier as an example:

• Input: about CNY 13 per million tokens — and only about CNY 1.3 per million on cache hits. That is very friendly to high-frequency debugging and repeated reads of the same project context.
• Output: about CNY 68 per million tokens. When you are generating large refactors or rewriting long files, this pricing structure helps keep costs in check.

On this basis, my AI collaboration pipeline runs a tiered calling strategy:

1. Everyday lightweight tasks (formatting, comment generation, simple search): route to low-cost or free models; the cost is negligible.
2. Core code generation (module development, feature refactoring): route to mid-priced models and lean on caching to avoid paying repeatedly for the same context.
3. Hard bug analysis and fixes (needing global context and complex reasoning): call the current strongest model without fussing over per-call cost — solving the core problem comes first.

This strategy keeps total spend within about CNY 17,000 per year while preserving output efficiency at every tier.

4. Case Study: The Full Pipeline of a Stubborn Bug Fixed in Nine Minutes

Theory covered, back to the real battlefield. A content distribution tool I built myself had a bug that had sat unresolved for a long time: along certain operation paths, data writes would fail intermittently, with no clear error in the logs. Adding retry mechanisms and tuning thread pool parameters had both proved ineffective.

In this test, I handed the entire task to the new model. The sequence:

1. Instruction. I gave a short instruction containing the essentials — the buggy module, the reproduction path, and the gap between expected and actual behavior. No code snippets were pasted.
2. Location and context reading. From my description, the model located the relevant project directory and read the three core files involved: the data model definition, the scheduling logic, and the persistence-layer wrapper. With the million-token context window, it took in the overall call relationships in a single pass.
3. Root cause analysis. The model determined the fault was not in the business logic layer at all. Under a specific concurrency scenario, the persistence layer was tripping a hidden timeout path in the database connection pool. The logs had never captured the exception because the framework swallowed it internally.
4. Fix and verification. The model adjusted the connection pool configuration parameters and added a fallback exception-catching layer. It then simulated high-concurrency stress tests, reproduced the original failure path, and confirmed the problem no longer occurred. No human intervention at any point.

From pressing Enter to completed verification took about nine minutes. Most importantly, I wrote no code myself — the model closed the understand, analyze, modify, and verify loop autonomously. Compared with the hours or even days such issues used to consume, the efficiency gain is substantial. That is the practical value of a high-delivery-rate model.

5. Frontend in Practice: From Natural Language to a Usable Page

Beyond bug fixing, the model is also strong at rapid frontend work. In another task, I asked for a display page with a responsive layout, interactive charts, and mobile adaptation. It returned a complete HTML, CSS, and JavaScript solution in one pass — structured to modern web conventions and running in the browser without any adjustment. More notably, it proactively accounted for loading performance and basic SEO tags, which most models in its class do not.

This points to real progress in understanding business intent: the model is not satisfied with syntactically correct code; it tries to match the implicit requirements of the delivery scenario.

6. Applicable Scenarios and Engineering Advice

Based on this practice, the methodology fits the following scenarios:

• Rapid prototyping. When requirements are still vague, use AI-generated runnable demos to validate ideas.
• Technical debt cleanup. Let a long-context model absorb the structure of legacy code in one pass and propose refactoring suggestions.
• Stubborn bug hunts. When conventional search cannot localize a problem, hand it to an LLM for cross-file reasoning.
• Small-team enablement. Treat AI as a virtual team member, responsible for baseline code generation and test case writing.

Three boundaries to respect:

1. Security and compliance. Be cautious about uploading repositories that contain sensitive data to cloud models; choose a private deployment option when necessary.
2. Code review cannot be skipped. AI-generated code still needs human review, especially in security-sensitive scenarios.
3. Cost control is continuous work. As models iterate, pricing and performance will change; review your usage data regularly and adjust the strategy accordingly.

7. Outlook: A New Paradigm of LLM-Driven Development

This test shows LLMs moving from autocomplete assistants toward autonomous engineering agents. Next, these capabilities will push further into edge environments and vertical domains, and the developer’s role will shift toward requirement definition, solution review, and quality control rather than line-by-line writing. For a solo developer, mastering a sound methodology for invoking AI is worth far more than owning expensive hardware.

Back to the original selection logic — token cost and delivery rate — these criteria still hold today. A year from now, as model capability keeps climbing, the more interesting question may be how tightly AI capability can be fused with human experience and judgment. That is the shared challenge every engineer now faces.