{"slug": "adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad", "title": "Adding Thousands of Lines to Your Codebase Isn't Impressive. It's Actually Bad.", "summary": "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.", "body_md": "# Adding Thousands of Lines to Your Codebase Isn't Impressive. It's Actually Bad.\n\nVibe 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?\n\nHowever, this layer, unlike all the previous ones, is non-deterministic and yet has a far more intensive cost despite that.\n\nYou now have the ability to jump right into coding a project without understanding the fundamentals of syntax, or basic concepts like loops, `if/else`\n\nstatements, 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.\n\nThere 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).\n\nBut 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.)\n\n## The Numbers Just Keep Getting Bigger\n\nTo 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.\n\nSorry to put you on blast, Stephen Collins, but don't worry. I'll put others on as well.\n\nAustin 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.\n\nCursor'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.\"\n\nA 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.\n\nA [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.\"\n\nA 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.\n\n## Weighing the Airplane\n\nSomewhere 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).\n\nA 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.\n\n[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.\n\nA 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.\n\n## Code Golfing\n\n[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.\n\nThey'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:\n\n```\nfor i in range(1, 101):\n    if i % 15 == 0:\n        print(\"FizzBuzz\")\n    elif i % 3 == 0:\n        print(\"Fizz\")\n    elif i % 5 == 0:\n        print(\"Buzz\")\n    else:\n        print(i)\n```\n\nAnd here's a golf version:\n\n```\nfor i in range(1,101):print(\"Fizz\"*(i%3<1)+\"Buzz\"*(i%5<1)or i)\n```\n\nIf you'd like to know how this code works:\n\nreturns a boolean (`i%3<1`\n\n`True`\n\n/`False`\n\n), which Python silently treats as`1`\n\n/`0`\n\nwhen used in arithmetic.exploits string-repetition: multiplying a string by`\"Fizz\"*(i%3<1)`\n\n`1`\n\ngives you the string back, multiplying by`0`\n\ngives`\"\"`\n\n. So this either produces`\"Fizz\"`\n\nor nothing, depending on divisibility.- Concatenating the two conditional strings naturally handles the \"FizzBuzz\" case for free, and there's no need for a separate\n`%15`\n\ncheck. is sneaky: if both conditions failed, you're left with`... or i`\n\n`\"\"`\n\n, which Python considers falsy, so`or`\n\nfalls through to`i`\n\n. If either string got built, that string is truthy, so`or`\n\nshort-circuits and returns it instead.\n\n## ...But Short Also Doesn't Mean Good\n\nA vibe coder might read the section about lines-of-code bragging and conclude the fix is fewer characters. It isn't.\n\nThe golfed FizzBuzz above is short and confusing. The `\"Fizz\"*(i%3<1)`\n\ntrick 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.\n\nOptimization 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).\n\nPython'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.\n\nChasing 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.\n\nDonald 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.\n\nMore 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.\n\nReally, though? Code is not the point. Code is what you write after you've found something that needs it.\n\nA [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).\n\nA 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.\n\nGenerating 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.\n\nWhat are people sitting with, now?\n\nFun is being used very liberally here, as you might be able to tell.\n\n[↩︎](#fnref1)", "url": "https://wpnews.pro/news/adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad", "canonical_source": "https://brennan.day/adding-thousands-of-lines-to-your-codebase-isnt-impressive-its-actually-bad/", "published_at": "2026-07-22 02:00:00+00:00", "updated_at": "2026-07-22 10:29:13.869148+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "large-language-models", "generative-ai"], "entities": ["Stephen Collins", "Austin Starks", "NexusTrade", "Michael Truell", "Cursor", "Ashley Childress", "John Crickett", "Bill Gates"], "alternates": {"html": "https://wpnews.pro/news/adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad", "markdown": "https://wpnews.pro/news/adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad.md", "text": "https://wpnews.pro/news/adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad.txt", "jsonld": "https://wpnews.pro/news/adding-thousands-of-lines-to-your-codebase-isn-t-impressive-it-s-actually-bad.jsonld"}}