One-Person Team Ships 270K Lines of Code in Six Months: How a Low-Cost LLM Precisely Squashed a Stubborn Bug

From “Works” to “Works Well”: A New Evaluation Dimension for LLM Programming

Over the past six months, I single-handedly handled the development and maintenance of multiple business systems, producing over 270,000 lines of code and completing nearly 3,000 commits. My total spend on various AI programming tools throughout the year was approximately ¥17,000. That figure may not sound high, but for an individual developer, every yuan needs to count. After cycling through everything from general-purpose conversational models to specialized coding assistants, I gradually realized that evaluating whether an LLM is truly suitable for engineering scenarios requires looking beyond benchmark scores. Two accounts matter more: the direct cost of token consumption, and whether the model can rapidly locate and fix problems when facing real-world edge cases.

Industry-standard AI code capability leaderboards (such as composite capability indices) can reflect a model’s generalization level, but when it comes to long-tail problems in a specific repository, a specific language, or specific business logic, they often diverge from real-world experience. Many models perform excellently on standard test sets but become helpless when facing a hidden state management bug buried in hundreds of thousands of lines of code. So my selection criterion is simple: can it solve problems I cannot solve, within my required timeframe, at an acceptable token cost?

Hardware Foundation and Architecture Parameters: The Long-Context Dividend of Large Parameters

Recently, a cloud provider released a new-generation large model designed for complex engineering tasks (hereafter referred to as the “K-Series Pro”). According to publicly available technical documentation, the model uses a mixture-of-experts architecture with a total parameter count of 2.8 trillion (officially claimed as 3-trillion-class), with approximately 104 billion parameters activated per inference. This design preserves massive prior knowledge while controlling per-inference cost. More critically, it supports a 1-million-token context window, meaning the core codebase, relevant configuration files, test cases, and even historical commit records of a mid-to-large project can all be loaded into a single prompt without manual decomposition or summarization.

In practice, the value of long context far exceeded expectations. The traditional approach is: when encountering a bug, first guess which module might be problematic based on the error stack trace, then search the codebase for relevant functions, and manually copy-paste them into the chat window. This process is not only time-consuming but also prone to missing cross-file state propagation. The K-Series Pro lets me directly import an entire microservice directory (approximately 800 files) into a session, and the model can autonomously retrieve and correlate call chains across different files. This fundamentally changes the debugging logic: from “humans finding code” to “code waiting for questions.”

Real-World Test: A Stubborn Defect That Had Been Unresolved for Three Months

In my self-built text streaming service (code-named “ZiLiu”), there was a long-standing concurrency defect. The symptom: under high-concurrency write scenarios, messages would occasionally be lost, with no exception logs output. Previously, multiple mainstream LLMs and static analysis tools failed to identify the root cause. Model A suggested checking lock granularity; Model B suspected database connection pool exhaustion—but after verifying each one, the problem persisted.

On the evening of October 23, I decided to bring this model into the “ZiLiu” troubleshooting workflow. The process was as follows:

1. Create a session and import the project: I created a new session and uploaded the “ZiLiu” server-side code directory (approximately 200MB, covering a Go backend and a TypeScript frontend).
2. Describe the symptoms: I did not provide specific code lines—only three key pieces of information: concurrent writes, intermittent loss, no errors reported.
3. Request a troubleshooting plan: The model did not jump to conclusions. Instead, it first listed a five-step diagnostic path, including verification of message queue ack mechanisms, channel blocking, goroutine leaks, data races, and serialization layer anomalies.

From pressing enter to its first troubleshooting plan output: about 40 seconds. I then added temporary logs at key points as it suggested. About 5 minutes after redeployment, the logs captured an anomaly: a worker goroutine failed to exit properly after a context timeout, causing a message body to be partially written to the buffer without being flushed. The model immediately provided a fix patch—modifying the goroutine exit condition and adding a buffer state check before write operations. The entire closed loop from problem reproduction to fix verification took about 9 minutes, and I did not hand-write a single line of logic code throughout.

The Cost Account: How Many Tokens Does One Debugging Session Consume?

According to console logs, the session consumed approximately 1.8 million input tokens (mainly from large file imports) and about 23,000 output tokens. At the model’s current publicly listed per-million-token input/output pricing (approximately ¥5/¥20), the API cost for this debugging session was about ¥13.4. Compare that to purchasing a more expensive proprietary tool with an annual fee (thousands of yuan), or spending an entire evening manually troubleshooting—the cost-effectiveness advantage is clear.

More noteworthy: after the fix, the model proactively output regression test suggestions for this pattern and pointed out that similar structural risks might exist in another module. This “associated diagnosis” capability is virtually nonexistent in traditional toolchains.

Frontend Landing Page Engineering: From Prototype to Deliverable in the Same Session

Using the same context window, I then tried having it directly generate a frontend landing page for a data dashboard. The requirements description was under 100 words (including chart types, data refresh frequency, and page style). It generated React code based on a common component library, including ECharts line charts, real-time data tables, and responsive layout. The entire page was about 600 lines of code, passed the build on the first try, and had no runtime errors.

This gave me an insight: spanning “backend defect fixing” and “frontend feature development” within the same long session means the model’s overall understanding of the project stays consistent. The generated code style closely matches the existing codebase—it even automatically uses existing utility functions in the project rather than reinventing the wheel. This consistency is difficult to achieve with short sessions or single-file Q&A modes.

Sober Observations Beyond the Leaderboard: Applicable Boundaries and Risk Control

Despite the impressive results, I must point out the limitations of large models. The model still produces “plausible but incorrect” guesses when parsing stack traces for cross-language mixed calls (such as Go calling C++ libraries). Additionally, while the code it generates is logically correct, it occasionally exhibits a tendency toward over-engineering (such as unnecessary abstraction layers). Therefore, in actual engineering practice, I still maintain strict code review and automated testing mechanisms.

Another variable that cannot be ignored is the model’s open-source progress. The model vendor has promised to release full weights within the next year. For enterprise users, this means subsequent deployment to private environments to address code security and compliance concerns. However, at this pre-open-source stage, caution is still needed when handling classified code.

LLM Selection Advice for Developers

Based on six months of hands-on experience, I have distilled four principles for model selection and usage:

1. Context length is the hardest metric: Tools with less than 64K context often require repeated information trimming when handling real projects, causing severe efficiency decay.
2. Focus on activated parameters, not total parameters: Activated parameters determine the response quality and speed of a single inference. A model with many total parameters but few activated parameters may “read a lot but react slowly.”
3. Use long-tail bugs for stress testing: Standard programming problems cannot differentiate model quality. Prepare a stubborn defect whose root cause you already know but have not yet fixed, and test whether candidate models produce a clear troubleshooting path.
4. Calculate budget on an annual basis: Evaluate by scenario, not by usage count. A stable API subscription is usually more cost-effective than pay-per-use—provided the model genuinely reduces your ineffective trial-and-error time.

In the future, as models gradually open-source and inference costs continue to drop, a one-person company surpassing a traditional small team in programming productivity will no longer be news. The key question is whether developers can build a debugging philosophy for efficient AI collaboration—write less code, ask better questions.