224,000 lines of AI-generated code: what is actually left of human work?

Note on How This Article Was Written

Like the previous one, this article was drafted with the help of AI, then reviewed, edited, and validated by me.

It draws on my experience developing LingRise, my working notes, and a technical audit pulled from the codebase and Git history. While the figures come from tangible records, the instincts, doubts, and shifts in direction stem entirely from firsthand experience.

---

I don't consider myself a technical virtuoso. Yet, since September 2025, I’ve been developing a solo project that now totals nearly 224,000 lines of code, mostly generated with the help of artificial intelligence.

This naturally raises a question: what, specifically, is left of my work?

The simplistic explanation suggests that the human supplies the ideas while the machine writes the lines. The opposing view claims that AI does everything while the user just watches. Both perspectives are wrong.

To gauge what still constitutes human effort in a codebase of this size, you have to look at how the nature of the obstacles shifted over the months: first a challenge of pace, then an issue of methodology, and finally a task of trade-offs and decision-making.

The Reality Behind the Volume

Taken in isolation, a line counter proves nothing. Any language model can churn out thousands of redundant or unusable lines within minutes.

In the case of LingRise, these 224,000 lines represent concrete infrastructure built over roughly a year:

• TypeScript (~124,000 lines): The web app built with Next.js and the mobile app in React Native.
• Python (~86,000 lines): The content engine (audio transcription, translation, generation, and quality validation).
• SQL (~11,000 lines): Nearly a hundred migration files.
• Architecture: 96 API routes, 56 user-facing pages, 179 React components, over 60 PostgreSQL tables, and 332 commits.

This volume doesn't make me an exceptional developer. However, it does illustrate what a single person can realistically aim to build today—as well as the pitfalls that this sheer abundance brings to light.

From Improvisation to the Need for Structure

When I started out on the project, my approach was far from methodical. I would pitch an idea to the AI, briefly discuss implementation paths, approve a proposal, and move on.

As long as the project fit within a few dozen files, this "freestyle" workflow was more than enough. AI dramatically accelerated my execution speed, allowing me to test hunches I would never have had the time to code manually.

Friction began to mount as features piled up. When a codebase starts depending on architectural decisions made weeks earlier, opening a blank prompt to stack another building block becomes risky. AI knows how to produce fast, but it doesn't automatically maintain the consistency of an ever-growing system.

To avoid getting bogged down, I adopted the BMAD method, which I discovered during technical research. Without being a silver bullet, it introduced much-needed rigor: explicit steps, specialized agents, and a structured path running from requirements gathering to technical specification before generating a single line of code.

The biggest benefit wasn't technical; it was cognitive. I started spending more time clarifying problems than asking for solutions. Brainstorming, formalizing constraints, having a critical agent review decisions, and being willing to scrap an idea before writing any code helped clean up the development workflow.

Yet, a project can be perfectly structured and still head straight into a wall.

The Trap of Feature Abundance

Initially, LingRise was supposed to cover a wide spectrum: grammar, conjugation, thematic vocabulary, interactive books, song analysis, and guided dialogues. AI gives the impression that you can build anything in no time—so why not build everything?

It was an illusion. Even with a solid methodology and effective agents, stacking sub-products creates a system that becomes impossible to test, maintain, and bring to market.

The real challenge shifted: it was no longer about moving faster, but knowing when to stop.

To make the cut, I ran a session with the bmad-brainstorming agent. The goal was not to outsource the decision—the drive to trim down came from me—but to subject my priorities to systematic pushback.

By scrutinizing every use case, a clear direction emerged: LingRise needed to focus on a strong, straightforward value proposition. Specifically: immersion through real podcasts, synchronized transcripts, contextual word-for-word translation, and a shadowing module for speaking practice. Everything else was cut.

This is where a core part of the work lies: designing a strict evaluation framework to resist the temptation to build everything just because the generation cost is virtually zero.

Asking the Question at the Right Scale

Technical trade-offs rarely come down to a simple unit test. The translation pipeline in LingRise is a prime example.

On a small sample of text, it's tempting to pick the most sophisticated model without worrying about cost. But scaled across the entire app catalog, the volume reached 2.16 billion tokens. (I haven't checked recently, but the figure is likely much higher now, as I generate new podcasts daily.)

Financial projections quickly put things into perspective:

• DeepSeek: ~€1,900
• Claude Sonnet: ~€30,000
• Claude Opus: ~€165,000

Even purchasing a dedicated GPU to run models locally couldn't compete economically with the pricing of certain specialized APIs.

AI is perfectly capable of building this comparison table and calculating the ratios. However, it won't take the initiative to evaluate the impact of a technical choice across an overall business model—that responsibility remains entirely human.

When the Technical Solution Masks the Real Problem

Generated code can run without a single error while missing the mark entirely.

To protect paid audio files, the AI set up a system of temporary signed URLs. On the surface, everything worked. I didn't find the flaw myself by acting like a cybersecurity expert—the issue was flagged simply by submitting the code to /bmad-code-review. Due to my storage and subdomain setup, the signature could be tampered with without blocking access to the file.

The first AI followed the technical instructions to the letter without genuinely securing the content. We had to iterate to design a system of tokens verified on the fly. My role wasn't to audit the code by hand, but to maintain high standards by orchestrating cross-examination between multiple agents.

The Flip Side: Owning the Technical Debt

Claiming 224,000 lines of code without mentioning technical debt would be dishonest. LingRise has clear weaknesses:

• No continuous integration (CI) pipeline: Checks remain largely manual before deployment.
• An unfinished monorepo migration: The overall structure still carries legacy artifacts at the root from when the mobile app was launched.

AI makes it easy to identify these areas and churn out patches in bulk. But review time and attention are finite resources. Living with these shortcomings is part of the compromise: setting priorities also means accepting what you choose not to tackle right away.

---

After these eleven months, the binary division between "human as designer" and "machine as executor" no longer holds up. Today's AI agents can write specifications and propose coherent architectures.

Yet the developer's role hasn't vanished: it has shifted.

It lies in identifying when the nature of a problem changes. In knowing when speed turns toxic, refusing to build new features even when they seem trivial to generate, spotting logical flaws hidden behind clean code, and safeguarding a system's economic viability.

AI made it possible to bring LingRise to life at a speed unimaginable for a solo developer. But the responsibility for what gets built—and especially what shouldn't be—still rests on the person sitting behind the screen.