There is a new trend sweeping through Silicon Valley and the wider tech world. It is called vibe coding. The premise sounds like a dream for any founder with a vision but no patience for the terminal. You sit back, describe your dream app to an AI agent, and watch as it hallucinates a functional product into existence. No syntax errors, no manual debugging, just vibes.
Recently, Gary Tan, the president of Y Combinator, became the poster child for this movement. He bragged about shipping Gary’s List, a civic access site for San Francisco, claiming the AI generated nearly 400,000 lines of code in record time. On the surface, it looked like a 100x productivity win. But when engineers actually peeked under the hood, they found a digital disaster area.
What happens when you let a raw token predictor build your infrastructure without an adult in the room? You get a 400,000 line monument to inefficiency.
The Quantity Fallacy: Why 37,000 Lines a Day is a Red Flag
In the old world of engineering, writing fewer lines of code to solve a problem was considered the ultimate flex. It meant your logic was tight, your abstractions were clean, and your maintenance burden was low.
Vibe coding flips this on its head. When Gary Tan celebrated 37,000 lines of code produced in a single day, he was effectively bragging about the size of his technical debt. AI does not care about elegance. It does not care about modularity or keeping things DRY (Don't Repeat Yourself). It just wants to satisfy the next token in the sequence.
If you ask an AI to add a button, it might copy and paste an entire CSS library just to style that one button because it is the fastest way to "fulfill the vibe." Multiply that by a thousand prompts, and you have a codebase that no human can ever audit or fix. Quantity is not a badge of honor in software; it is usually a warning sign that the architecture is non existent.
A Performance Horror Story: The Audit
When developers audited the Gary’s List website, which is built on Ruby on Rails, the results were staggering. The homepage load required 169 separate requests. For context, a site like Hacker News is legendary for its speed and simplicity. Gary’s List was found to be 562 times heavier than Hacker News.
Loading a single homepage required transferring 6.4MB of data. In a world where we fight for milliseconds and mobile users have limited data plans, shipping a 6.4MB homepage for a basic list of names and links is offensive. It is the architectural equivalent of building a shed out of solid lead.
Why was it so heavy? Because the AI had no concept of a build process or optimization. It simply threw every ingredient into the pot and hoped the browser could sort it out.
Shipping the Kitchen Sink (And 28 Test Files)
One of the most glaring errors found in the audit was the inclusion of 28 actual test harness files in the production environment. These are files meant for internal testing during development. They have no business being served to a visitor.
Yet, because the "vibe" was just to ship as fast as possible, the AI included them in the public bundle. Every person visiting the site was forced to download these unnecessary files. It is a massive security risk and a sign that the deployment pipeline was essentially non existent.
The logo management was even more chaotic. The audit revealed that the site was downloading the same bear logo eight different times in different formats. One of those files was a 0 byte broken file. Another 4MB consisted of uncompressed raw PNGs, even though the browser specifically requested WebP. The AI ignored the request for modern formats and just dumped the heaviest files available into the DOM.
Double Rendering and the Ghost in the DOM
The technical debt did not stop at file sizes. The structure of the site itself was a mess. Inspectors found multiple title tags in the <head> section and a double rendered DOM.
When a human writes code, they understand the hierarchy of an HTML document. When an AI "vibe codes," it might generate one part of the site, forget it exists, and then generate it again when prompted for a change. Without a human to prune the branches, the code grows into a tangled thicket.
The audit also found empty CSS files being served to the client. Why? Because the AI started a task, got distracted, and nobody told it to stop. These empty files still require a request and a handshake, adding more latency to an already bloated experience.
The Accessibility Crisis
Perhaps the most disappointing part of the Gary’s List saga was the total failure of accessibility. This was a site designed for civic engagement in San Francisco. It is the one place where you absolutely cannot afford to ignore users with visual impairments.
The audit found 47 images with empty alt text. For a user with a screen reader, those 47 images simply do not exist or are read out as gibberish. This is not just a "vibes" issue; it is a fundamental failure to build for the community. It proves that while AI can predict what a website looks like, it has no understanding of who the website is for.
AI is a Token Predictor, Not an Engineer
The core of the problem is a misunderstanding of what Large Language Models actually do. AI is a raw token predictor. It is a high speed statistical engine that guesses what comes next based on patterns. It does not have intent. It does not have a mental model of how a database should scale or how a user feels when a page takes five seconds to load.
Vibe coding assumes that the "feeling" of the prompt is enough to ensure the quality of the output. But software engineering is about constraints, edge cases, and longevity. If you have no process, AI just magnifies the mess. It gives you 400,000 lines of slop instead of 40 lines of clear logic.
The 100x Trap and Shipping Streaks
We are currently seeing the "100x Trap" play out in real time. Organizations like Y Combinator often push for "shipping streaks" and rapid iteration. In the pre AI era, this meant working harder and smarter. In the AI era, it has turned into a race to see who can generate the most "slop" the fastest.
This culture is creating a generation of "AI pilled" developers who value the act of shipping over the quality of the product. They are trading their reputations for a momentary dopamine hit of a "Live" URL. But as the Gary’s List audit shows, the internet never forgets a 6.4MB homepage. Building with AI should make us better architects, not just faster typists.
The Fenix Ethos: Meaning vs. Trash
In our philosophy, we believe in building tools with meaning. There is a "Fenix" ethos to creation: you take the raw elements and refine them into something powerful and lasting. True creation is not about dumping 400,000 lines of automated trash onto a server. It is about using the best tools available, including AI, to reach a higher level of precision.
AI is an incredible tool for brainstorming, boilerplate generation, and refactoring. But it is not a replacement for code review or architectural intent. If you let the "vibe" drive the car, you are going to crash into a wall of technical debt.
Conclusion: Don't Let Your Vibe Crash
The lesson from the 400,000 line disaster is simple: Engineering still matters.
AI can give you a head start, but it cannot finish the race for you. If you are not looking at your network tab, if you are not checking your alt tags, and if you are not auditing your requests, you are not building a product. You are just creating a very expensive hallucination.
Use AI to empower your engineering, not to bypass it. Don't let your "vibe" crash your production environment. Build something that is light, fast, and accessible. Because at the end of the day, 40 lines of code that work perfectly for every user will always beat 400,000 lines of AI slop.
