Adding Thousands of Lines to Your Codebase Isn't Impressive. It's Actually Bad.

Adding thousands of lines of AI-generated code to a project is not a sign of productivity but a misunderstanding of development, according to a critical analysis of the 'vibe coding' trend. Examples include a founder who bragged about 160,000 lines for a trading platform and Cursor CEO Michael Truell admitting a 3-million-line browser 'kind of works.' The piece argues that reliance on non-deterministic LLM output without understanding fundamentals leads to bloated, low-quality code.

Adding Thousands of Lines to Your Codebase Isn't Impressive. It's Actually Bad. Vibe coding has added yet another layer of abstraction https://www.computer.org/csdl/magazine/so/2026/01/11316885/2cQwAOTuB4Q to programming. There are vibe coders who assume they don't even have to think about code anymore at all—the way web developers don't have to think about assembly or binary. Right? However, this layer, unlike all the previous ones, is non-deterministic and yet has a far more intensive cost despite that. You now have the ability to jump right into coding a project without understanding the fundamentals of syntax, or basic concepts like loops, if/else statements, variables, constants, the list goes on. Instead, you rely on the skills of the LLM chatbot to debug and maintain their work. And there's a false assumption that if you simply use a more detailed, specific prompt it'll lead to better quality code—a handy placebo. "We found that no single prompt consistently outperforms other" https://arxiv.org/html/2412.14454v1 is often the conclusion you'll get from data researchers. There is no shortcut for learning and understanding. There are unavoidable consequences for trying to use generative AI to shortcut the work required. Maybe I'm being cynical, but the radical universality that genAI has brought to coding seems to have only lead to far more SaaS spam in my email inbox with saccharine templative language, among other far more insidious harms https://brennan.day/ai . But I'm sure I'm preaching to the choir here. Maybe do yourself a favour and link somebody this article if they ever brag to you about using AI to make an app. The Numbers Just Keep Getting Bigger To the vibe coders that do attempt to interface with code, there is often a deep misunderstanding of what constitutes productivity in development. They'll brag about adding thousands of lines of code https://stephencollinstech.substack.com/p/pushing-ai-to-its-limits-10000-lines to a project in mere hours, as though this is a good benchmark. Sorry to put you on blast, Stephen Collins, but don't worry. I'll put others on as well. Austin Starks wrote an entire Medium piece bragging about having "vibe-coded" over 160,000 lines of code https://medium.com/p/c8ee0addef57 for a trading platform. The founder behind NexusTrade published a defensive rant about having AI help write over a quarter million lines of code https://nexustrade.io/blog/ai-helped-me-write-over-a-quarter-million-lines-of-code-the-internet-has-no-idea-whats-about-to-happen-20250421 , daring critics who called his app a "500 LOC toy project" to go replicate it themselves in a weekend, with the line count somehow doing the rhetorical heavy lifting in the argument. Cursor's CEO Michael Truell, who tweeted that his team had built a working browser with 3M+ lines of code https://www.theregister.com/2026/01/26/cursor opinion/ generated by AI in Cursor, then immediately admitted it just "kind of works." A Blind post bragged about Claude writing 15,000 lines of "critical infra" https://www.teamblind.com/post/opus-45-just-coded-15k-lines-of-critical-infra-in-8-hours-7dj744yq in a single weekend. Terraform, config, and Rust ETL pipelines. The poster thinks his whole team might be obsolete within months. A dev.to http://dev.to post from Ashley Childress proudly tallied more than 600,000 lines of AI-generated code https://dev.to/anchildress1/from-hell-loops-to-happy-commits-38c4 for a project. Though the breakdown in the post's own table shows the actual source code was 2,417 lines; the other 597,908 lines were raw Copilot output logs being counted as "code." A Substack note from John Crickett described an app that generated 23,000 lines of code with 836 passing tests in a couple of hours https://substack.com/@johncrickett/note/c-212097879 . He clicked the "run" button and nothing happened. Weighing the Airplane Somewhere in Microsoft folklore, Bill Gates is credited with saying that measuring programming progress by lines of code is like measuring aircraft-building progress by weight. Nobody can actually pin down where or whether he said it https://ask.metafilter.com/114578/Did-he-really-say-that , but the line has stuck around for decades anyway, showing up as an epigraph in Google engineers' own book on software productivity metrics https://www.oreilly.com/library/view/rethinking-productivity-in/9781484242216/html/456196 1 En 2 Chapter.xhtml . A large-scale study tracking AI-authored commits across real repositories found the volume of unresolved, AI-introduced issues still sitting in codebases climbed from a few hundred in early 2025 to over 100,000 by February 2026 https://arxiv.org/html/2603.28592v2 . Claude racked up nearly 500,000 lines added in a matter of weeks. GitClear's research https://leaddev.com/ai/code-maintainability-plummets-in-the-ai-coding-era , based on 211 million lines of changed code, found code duplication up 81% and code reuse down 70% since AI coding tools went mainstream. Refactoring rates https://www.tembo.io/blog/ai-technical-debt dropped from 25% of changes in 2021 to under 10% by 2024, while churn code rewritten within two weeks of being written went up. Only the person who wrote the prompt tends to actually understand the resulting code https://www.forbes.com/councils/forbestechcouncil/2026/03/24/the-new-tech-debt-codebases-only-ai-understands/ , which turns every AI-heavy repo into a knowledge silo of one. A benchmark of LLM-generated solutions across a thousand algorithmic tasks found GPT-4's code could run up to 3x slower and use 14 to 44 times more memory https://arxiv.org/pdf/2511.18538 than optimized human baselines. A more recent audit of AI-generated pull requests found actual slowdowns ranging from 3x to a staggering 446x https://blakecrosley.com/blog/the-performance-blind-spot in the affected functions. Worse, when AI agents were asked to fix performance problems, 90% of their proposed optimizations were either wrong or made no measurable difference. A peer-reviewed study of Copilot and comparable tools found inefficient function calls, inefficient looping, inefficient algorithms https://link.springer.com/article/10.1007/s10664-025-10776-1 , and inefficient use of basic language features. Code Golfing Code Golf https://en.wikipedia.org/wiki/Code golf is the practice of trying to write code with the least amount of lines and characters possible. It's a recreational programming challenge where devs compete to solve a specific problem using the fewest possible characters of source code, specifically. There are many different challenges https://code.golf/ . Regex Golf https://xkcd.com/1313/ , similarly, is a discipline of code golf and a fun 1 game where you use regular expressions to try to match one group of text fragments while avoiding matching another. They're named golf because, just like the sport, the goal is to get the "lowest score" fewest keystrokes possible. Now, this usually results in code that is incomprehensible or at least very difficult to parse. Here's a typical FizzBuzz in Python: for i in range 1, 101 : if i % 15 == 0: print "FizzBuzz" elif i % 3 == 0: print "Fizz" elif i % 5 == 0: print "Buzz" else: print i And here's a golf version: for i in range 1,101 :print "Fizz" i%3<1 +"Buzz" i%5<1 or i If you'd like to know how this code works: returns a boolean i%3<1 True / False , which Python silently treats as 1 / 0 when used in arithmetic.exploits string-repetition: multiplying a string by "Fizz" i%3<1 1 gives you the string back, multiplying by 0 gives "" . So this either produces "Fizz" or nothing, depending on divisibility.- Concatenating the two conditional strings naturally handles the "FizzBuzz" case for free, and there's no need for a separate %15 check. is sneaky: if both conditions failed, you're left with ... or i "" , which Python considers falsy, so or falls through to i . If either string got built, that string is truthy, so or short-circuits and returns it instead. ...But Short Also Doesn't Mean Good A vibe coder might read the section about lines-of-code bragging and conclude the fix is fewer characters. It isn't. The golfed FizzBuzz above is short and confusing. The "Fizz" i%3<1 trick saves keystrokes by hiding what's happening from the next person who reads it including, six months from now, you . Code golf communities are upfront about the trade-off, the code you produce is useless in the real world because of how unmaintainable it is https://github.com/shuprog/golf , and that's fine because it's an exercise. Code golf rewards concise, trick-laden solutions over the readability and maintainability that traditional programming prioritizes https://sonnik.substack.com/p/exploring-code-golf-the-art-of-minimalist . It's chess notation, not chess strategy. Optimization accounts for how fast a human can read it, how fast it builds, how fast it runs, and how little it costs to change six months from now. None of which correlate with character count. A study of how developers actually spend their time found programmers spend roughly 70% of it reading and understanding existing code https://arxiv.org/pdf/2501.11264 and not writing new code. Code is read far more often than it's written https://arxiv.org/pdf/2501.11264 . Python's own founding philosophy, PEP 20 https://peps.python.org/pep-0020/ , states that readability is a design value, that explicit beats implicit, and that sparse beats dense. Sparse, not shortest. Chasing brevity by hand at the source level doesn't make the build faster, it makes the code harder for the next person to work with. The build/compile/runtime side of "short" is already handled by machines automatically, downstream of the human-readable source. Minifiers strip whitespace and rename variables at bundle time, and compilers strip inline and dead-code. Developers don't need to hand-compress source so the browser downloads fewer bytes, that step already happens in the pipeline without sacrificing readability. Donald Knuth warned that programmers obsessing over efficiency in the wrong places produce needlessly complicated code, and that the resulting complexity actively hurts debugging and maintenance https://lawsofsoftwareengineering.com/laws/premature-optimization/ . Net efficiency goes down, not up. Swap "efficiency" for "brevity" and you've described exactly what happens when a vibe coder decides the lesson of the last section was "fewer lines good" instead of "lines were never the point." It's the same mistake wearing a different hat — optimizing for a number instead of for the thing the number was supposed to be a proxy for. More lines isn't good, fewer lines is also not good. The lines of code aren't the point. There are many factors that go into understanding the state of any codebase, like can a stranger or a future version of you understand why the code is shaped the way it is, and not just what it does? DORA's four keys https://dora.dev/guides/dora-metrics/ are how often you ship, how long a change takes to reach production, how often a deployment breaks something, and how long it takes to restore service. Really, though? Code is not the point. Code is what you write after you've found something that needs it. A 1951 book review coined the phrase https://quoteinvestigator.com/2026/02/25/solution-search/ , "a solution in search of a problem". SISP. To build something you believe is impressive and then searching backward for a problem it can be pointed towards https://medium.com/uwaterloo-voice/solutions-in-search-of-a-problem-7a3006eba458 . A SaaS-focused blog defending vibe coding's staying power made the point despite itself: building the software was never the hard 80%, understanding who actually struggles with a problem, and what they'd pay to have it solved https://thebootstrappedfounder.com/vibe-coding-wont-kill-saas/ , was. Generating the app is "free" now, sure. Knowing what the app is for still isn't. Friction used to sit between "idea" and "shipped product," forcing you to sit with a problem and understand it. What are people sitting with, now? Fun is being used very liberally here, as you might be able to tell. ↩︎ fnref1