It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work.

If anything, it’s the exact opposite. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, and a lot of the terrible code that makes it to production was shocking when I first started.

This isn't a dig at anyone, I've certainly shipped my share of bad code as well. Deadlines, despite my wishes sometimes, continue to exist. Sometimes you have to ship a hack to make a customer or manager happy, and then replacing those hacks with better code just never happens.

For that matter, the first draft of nearly anything I write is usually not great. I might just be stupid, but I doubt I'm unique; when I've written nice, beautiful, optimized code, it's usually a second or third draft, because ultimately I don't think I fully understand the problem and the assumptions I am allowed to make until I've finished the first draft. Usually for my personal projects, my first dozen or so commits will be pretty messy, and then I'll have cleanup branches that I merge to make the code less terrible.

This isn't inherently bad, but a lot of the time I am simply not given time to do a second or third draft of the code, because, again, deadlines, so my initial "just get it working" draft is what ships into production. I don't love it, and I kind of dread of some of the code with my name attached to it at BigCo ever gets leaked, but that's just how it is in the corporate world sometimes.

I'm skeptical of the whole thing, it almost seems like a marketing campaign to encourage developers to use more tokens.

My experience as a software engineer, including with Claude Code itself, is that the more code you have, the more bugs there are. It quickly turns into a game of Whac-a-Mole where you fix 1 bug and 2 new bugs appear.

Looking at the functionality of Claude code. There is no way it requires 500k lines of code as claimed. It would make it very difficult to debug... Though it seems they have a team of 10 people which is a lot for a CLI wrapper.

It's more likely that somebody ran the real code through an agent to intentionally obfuscate it into a more complicated form before they leaked it. This is trivial to do with LLMs. You can take any short function of a couple of lines and turn it into a function hundreds of lines long which does the exact same thing.

It's actually a great way to obfuscate code in the AI era because LLMs are good at creating complexity and not good at reducing it. I've done tests where I ask Claude to turn a simple 1 line function which adds two numbers together into a 100 line function and when I asked it to simplify it down, it couldn't reduce it back to its original simple form after multiple attempts. I had to explicitly tell it what the original form of the function was for it to clean up properly. This approach doesn't scale to a whole codebase. Imagine doing this to an entire codebase, it would take more time for you to read and understand each function to tell the LLM how to clean it up than just re-generating the entire app from scratch.

The problem with large amounts of code is not only that it's harder to maintain and extend, it's often less performant.

While LLMs can allow us to get more out of bad code, they will allow us to get even more value out of the equivalent good code when it comes to maintainability, reliability and efficiency.

Bad code works fine until it doesn't. In my experience, with humans, doing the right thing is worth it over doing the bad thing if your time horizon is a few months. Once you're in years, absolutely do the right thing, you're actually throwing time away if you don't. And I don't mean "big refactor", I mean at-change-time, when you think "this change feels like an icky hack."

For LLMs, I don't really know. I only have a couple years experience at that.

> you can build a crazy popular & successful product while violating all the traditional rules about “good” code

which has always been true

1. "Vibe coding" is a spectrum of how much human supervision (and/or scaffolding in the form of human-written tests and/or specs) is involved.

2. The problem with "bad code" has nothing to do with the short-term success of the product but with the ability to evolve it successfully over time. In other words, it's about long-term success, not short-term success.

3. Perhaps most importantly, Claude Code is a fairly simple product at its core, and almost all its value comes from the model, not from its own code (and the same is true on the cost side). Claude Code is relatively a low stakes product. This means that the problems caused by bad code matter less in this instance, and they're managed further by Claude Code not being at the extreme "vibey" end of the spectrum.

So AI aside, Claude Code is proof that if you pour years and many billions into a product, it can be a success even if the code in the narrow and small UI layer isn't great.

Still, it's probably true that Claude Code (etc) will be more successful working on clean, well-structured code, just like human coders are. So short-term, maybe not such a big deal, but long-term I think it's still an unresolved issue.

It is always amazing at how crap some code can be and yet still function, usually to the total bemusement of the coder. "It shouldn't work but it does?!"

When I used to contract code for some game engine stuff back in the 2000's early 2010's, that was essentially my working standard. Essentially gave a boiler plate terms of my work. I will make it work, I will get it done quickly, it will run fast BUT you will incur a lot of technical debt in doing so. In a games engine it isn't a big deal, you are essentially just pushing pixels around a screen in a sand-boxed system. "Yeah, the decompression system does some odd things with memory addresses but it is quick and plays nice with your streaming system. Just don't change the overall mapping too much and it should ship ok.". "In this level of your game, I have this explicit exception code that prevents that streaming system from booting out too much necessary data. Don't change this unless you want a headache"

