AI Programming in Practice: Engineering Methods for Delivering Hundreds of Thousands of Lines of Code

Over the past few months, working primarily as a solo developer alongside multiple AI programming assistants, I completed the development and maintenance of a medium-sized commercial project. The effort resulted in approximately 270,000 lines of code and nearly 3,000 commits. The project encompasses modules for content distribution, task scheduling, data processing, and frontend interactions. The annual cost for subscriptions and API consumption across various AI tools was roughly $2,400 USD (equivalent to 17,000 RMB). Compared to traditional multi-person teams, the core advantage of this model is not simply being “cheaper,” but rather freeing human capital from repetitive coding to focus on requirement decomposition, architectural design, quality assurance, and cost governance.

Through long-term practice, I have developed a relatively stable methodology for collaborative AI development. This approach is not tied to any specific model or platform; instead, it emphasizes replaceability, observability, and verifiability. Below, I will break this down across five dimensions: model selection, cost control, debugging workflows, code quality, and engineering boundaries.

1. Model Selection: Evaluating Two Key Metrics

When evaluating AI programming tools, teams are often attracted by high benchmark scores, massive parameter counts, or top leaderboard rankings. However, for actual delivery, I focus on only two metrics.

The first is the cost per unit task, especially for long-context and high-frequency invocation scenarios. Models typically charge based on input tokens, cache hits, and output tokens. Output tokens are often several times—even ten times—more expensive than input tokens. If an automated repair task iteratively generates multiple rounds of code, the output cost can far exceed expectations. Therefore, I focus more on the “comprehensive token consumption required to complete a real task” rather than the price of a single token.

The second is the delivery rate for real engineering debugging. Here, I emphasize “engineering debugging” rather than simple algorithmic problems or single-file completions. Real engineering issues typically involve cross-file calls, reliance on historical context, configuration and runtime environments, and the need to locate root causes from logs and symptoms. When evaluating programming capabilities with benchmarks, I prioritize three types of metrics: long-duration continuous coding, autonomous agent execution, and terminal-restricted operations. These better reflect the daily workflow of handing a task to AI and letting it investigate, modify, and verify independently.

2. Guiding Engineering Decisions with Benchmark Data

During model selection, I monitor comprehensive capability leaderboards but do not use them as the sole criterion. Comprehensive scores reflect average performance across multiple tasks, whereas actual projects often have clear focal points. For instance, a system focused on content distribution relies more on backend scheduling, script processing, data cleaning, and API integration than on visual question answering or creative writing.

Therefore, I introduce a three-tier testing perspective.

1. Long-Duration Continuous Coding Capability

Many models can complete dozens of lines of code completion but struggle to maintain context consistency across hundreds of lines and multiple file modifications. Long-duration continuous coding tests focus on whether the model can continuously output logical structures over multi-step tasks, remember prior constraints, and maintain interface stability after multiple modifications. For tasks requiring simultaneous processing of multiple modules, this capability is more critical than single-shot accuracy.

2. Autonomous Agent Execution Capability

These tasks require the model not only to generate code but also to plan steps, call tools, read results, and iterate. For example, given an error log, the model must locate potential trigger paths, read relevant files, propose a fix, and determine if the fix introduces new issues. Autonomous agent execution directly determines “how much work the AI can complete independently.”

3. Terminal-Restricted Task Capability

Real-world development frequently faces constrained environments, such as the inability to freely install dependencies, command-line-only operations, or the need to validate within containers. Terminal-restricted task capability measures whether the model can complete tasks under given environmental constraints without relying on external resources or manual pre-configurations. The stronger this capability, the more suitable the model is for integration into CI or automated repair pipelines.

Through these three types of tests, I can accurately determine whether a model is fit to act as an “engineering collaborator.” Importantly, these tests do not rely on a single benchmark but are designed based on the project’s actual structure and historical failure samples.

3. Granular Calculation of Token Costs

