Six Months and 300,000 Lines of Code: What a $200-a-Month AI Coding Experiment Revealed

A Six-Month Extreme Programming Experiment

Over the past six months, one developer took an almost self-punishing approach to advancing a personal project. He spent approximately $200 per month on a high-usage plan for an AI coding tool and pushed his development pace to the limit. During that period, he rewrote and expanded a codebase that originally contained about 100,000 lines into one containing roughly 300,000 to 400,000 lines.

This was not a simple productivity success story. Behind the numbers were months of intense human–AI collaboration, technical debt caused by repeated refactoring, and a clear decline in both physical and psychological well-being. He joked that the experience might have cost him five years of his life. Although made humorously, the remark reflects a real tension emerging in the age of AI-assisted programming: tools are becoming dramatically more capable, but health, quality, and maintainability do not automatically improve with them.

Why Pay $200 a Month?

To understand the experiment, it is important to look at why the developer was willing to make such a substantial monthly investment. He was not simply spending money to try a new tool. The decision was driven by two main needs.

First, the existing project required a structural refactor. The original 100,000-line codebase was a business system that had evolved through rapid iteration. Its modules were tightly coupled, its logic was scattered, and its naming conventions were inconsistent. A conventional manual refactor could have taken months or longer. AI coding tools appeared to offer a way to replace large amounts of code at machine speed.

Second, he wanted to test the limits of the new tools. A high-frequency plan provided shorter response intervals, larger context windows, and more sophisticated multi-file editing capabilities. His question was not merely whether AI could write code. He wanted to know whether it could continue producing useful code as a reliable collaborator over a long period of time, inside a large and complex real-world project.

The results showed that the tool eliminated a significant amount of mechanical coding work. Function completion, template generation, cross-file logic analysis, and initial test generation all became substantially faster. Yet that speed also introduced problems that were difficult to see at the beginning.

What the 300,000 Lines Actually Represented

When a project grows from 100,000 to 300,000 lines, the obvious assumption is that its functionality has expanded dramatically. In practice, the reasons behind the increase were much more complicated.

Redundancy Generated by AI

A common pattern in AI-assisted development is that models tend to generate a complete solution rather than make the smallest possible change. Given a request to modify one function, an AI tool may rewrite the entire function body and adjust several surrounding functions for compatibility.

A single operation may appear reasonable. Repeated thousands of times, however, this approach can quickly fill a codebase with redundant elements: unused helper functions, multiple implementations of similar utilities, and unnecessary state-checking branches.

During his later review, the developer found that a significant portion of the 300,000 lines consisted of this kind of defensive redundancy. The actual increase in business logic may have been closer to 50 percent. Much of the remaining code served as structural padding created by the way AI-generated changes were introduced.

When Refactoring Turned into Rewriting

The original plan was to use AI for incremental refactoring: decoupling modules, standardizing interfaces, and optimizing critical paths. In practice, the speed of AI-generated code made full rewrites highly tempting.

When faced with a poorly structured legacy module, it often seemed easier to ask the AI to generate a new version from a requirements description than to spend time analyzing dependencies and gradually modifying the existing implementation.

At first, this approach created a strong sense of progress. The new code appeared cleaner, more modular, and more consistent in its naming and documentation. But each large-scale rewrite also created a risk: hidden edge cases, exception-handling logic, and implicit business rules in the original code could be lost.

To verify behavioral consistency, the developer had to add large numbers of tests to the rewritten code. The cost of this validation work had been seriously underestimated.

Exponential Growth in Test Code

Testing was another major source of the increase in line count. To verify AI-generated code, the developer gradually adopted a “generate and test” rule. After the AI produced the main implementation for a feature, he either wrote or asked the AI to generate corresponding unit and integration tests.

From a software engineering perspective, this was a sound practice. In reality, it also created a new time sink: test code had to be written, reviewed, and maintained.

The problem became especially severe during the later stages of refactoring. A small interface change could require updates across a large number of related tests, and the resulting maintenance work was often much greater than expected.

Evaluating the ROI of $200 per Month

The value of the monthly investment cannot be measured simply by comparing the subscription cost with the number of lines produced. A more useful evaluation needs to consider three dimensions.

1. Effective Productivity Gains

AI tools produced clear efficiency gains in several areas:

• Boilerplate and glue code: DTO definitions, configuration files, interface skeletons, and basic CRUD operations could often be generated with little effort and relatively stable quality.

• Initial drafts for language and framework migrations: When moving a module from an older technology stack to a newer one, AI could quickly produce a roughly runnable first version, significantly reducing the time required for initial exploration.

• Common algorithms and design patterns: For established approaches such as caching strategies, retry mechanisms, and message-queue consumer logic, AI could provide implementations aligned with common practices.