I shudder to think of what that style of code would do in a work environment with serious consequences.

I suspect we will find out a lot more of this in the decades to come.

One truism about coding agents is that they struggle to work with bad code. Code quality matters as much as always, the experts say, and AI agents (left unfettered) produce bad code at an unprecedented rate. That's why good practices matter so much! If you use specs and test it like so and blah blah blah, that makes it all sustainable. And if anyone knows how to do it right, presumably it's Anthropic.

This codebase has existed for maybe 18 months, written by THE experts on agentic coding. If it is already unintelligible, that bodes poorly for how much it is possible to "accelerate" coding without taking on substantial technical debt.

You can, but:

- Good code is what enables you to be able to build very complex software without an unreasonable number of bugs.

- Good code is what enables you to be responsive to changing customer needs and times. Whether you view that as valuable is another matter though. I guess it is a business decision. There have been plenty of business that have gone bust though by neglecting that.

Good code is for your own sanity, the machine does not care.

This product rides a hype wave. This is why it is crazy popular and successful.

The situation there is akin to Viaweb - Viaweb also rode hype wave and code situation was awful as well (see PG's stories about fixing bugs during customer's issue reproduction theater).

What did Viaweb's buyer do? They rewrote thing in C++.

If history rhymes, then buyer of Anthropic would do something close to "rewrite it in C++" to the current Claude Code implementation.

This, 100x.

I do M&As at my company - as a cto. I have seen lots of successful companies' codebases, and literally none of them elegant. Including very profitable companies with good, loved products.

The only good code I know is in the open source domain and in the demoscene. The commercial code is mostly crap - and still makes money.

What I'm missing so far is how they produced such awful code with the same product I'm using, which definitely would have called out some of those issues.

Perhaps the problem is getting multiple vibe-coders synced up when working on a large repo.

The impression I got from that thread is its quality is dropping, with weird bugs popping up. And I'm pretty sure I remember they announced at one point they switched to that, so the vibe coding had a human-written codebase to start with.

So that sounds to me like it is evidence vibe coding doesn't work well long term.

It kind of reminds me of grammar police type personalities. They are so hung up on the fact it reads “ugly” they can’t see the message; this code powers a rapidly growing $400B company. They admit refactoring is easy, but fail to realize they probably know that too and it’s just not a priority yet.

You can send a submarine down to crushing depths while violating all the traditional rules about "good" engineering, too.

Vibe coding in my opinion is analogous to say borrowing on a credit card to gamble on a startup.

Occasionally, in IRL you hear the feel good story how Fred smith gambled the last $5,000 to save FedEx and so on, but most people with that mindset end up crashing out.

Vibe coding a product runs the risk of acquiring too much tech debt before project is successful.

Product Market Fit is very hard, you need to keep enough room for pivots. Changes in direction will always accumulate debt, even when tech is well written. It is far more difficult when you accumulate debt quickly.

The counterpoint being that procrastinating and over-engineering prematurely or building lot of unrelated tooling and loosing focus can also bring the product down quickly or never let it start .

Being able to vibe code POCs etc is a great tool if done in a controlled limited well defined way.

Just as borrowing cash on your credit card is not always bad, it just usually is.

It basically shifting work to future people. This mess will stop working and will introduce unsolvable obscure bugs one day, and someone actually will have to look at it.

It already costed many developers months and hundreds of dollars worth of tokens because of a bug. There will be more.

It's always been the case that you could make something that sort of worked for a while with terrible code. The problem was that your product would have random regressions all the time (which theirs does!) and as a result no serious buyers would pay for it.

Code quality is a tactical concern and products live or die on strategy.

I wouldn't recommend neglecting tactics if your strategy doesn't put you on the good side of a generational bubble though.

I'd imagine the AI engineers on million dollar TC are not vibe coding the models though, which is the actual sauce.

Not AI but perfect example is Cloudflare. They have implemented public suffix list (to check if a domain is valid) 10 different times in 10 different ways. In one place, they have even embedded the list in frontend (pages custom domain). You report issues, they fix that one service, their own stuff isn't even aware that it exists in other places.

It helps if the product is so revolutionary that people are willing to overlook bugs. Could you imagine a more mundane product with a TUI that flickered all the time where this wouldn't be a showstopper? I believe the bug is fixed now, but it seems crazy that it persisted so long given how obvious the cause was (clear before update). How many more bugs are in CC? As of a few weeks ago there were 5000 or so open issues against it on github.