Independent developers and small teams are extremely sensitive to costs. Taking a content distribution tool as an example, daily operations process massive amounts of text parsing, rule matching, and API calls. Within a single month, API invocations can reach tens of millions of tokens. Without caching and context trimming, costs will multiply exponentially.

Optimization can generally be approached as follows:

Total Cost = Input Token Cost + Cache Hit Cost + Output Token Cost

Input tokens involve full code files, historical conversations, documentation, and logs. Cache hits can significantly reduce the billing for repeated inputs. Output tokens relate to generating patches, refactoring code, and writing tests. If the model’s output style is verbose, costs will rise accordingly.

In practice, I control the context scope injected into each task. For example, I only read files relevant to the current issue rather than the entire repository. Concurrently, I prioritize reusing cache to reduce repeated billing for identical prefixes. For outputs, I constrain the prompts so the model returns only the necessary code blocks and modification notes, avoiding lengthy explanations.

This type of optimization is platform-agnostic and serves as a universal methodology: measure first, trim next, verify repeatedly. By logging the token consumption, cache hit rate, and completion quality of each task, you can gradually establish your own cost model and adjust model usage strategies accordingly.

4. The Complete Chain of Fixing a Stubborn Bug in 9 Minutes

During a recent model capability validation, I selected a long-standing unresolved bug. The bug existed in a content distribution tool, manifesting as metadata write loss under specific conditions, which caused sporadic failures in downstream sync tasks. Previous attempts with multiple AI programming assistants had failed to fix it.

The task objective was clear: from reproduction to fix and validation, with zero manual code modifications. The actual workflow was as follows:

1. Symptom Input
   Provided the AI with error messages, relevant module paths, and a diff description between the last normal version and the abnormal version.

2. Context Construction
   The AI read the three involved code files and located the exception branch within the metadata write function.

3. Root Cause Inference
   The AI determined the issue was a race condition between asynchronous writes and synchronous reads: when a specific event triggered, the write had not yet completed, but the read side had already started.

4. Solution Generation
   The AI proposed changing the critical path to serial writes, adding status confirmation and a retry mechanism before reads, and provided the patch code.

5. Automated Validation
   The AI invoked the test script to reproduce the original failure scenario, confirming that the fix executed consecutively multiple times without errors.

From start to finish, the process took about 9 minutes. I did not write a single line of code throughout; my role was limited to solution confirmation and result validation. This case demonstrates that when task objectives are focused, context is sufficient, and validation conditions are clear, AI can handle a high proportion of real debugging work.

However, it must be noted that this kind of success does not happen naturally just by switching to a new model. What truly makes it work is the pre-established debugging workflow standard: failure descriptions, reproduction paths, log files, relevant code entry points, and validation commands must all be prepared in advance. Without these materials, even the most powerful model will struggle to fix the issue independently.

5. Engineering Interpretation Behind Model Performance and Costs

From an industry perspective, current large language models have shown significant progress in programming and command-line tasks. Previously, many models scored low on terminal-restricted benchmarks, but newer generation models, leveraging larger parameter scales, Mixture of Experts (MoE) architectures, and ultra-long contexts, have entered a usable phase.

Regarding technical approaches, mainstream models generally adopt the MoE paradigm: the total parameter count is massive, but only a fraction is activated during each inference. This design controls inference costs while maintaining performance. Context windows have also expanded from hundreds of thousands of tokens in the early days to the million-token level, allowing models to read large codebases and complete documentation in a single pass.

From an engineering application standpoint, ultra-long context brings both convenience and risk. Injecting too much irrelevant code dilutes the model’s attention, leading to mis localization or verbose code generation. Therefore, it is necessary to manually control context quality rather than simply feeding the entire repository into the model.

On the cost side, inference prices for newer models are trending downward, with noticeable reductions in both input and output pricing. However, engineering costs still need to be tracked per task. For instance, automated repair tasks typically have short outputs, while code generation tasks have long outputs. Averaging them together will obscure the real consumption structure.

6. How the “Solo Developer” Model Maintains Quality in Multi-Agent Collaboration