These tasks represented approximately 30 to 40 percent of the overall coding workload. AI could reduce the time spent on them by more than half, creating a real and measurable productivity benefit.

2. Quality and Cognitive Cost

The quality benefits of AI-assisted programming exist alongside a growing cognitive burden.

On the positive side, AI-generated code usually follows formatting conventions and often includes useful comments. It can also reduce simple typographical mistakes. The deeper risk, however, is a loss of direct understanding.

When developers stop writing code line by line and instead describe requirements for an AI system to implement, their familiarity with the details of the overall system can decline. By the sixth month, the developer admitted that he had become somewhat unfamiliar with the underlying logic of certain modules. This kind of distance is much less common in a traditional hand-coding workflow.

AI may save typing time, but it does not necessarily save the time required to understand or debug a system. In some cases, it can increase that cost. When investigating a complex bug, the developer first had to reverse-engineer and understand AI-generated code before he could locate the actual problem. The debugging process was sometimes slower than it would have been with code he had written manually.

3. Long-Term Maintainability and Technical Debt

This is the dimension most easily hidden by short-term productivity gains.

The consistency of AI-generated code depends on sufficient context and clear requirements. When the requirements are ambiguous or the relevant context is truncated, the AI must make default decisions based on its own assumptions. Those assumptions may not match the project’s long-term direction.

The developer summarized the experience with a particularly harsh observation:

AI-generated “correct code” is easy to verify, but AI-generated “appropriate architecture” is difficult to judge.

During system integration, compatibility problems began to appear because different modules had been generated with inconsistent assumptions. Fixing these problems cost far more than establishing constraints and making architectural decisions before implementation.

The Cost of Extreme Programming

During the most intense period, the developer spent more than 12 hours a day on high-intensity coding while relying heavily on the rapid output of the AI tool.

After three months, his body began showing clear warning signs: neck discomfort, declining eyesight, poor sleep quality, and persistent fatigue. The symptoms were similar to those associated with long-term overwork and professional burnout.

The psychological changes were even more concerning. Because the AI tool responded quickly and generated large amounts of code, he developed an unconscious compulsion to use his daily request allowance. Even when his ideas were unclear or the requirements were not fully defined, he would continue sending prompts simply to avoid “wasting” the subscription quota.

This mindset almost inevitably produced more fragmented output and increased rework.

His comment that the experiment might have shortened his life by five years was a joke, but it pointed to a serious issue: AI coding tools have significantly raised the maximum potential workload for developers, while human physical and cognitive capacity has not increased at the same rate.

Once a tool produces code faster than a person can absorb it, the tool can shift from being an accelerator to becoming a source of exhaustion.

Practical Improvements

Based on the experience, several recommendations may be useful for developers using AI coding tools.

• Define boundaries for AI-generated changes: Specify which modules may be rewritten and which may only receive localized changes. These rules can be documented in configuration files or code comments so that the AI tool is less likely to perform unnecessary rewrites.

• Restore human code review as a mandatory step: AI-generated code should not bypass review. Before code is merged, an independent review by the module owner—not only by the person who prompted the AI—should focus on overengineering, hidden assumptions, and architectural inconsistencies.

• Create traceability conventions: Mark AI-generated code in commit messages or comments, along with the key constraints used during generation. This can significantly reduce the cost of re-understanding the code during later maintenance.

• Limit daily AI usage: Set a personal upper limit for AI-generated requests. This helps prevent the “use it because it has already been paid for” behavior associated with high-frequency plans.

• Schedule regular AI-free periods: Set aside half a day or a full day each week for manual code reviews, architectural analysis, and technical-debt assessment without using AI tools. This can help developers regain a clear understanding of the system as a whole.

Conclusion: Tool Efficiency Requires Engineering Discipline

The most important aspect of this six-month experiment was not the number 300,000. It was what the number revealed about a broader trend in software development.

AI coding tools are raising the upper limit of software complexity that developers can handle. At the same time, they are also increasing cognitive demands and potentially raising the health costs of development work.

The key is to find a balance between using a tool and depending on it. As the developer observed during his review:

AI helped me finish the code, but it did not help me think through the system.

Codebases can grow rapidly with the help of AI. System stability, maintainability, team collaboration, and long-term architectural coherence still depend on engineering judgment that the tool cannot replace.

For teams adopting AI-assisted development, this experiment offers an important lesson. The value of an AI tool should not be measured by how many lines of code it produces. It should be measured by whether it genuinely reduces the complexity of evolving and maintaining the system over time.

In that sense, the $200-a-month experiment did not ultimately produce 300,000 lines of code. It produced a case study in how programming practices need to be reconsidered in the age of AI.