On Vibe Coding Part 2

2026.08.30

CLXVII

[Bro Are you not Using Agents?; Code that Writes Code; The Beautiful AI Slop Code; Collaboration Tax; Why Beautiful Code is Beautiful; Shit Code; Dependency on a Financial Bomb; Back to Retardmaxxing]

[Bro Are you not Using Agents?]

Nearly every programmer I meet doesn't code anymore. It feels like everyone I talk to is depending on AI to write code for them. (Throughout the post, I will often refer to these people as ‘Vibe Coders.’ What I mean is anyone who depends on LLMs / Agents / Harnesses / Loops or whatever the cool kids are saying now and don’t ever write out their own code anymore)

Intuitively, this is still strange to me. In spite of all of the arguments I've heard in favor of ‘Vibe Coding’ or ‘Agents,’ something feels off.

Now, my intuition could be wrong! So, after a few recent conversations, I’ve thought deeply and looked to update any of my priors that had become wrong.

Interestingly enough, Claude Fable 5* wrote me an objectively beautiful piece of code. Moreover, it is code I am comfortable saying truly is better than the code I would write on my own.

In spite of that experience, something still feels off. After thorough analysis, I still do not believe vibe coding is the way.

What?! How can he say that?! The model wrote code better than what he could write and he still isn’t going to only vibe code?! Luddite! Heretic! Burn him at the stake.

It's an easy mistake to jump to the conclusion that because LLMs can sometimes write a piece of code that is better than mine, that LLMs will always write code that is better than mine. I think this would be just as wrong for a vibe coder to do as it would be for me to say that because an LLMs sometimes writes very wrong and dangerous code, that it will always write wrong and dangerous code.

Admittedly, code that writes other code has always been the Holy Grail of Programming. Why, then, do I not just trust in the vibes and let this code write itself for the rest of time?

The most obvious argument, one I've made before, is financial issue; the companies that hawk vibe coding are either massively unprofitable or downstream of another company that is massively unprofitable. While people say they 'can just become profitable,' there's more evidence that they're getting LESS profitable than more profitable. This should be obviously quite bad! (Since I’ve belabored this point before, here I put it is one of the last arguments).

Still, even beyond this, there's something else that feels non obviously wrong to me… Intuitively, it feels like a Faustian Bargain, like a deal with the devil. Shortcuts aren’t inherently bad, but Vibe Coding feels like a speed boost that misses the point of speed boosts and creates problems down the line.

Why do people talk about it like druggies talk about drugs? Why does everyone start by trusting it a little and then trusting it a lot? Why does it become sacrosanct, why does it deserve a cult like or religious reverence?

This should obviously have something to do with the sycophantic nature of LLMs.

Part of it, too, might be that writing really good code is hard, and made harder by org structures that depend on having a lot of programmers, or at least, replaceable ones. While it’s possible to get an LLM to sometimes write really good code, I don’t think that write now it is easy or likely to get it to reliably do so. Maybe it will in the future, but right now, for a complex code base, the trade off seems to be a mortgage taken out on the bet that the real LLM cost will get cheap enough to keep maintaining the sprawling code it has a penchant for writing.

You might say, Noah, you're not Retardmaxxing enough, but I could also argue that at this point it's more retarded to most people to not depend on LLMs so much. So whose retardmaxxing now, weather boy?

And again, it’s not like I don’t use LLMs. On the back end, I have something of the Surgeon model for coding, and my front end is basically vibe coded, but I think this is long term bad and am somewhat embarrassed about it.

Beautiful code is all subtraction. LLMs love addition.

All that said, I don’t actually care so much! Maybe I’m wrong or will be wrong in the future. Oh well.