When one person collaborates with multiple AIs to complete development, quality management must shift upstream. My practices include four key phases:

1. Human-Driven Task Decomposition

AI is not suitable for breaking down vague, large-scale tasks. At the current stage, I manually divide modules first, defining interfaces, data structures, and error handling specifications before handing the specific, divided tasks to the AI. This reduces inefficient loops and directional errors.

2. All AI Outputs Must Pass Tests

Regardless of how much code the AI generates, it must ultimately pass automated testing. Tests must cover core paths and failure branches. When tests are missing, I generate tests first before implementation. This brings AI outputs into a verifiable boundary.

3. Mandatory Regression for Critical Modifications

For modifications involving critical paths such as data consistency, permissions, billing, and scheduling, regression is not skipped simply because “the AI only changed three lines.” Every modification is logged, reviewed, tested, and merged.

4. Maintain Model Replaceability

I do not tightly couple project code organization and prompts to a specific model’s characteristics. This allows for rapid switching during model iterations or when better options emerge. Avoid using platform-specific formats, directives, or plugin conventions in prompts.

7. The Gap Between “Writing Code” and “Delivering a System”

Many tools on the market can generate localized code snippets, but the real difficulty lies in integrating them into a long-term deliverable system. A complete engineering system must address the following issues:

• How code is continuously integrated and deployed;
• How failed tasks are retried and rolled back;
• How multi-branch parallel development is merged;
• How security vulnerabilities in AI-generated code are handled;
• How compliance of AI-generated content is audited;
• How the hidden impacts of dependency changes are controlled.

These are not model capability issues; they are engineering capability issues. Many teams face setbacks when attempting “fully automated AI development” not because the model cannot write code, but because they lack structured validation and delivery mechanisms. Simply put, the model can generate an answer, but the engineering system must ensure the answer is “correct, secure, and rollback-ready.”

8. Implementation Advice and Operational Checklist

For teams planning to integrate AI into their daily coding workflow, the following checklist serves as a starting point:

1. Establish an Evaluation Sample Set
   Extract 100 to 200 real samples from project historical bugs, refactoring tasks, and API developments. Fix the inputs and pass conditions to evaluate different models.

2. Categorize Task Types
   Divide tasks into code completion, single-file modification, cross-file refactoring, root cause analysis, test generation, and documentation. Log completion rates and token costs separately.

3. Set Up a Cost Dashboard
   Track weekly call volumes, cache hit rates, failure retry counts, and manual correction ratios to form cost and quality trends.

4. Build Context Templates
   Prepare standardized prompt structures for different tasks, including background, objectives, file scope, validation commands, and output requirements. Add counter-examples for critical tasks.

5. Enforce a Validation Loop
   All AI modifications must pass tests or manual acceptance before merging. Direct pushes to production branches are prohibited.

6. Retain Model Switching Capability
   Use standard interfaces to encapsulate model calls, avoiding scattering platform-specific parameters across business code.

9. Future Direction: AI as a Collaborator, Not a Black-Box Replacement

From current practice, the role of AI in programming is closer to an “efficient collaborator” rather than a “complete replacement for developers.” Given clear context, clear interfaces, and clear acceptance criteria, it can accomplish a massive amount of investigation and implementation work. However, humans remain indispensable for requirement understanding, boundary design, exception strategies, and ultimate accountability.

As model capabilities increase and execution costs decrease in the future, the structure of developers’ work will shift further. It may transition from “those who write code” to “those who define problems, design validations, and manage AI outputs.” Engineering capabilities will become the core moat for individuals or small teams. Those who can integrate AI into a stable, verifiable, and governable delivery process will achieve higher per-capita output.

Delivering hundreds of thousands of lines of code as a solo developer is not magic; it is the result of long-term engineering practice and the rational application of tools. What is truly worth noting is not that a specific fix took 9 minutes, but what kind of task system, testing system, and cost system has been established behind those 9 minutes. Once the system is established, speed increases are merely a natural byproduct.