The success is undeniable, but whether this vibe-coded level of quality is acceptable for more general use cases isn't something you can infer from that.

Yes, that is how Facebook, Yahoo and many other companies started out. But they rewrote their code when it became to big to be maintainable. The problem with shoddy code is not necessarily that it doesn't work but that it becomes impossible to change.

99.999999% of products can't get away with what Anthropic is able to - this is a one in a billion disruptive product with minimal competition, and its success so far is mostly due to Claude the model, not the agent harness

> It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

We already knew that. This is a matter of people who didn't know that or didn't want to acknowledge that thinking they now have proof that it doesn't matter for creating a crazy popular & successful product, as if it's a gotcha on those who advocate for good practices. When your goal is to create something successful that you can cash out, good practices and quality are/were never a concern. This is the basis for YAGNI, move-fast-and-break-things, and worse-is-better. We've know this since at least betamax-vs-VHS (although maybe the WiB VHS cultural knowledge is forgotten these days).

It works, it is popular, sure. Claude's code may be barely old enough to have suffered through its true long-term maintainability problems. They probably also haven't had a lot of rotation/attrition in their staff.

In the end what really matters to most people is does it work. How it is built or works means nothing to them nor should it.

The traditional rules of good code are heuristics that are practical for human developers. A different set of heuristics will emerge for agentic development.

There's also a business incentive for code produced by LLM companies to be hard to maintain. So you keep needing them in the future.

TBH Claude Code is surprisingly shit to use given the technical resources and the amount of money behind it. Looking past the bugs and missing features, it's so obvious it's not built by people who care about the product from a developer/craftsman perspective. It's missing all the signs of polish/care, it feels like someone shipped an internal PoC to prod and kept hacking on it. And now they are just tacking on features to sell more buzzwords and internal prototypes. Classic user facing/commercial software story.

But we (the dev community) are kind of spoiled, because we have a lot of great developer tools that come from people passionate about their work, skilled at what they do and take pride in what they put out. I don't count myself among one of those people but I have benefited from their work throughout my career and have gotten used to it in my tooling.