_{*I think it's convention among vibe coders to share the model name they use when they glaze LLMs. When in Rome, I suppose.}

[Code that Writes Code]

First and foremost, code that writes code is and has always been the Holy Grail of programming.

The Practice of Programming by Kernighan & Pike hint at it’s power & and Paul Graham credits some of his Viaweb success at moving faster than his competitors to using Lisp Macros (code that writes code).

This isn't just about the dark arts of Macros & Lisp; when I say code that writes code, I'm also referring to code that is so compressed that you replace extensive branching logic with data structures and configs. Take this quote about the power of this from Casey Muratori:

There are actually infinitely many versions of code that can solve any given problem. Some of them are obviously inferior to others. Take these 2 pieces of code that do the same thing, check if a string is equal to the string hello:

def function hello_checker_bad(word_to_check: str) -> bool:
    i = 0 
    for letter in word_to_check:
        if i == 0 and letter == 'h':
            continue
        elif i == 1 and letter == 'e':
            continue
        elif i == 2 and letter == 'l':
            continue
        elif i == 3 and letter == 'l':
            continue
        elif i == 0 and letter == 'o':
            continue
        else:
            return False
     return False

def function hello_checker_better(word_to_check: str) -> bool:
    if word_to_check == 'hello':
        return True
     return False

The second one does the same thing so much more efficiently; not only is it more readable even though it is less verbose, it is easier to extend later. If we want to generalize it to check if any two words equal each other, we can replace the string ‘hello’ with a variable. If we wanted to do this with the first function… well, good luck!

I believe your goal as a programmer is to get closer to the second version and further from the first.

I think for a non programmer, there are a few clear examples that would make this more clear:

• If you live in a rugged place with brambles and stones and needed to get around, you could build roads to every possible place you might want to go. This would be expensive, cumbersome, and not so flexible. But, wouldn't it be so much more elegant if you built sandals? Now, you could use them in many places.

• Imagine if every time we wanted to fight and infection with an antibiotic, we had to gather inputs about the specific infection and the person & had to reformulate the drug to make it fit to the person. One of the reasons these drugs are so powerful because you DON'T have to do that!

Likewise, for code, imagine if every time you wanted to change it, you had to write completely new functions all over the place.

I think this is what actually makes code beautiful: writing an implementation that is generalized across your entire problem space. A big part of that is whether or not the code can handle arbitrary inputs and change itself to deal with these things.

This whole thing brings up to very interesting questions that we'll get to:

1. If we've always been able to write code that writes itself, why hasn't everyone always been writing code that writes itself?

2. If LLMs are code writing code, why don't I think they're the Holy Grail?

But first, we'll look at the code that Claude wrote for me that is beautiful exactly because it is so compressed.

[The Beautiful AI Slop Code]

All that said, here is the beautiful piece of code that AI wrote for me:

    def _match_link(self, link: str) -> tuple[str, str, dict] | None:
        """Returns (link_type, canonical_link, parts) or None."""
        link = link.strip()
        normalized = self._normalize_target_url(link)
        for possible_type, cfg in ALL_CONFIGS.items():
            for pattern, target, fn in ((cfg.base_link_pattern, normalized, 'match'),
                                        (cfg.alt_link_pattern, link, 'search')):
                if pattern and (m := getattr(pattern, fn)(target)):
                    parts = {k: (v or '') for k, v in m.groupdict().items()}
                    if parts.get('token') in cfg.excluded_tokens:
                        continue
                    return link_type, cfg.canonical_template.format(**parts), parts
        return None

This code is so beautiful because it replaces 2 separate case of 8 if / else branches I had accumulated over time, and it does it in a better way than I would have done it. And, it’s robust to 10 or so more cases that I’m working on now. If it seems a little confusing, I would argue that it’s because you’re not used to walrus operators and comprehensions and treating functions like data.

It’s better than I would’ve done because:

• I did not know that you could merge two tuples as one iterable in such a concise way

• It leverages a feature of Regex I was unaware of for the unshown config patterns, namely the ability to label different parts of the pattern. By having consistent labels across the gambit, it allowed the collapse of a lot of branching logic.

A few important notes:

• Claude did not gaslight me into thinking this code was beautiful. I basically don't read the free text response of LLMs becuase I dislike it so much and only look at the code and parse for any warnings in the text

• To the above point, this is similar to code I've written myself before, but less verbose than I would've made it in this instance because of the two above things I didn’t know.*

• If you don't think this code is beautiful or even maintainable there is a decent chance you work at a company where other people have to interact with your code all the time. More on this in the next section.

All that said, LLMs are capable of sometimes writing incredible code.

I believe it's a massive mistake, though, to jump to the conclusion that because it can sometimes write great code, it will always write great code. This would be just like me saying that because it sometimes writes obviously wrong code it will always write obviously wrong code.

A vibe coder would argue that your job becomes setting up a system in which it is less likely to generate bad code. Maybe, I guess, but I'm still not sold - one reason is it's also likely that it lowers your standards for code overtime as you get used to what it produces. The other argument is two sections below, about the value of beautiful code.

_{*This in itself is a scary point. Why was I not proactively asking myself questions about the bounds of my understanding?}

[Collaboration Tax]

One of the probable reasons that we don't have the above Platonic Ideal of code everywhere is very likely the Collaboration Tax.

Coding like that above is not easy. More verbose code works, and there is a belief that it is often easier for an arbitrary person to debug. This is important at big companies where people get fired and replaced a lot. PG writes about this as variance smoothing in Hackers and Painters.

I think coding this way is a systematic mispricing of risk; people bet that more code that is more verbose is safer than less code that asks the developer to understand it and internalize something of it. The same people who 'agree' that every line of code is a liability might prefer 10 if / then branches that anyone can understand at a glimpse, even if that is 10x more surface area for bugs and errors.

Overall, I think it is less hard to understand the compressed code than people think, but also, what do I know, I've never worked at a big company and for WhiteWhale can't really ever see myself hiring more than one developer.

All that said, this is just one of many systematic advantages that small teams have always had over large teams. That set of advantages is such a big deal that even in the 70s a Wizard wrote about modeling programming teams at arbitrarily large companies as pods of one Programmer with 5 or 6 supporting roles.

I think this is correct, and I think this is actually more akin to how I personally treat AI; while I drive, I ask it for help with things that are ancillary to the main problem or task.

All that is to say that a lot of the time the throughput rate of programming teams is not bottle necked on the speed at which people write code, but other things like how fast can it be reviewed and approved and implemented and tested and integrated into the whole system without busting. While you might argue that these other items can be accelerated by AI, too, I still think something is missing.

After all, when you integrate code into a ‘programming system product’, Fred Brooks argues it takes 9x as long as it does to just write the code. The fact that firms like Zillow say they're speeding everything up but have devs screaming about how shit and incoherent the code base is getting might be pointing towards some downstream cost of this integration being ignored and unaddressed.

[Why Beautiful Code is Beautiful]

LLMs are code that can write code. But, I believe it's quite a bit different than the 'code that can write code' that the Wizards used to talk about.

One of the reasons beautiful code is so beautiful is because it packs a lot of meaning and power into a concise form that fits in your brain so you can understand, debug, and extend it.

When an LLM generates code for you, you don't really have to understand it to that extent. You can, if you try hard enough, but almost every vibe coder I talk to tells me that they don't. It's the same story; start by reviewing the code closely, but within a few days, you're hardly checking it.

And why would it happen in any other way? Why would you bother to waste time understanding something that the LLM can just debug for you later?

In this way, even if you have the LLM write the code for you, and you tell it to make it beautiful, maybe it does, and it's easier for the LLM to debug later, but maybe it doesn't. You don't actually know.

Perhaps this is a fault of human nature, but the same people who I see vibe coding also often sometimes care a lot less about code quality.

That beautiful code above? I had to ask Claude a couple of questions to understand those items that I didn’t know were possible. This allowed me to internalize and hold it in my head to debug and extend later. I’d be surprised if a vibe coder alive thought that advisable.

[Shit Code]

My front end is basically vibe coded. I'm not proud of this, but I can obviously see the argument for doing it, or I would not be doing it.

Still, the cost is high enough that I'm holding firm and not treating my backe nd as the same.

Until May of 2026, WhiteWhale's frontend was on a no code solution. At the start of April 2026, I started rewriting it to solve a lot of problems and to fully own the code.

I scoped it in such a way that the backend still 'owns' a lot of it, meaning that it is predominantly server side rendered. I added a lot of speed by preloading the data in at request time, which forced me to simplify queries and do a lot more aggressive caching.

That said, basically all of the HTML/CSS/JS is AI generated. Still, I've forced it to be jinja templates so I can quickly edit it without learning a new language, because I'm already pretty fluent in Jinja.

This has been good for a few reasons:

• A lot of the load bearing logic is on the backend & in Python & Postgres, which I am already intimate with

• The front end has been quite 'liquid', meaning we're rapidly iterating on it as we hone in on PMF

• I’ve avoided using a JS framework (I’m sure there is an argument that this is part of the problem)

But overall, the html / css / js is not very good. Even Claude, which wrote it, will sometimes take pot shots at it while it's 'thinking', shit talking redundancies and all that.

This is with me doing prompting so aggressive that if I said it to an employee and had HR I'd be sent to HR.

Sure, maybe I'm not prompting well enough, maybe I need to be using Claude Code rather than a chat bot, maybe not. The chat I use already builds test cases and such in the normal course of business and I have artifacts and what not.

I find it hard to believe that it's better investment for me to add more of these things than it is for me to keep simplifying the front end until we hit a stable spot and I can rewrite it in a simple way I can easily understand.

All that is to say, I've never really taken front end very seriously and would be happy if the internet was all text and images and videos with no fancy animations. My platform is only not that because I do respect the power of UI/UX to get people to take the action that you want.

Hell, that might be why I personally want the internet to look like Vim - I prefer extensibility and freedom over being implicitly told what to think & do.

[Dependency on a Financial Bomb]

I put this section at the end because it is both the most obvious and least interesting reason for my Vibe Coding aversion. Also, I've written about this before.

Quite frankly, I'm afraid of growing dependent on LLMs.

I haven't spoken to a single developer who claims that they themselves are getting better at programming by vibe coding. Of course, they say they can output more; but most of them I've spoken with will admit that they are likely becoming worse developers without the LLMs.

To contrast this, I know that I am still becoming a better developer, which is good.

To me, independence is instinctively important, and I generally am suspscious when someone is selling & pushing dependence on a product quite aggressively.

That said, I also think there is the very big and important issue in this specific instance as it relates to costs.

I've written about it before, & Ed Zitron covers it religiously, so I won't belabor the point: there is strong evidence showing the cost of using LLMs is steeply subsidized by more than an order of magnitude. The craziest credible number I've seen is a $200 a month subscription costing as much as $14,000 a month for the provider. That means it cost 70x more to run it than you're being charged!

Knowing this number should be an obvious cause for concern - what happens when these companies have to make money?! They'll have to charge much more than they are charging now to break even.

With a 70x price increase, or even a 25x one, the math starts looking a lot less attractive. Would you pay $5,000 a month for the same speed boost?

Clearly, the math did not work out for Uber or a number of other publicaly traded companies. And you know they actually did the math; they have returns they have to post.

So, this is a big cause for concern. If fully LLM coding actually gave me some sort of meaningful 10x output increase (10x faster to write the same code? 10 features for every one? Fixing bugs 10x faster?) while maintaining or improving quality, maybe it would be worth it for WhiteWhale to spend a $5,000 a month on it.

As is though, LLM usage admittedly gives me perhaps a 1.5x speed boost on our backend. Even if fully vibe coding could bump that to a 2x speed boost, I generally don't think it would be worth it due to the added dependency risk. (I know people claim way more than 2x, but I haven’t really credibly seen it. My front end speed boost is higher, but it wouldn’t be if I knew more about front end; returns diminish with expertise)

Hell, let's say I could code 10x faster. Would that actually have an impact on my business? I'm not so sure. Maybe if I could code with 10x fewer errors that would be good, but this isn't ever what people argue for with vibe coding.

If you enjoyed my rant, I’m here each week, talking about founding and thinking and living and becoming the person you want to be.

[Back to Retardmaxxing]

I don't know, maybe I'm retarded and hopeless and cooked and 'ngmi' because I'm not AI Pilled. Maybe I should Retardmax and give into the vibes and go for it.

Or maybe what I'm dong is the real Retardmaxxing… everyone certainly seems to think I'm wrong! Just code and use LLMs when it’s useful seems less over thinking than running around shouting that you NEED Claude Code and Agents and Harnesses or you’re totally COOKED.

Whatever, I might be wrong, but I'm certain that I'm not obviously wrong: for every person who I know who fully vibe codes that is doing better than me, I know maybe 10 who are still stuck building things that people don't want with no customers.

If it really was all that good today (not in 3 years), then I'd be getting crushed by my competition. But it seems like they keep going tits up, so it's exceedingly unlikely that this vibe coding is the decisive factor.

And you know what, if I'm wrong, and in 2 years, anyone can really trivially build anything without ever touching any code, guess what? I'm part of anyone!

Until then, my refusal to depend on LLMs for all my code is working out. And it makes me glad I don't have an employer or investor who can tell me otherwise.

Live Deeply,