All that being said Opus is hands down the best coding model for me (and I'm actively trying all of them) and I'll tolerate it as long as I can get it to do what I need, even with the warts and annoyances.

Yes that plus having tens of billions of gulf money certainly helps you subsidize your moronic failures with money that isn't yours while you continue, and fail to, achieve profitability in any time horizon within a single lifespan.

While beeing in the center of a hype vortex which basically suspends market physics. But all that bad code eats serverfarms that are going to cost double when the bubble starts deflating.

devaluing craftsmanship is fundamentally insulting.

> It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

A lot of dollars fix a lot of mistakes.

"Wildly successful but unpolished product first-to-market with a new technology gets dethroned by a competitor with superior execution" is a story as old as tech.

It's also crazy more expensive to run than we thought. That doesn't bode well when their loss-leader period is over and they need to start making money.

It is amazing how much malice did author put into proving the world is stupid, and only few still stand guard of reason.

I think you're all fucking crazy. Or maybe I am?

I can literally see my teams codebase becoming an unmaintainable nightmare in front of my eyes each day.

I use copilot and Claude code and I frequently have to throw away their massively verbose and ridiculously complex code and engage my withering brain to come up with the correct solution that is 80% less code.

I probably get to the solution in the same time when all is said and done.

Honestly what is going on. What are we doing here?

Also, many of the complaints seem more like giddy joy than anything.

The negative emotion regex, for example, is only used for a log/telemetry metric. Sampling "wtf?" along would probably be enough. Why would you use an agent for that?

I don't see how a vibe-coded app is freed from the same trade-offs that apply to a fast-moving human-coded one.

Especially since a human is still driving it, thus they will take the same shortcuts they did before: instead of a formal planning phase, they'll just yolo it with the agent. Instead of cleaning up technical debt, they want to fix specific issues that are easy to review, not touch 10 files to do a refactor that's hard to review. The highest priority issues are bugs and new integrations, not tech debt, just like it always was.

This is really just a reminder of how little upside there is to coding in the open.

Its a buggy pos though, "popular and successful" have never been indicators of quality in any sense.

Honestly for such a powerful tool, it’s pretty damn janky. Permissions don’t always work, hitting escape doesn’t always register correctly, the formatting breaks on its own to name a few of the issues i’ve had. It’s popular and successful but it’s got lots of thorns

I read this posts and I wonder how many people are thisdelusional or dishonest. I am programmer for 40 years and in most companies 90% of coders are so called stack overflow coders or google coders. Every coder who is honest will admit it and AI is already better than those 90%.FAR better. At least most influencer coder start to admit the fact that the code is actually awesome, if you know what you are doing. I am more of a code reviewer and I plan the implementation, what is far more exciting than writing the code itself. I have the feeling most feel the way I do but there are still those stack ovwerflow coders who are afraid to lose their jobs. And they will.

Do we know if the original code was vibe coded? It's like chicken and an egg dilemma.

The model is the product.

It shows that you can have a garbage front end if people perceive value in your back end.

It also means that any competitor that improves on this part of the experience is going to eat your lunch.

Because or in spite of? Claude code works because of Claude being good and network effects. Agentic coding tools are maybe the dumbest code ever for the level of popularity they have.

This is a really wrong perspective on software. Short term monkey style coding does not produce products. You might get money but that is not what it is about.

This is similar to retarded builders in Turkey saying “wow, I can make the same building, sell for the same price, but spend way less” and then millions of people becoming victim when there is an earthquake.

This is not how responsible people should think about things in society

That’s nothing new.

Countless Excel-Solutions are popular and successful but the Macro behind bad.

Bad code doesn’t not work, unfortunately it works.

We are all using Claude despite Claude Code. The day ChudCorp releases a superior model Chud, we are all gone in an instant. There is no moat.

I think it is crazy popular for the model and not the crappy vibe code.

Value to customer. Literally the only thing that matters.

Hardly. Claude Code is basically just a wrapper around an LLM with a CLI.

Obviously it does some fairly smart stuff under the hood, but it's not exactly comparable to a large software project.

But to your point, that doesn't mean you can't vibe code some poorly built product and sell it. But people have always been able to sell poorly built software projects. They can just do it a bit quicker now.

My understanding of OP was not a claim that "vibe coding doesn't work", but that the way Anthropic does it doesn't work. He seems to be specifically criticizing the "hands off the actual code, human" approach and advocating for keeping the human in the loop.

There is already lots of popular software that is violates any concept of good software. Facebook messenger, instagram, twitter, minecraft, balena etcher, the original ethereum wallet, almost anything that uses electron...

Except for the part where it's constantly having quality and reliability issues, even independent of the server-side infrastructure (OOMs on long running tasks, etc).

> It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work.

It's not a proof vibe-coding doesn't work. It's a proof it's shitty, rube-goldberg, crappy code. It doesn't mean there aren't other shitty products out there (the heavy turds Microsoft produced throughout the years do comes to mind for example).

But when you've got a project upvoted here recently complaining that people do run into issue while quickly cut/pasting from Claude Code CLI to, say, Bash to test something because of Unicode characters in Claude Code CLI's output... And when you realize that it's because what Claude Code CLI shows you in the TUI is not the output of the model because there's an entire headless browser rendering the model's output to a webpage, which is then converted to text (and changing at that moment ASCII chars for Unicode ones), you realize that some serious level of fucktardery is ongoing.

It's normal that at times people aren't going full agentic and shall want to cut/paste what they see. I'm not the one complaining: I saw a project complaining about it and people are affected by that terribly dumb ASCII-to-Unicode conversion of characters.

When you can produce turds by the kilometer, a near infinity of turd is going to be produced.

We're not saying it's not working: I pay an Anthropic subscription and use it daily... We're saying it's a piece-of-shit of a codebase.

Shit that works is still shit.

If anyone from Anthropic is reading: STOP FUCKING CHANGING THE CHARACTERS THAT YOUR MODEL DOES OUTPUT.

(now of course it's just one issue out of thousands, but it'd be a nice one to fix)

I found that to be true years ago when I spooled the source of the Twitch leaks.

To me it said, clearly: nobody cares about your code quality other than your ability to ship interesting features.

It was incredibly eye-opening to me, I went in expecting different lessons honestly.

> It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

That was always the case. Landlords still want rent, the IRS still has figurative guns. Shipping shit code to please these folks and keep the company alive will always win over code quality, unless the system can be edited to financially incentivize code quality. The current loss function on society is literally "ship shit now and pay your taxes and rent".

>. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.

The product is also a bit wonky and doesn't always provide the benefits it's hyped for. It often doesn't even produce any result for me, just keeps me waiting and waiting... and nothing happens, which is what I expect from a vibe coded app.

[dead]

Yes, just get hundreds of billions of dollars in investments to build a leading product, and then use your massive legal team to force the usage of your highly subsidised and marketed subscription plan through your vibe coded software. This is excellent evidence that code doesn't matter.

I don't think anyone who used Claude code on the terminal had anything good to say about it. It was people using it through vs code that had a good time.