Live data from Hacker News

The cult of vibe coding is dogfooding run amok

bramcohen.com

351–360 of 555 posts

Re: The cult of vibe coding is dogfooding run amok

#351
post #259

How credible are the claims that the Claude Code source code is bad? AI naysayers are heavily incentivized to find fault with it, but in my experience it's pretty rare to see a codebase of that size where it's not easy to pick out "bad code" examples. Are there any relatively neutral parties who've evaluated the code and found it to be obviously junk?

Do you not think that ~400k lines of code for something as trivial as Claude Code is a great indication that there is an immense amount of bloat and stacking of overwrought, poor "choices" by LLMs in there? Do you not encounter this when using LLMs for programming yourself?

I routinely write my own solutions in parallel to LLM-implemented features from varying degrees of thorough specs and the bloat has never been less than 2x my solution, and I have yet to find any bloat in there that would cover more ground in terms of reliability, robustness, and so on. The biggest bloat factor I've found so far was 6x of my implementation.

I don't know, it's hard to read your post and not feel like you're being a bit obtuse. You've been doing this enough to understand just how bad code gets when you vibecode, or even how much nonsense tends to get tacked onto a PR if someone generates from spec. Surely you can do better than an LLM when you write code yourself? If you can, I'm not sure why your question even needs to be asked.

Re: The cult of vibe coding is dogfooding run amok

#352

Earlier quoted context omitted.

This is the product that's claiming "coding is a solved problem" though. I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.

No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.

It really shows that nobody cares about uptime at github or the jankiness of claude.

I wouldnt say that customers are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.

Re: The cult of vibe coding is dogfooding run amok

#353
post #139
post #57

In my opinion there are two main groups on the spectrum of "vibe coding". The non technical users that love it but don't understand software engineering enough to know what it takes to make a production grade product. The opposite are the AI haters that used chatgpt 3.5 and decided LLM code is garbage. Both of these camps are the loudest voices on the internet, but there is a quiet but extremely productive camp somew…

> extremely productive camp somewhere in the middle How do you quantify and measure this productivity gain?

These kinds of comments are so spectacularly useless. It was almost impossible to measure productivity gains from _computers_ for nearly two decades after they started being deployed to offices in the 1980s.

There were articles as late as the late 1990s that suggested that investing in IT was a waste of money and had not improved productivity.

You will not see obvious productivity gains until the current generation of senior engineers retires and you have a generation of developers who have only ever coded with AI, since they were in school.

Re: The cult of vibe coding is dogfooding run amok

#354
post #259

How credible are the claims that the Claude Code source code is bad? AI naysayers are heavily incentivized to find fault with it, but in my experience it's pretty rare to see a codebase of that size where it's not easy to pick out "bad code" examples. Are there any relatively neutral parties who've evaluated the code and found it to be obviously junk?

Do you not think that ~400k lines of code for something as trivial as Claude Code is a great indication that there is an immense amount of bloat and stacking of overwrought, poor "choices" by LLMs in there? Do you not encounter this when using LLMs for programming yourself? I routinely write my own solutions in parallel to LLM-implemented features from varying degrees of thorough specs and the bloat has never been le…

> Do you not think that ~400k lines of code for something as trivial as Claude Code is a great indication that there is an immense amount of bloat and stacking of overwrought, poor "choices" by LLMs in there?

I certainly wouldn't call Claude Code "trivial" - it's by far the most sophisticated TUI app I've ever interacted with. I can drag images onto it, it runs multiple sub-agents all updating their status rows at the same time, and even before the source code leaked I knew there was a ton of sophistication in terms of prompting under the hood because I'd intercepted the network traffic to see what it was doing.

If it was a million+ lines of code I'd be a little suspicious, but a few hundred thousand lines feels credible to me.

> Surely you can do better than an LLM when you write code yourself?

It takes me a solid day to write 100 lines of well designed, well tested code - and I'm pretty fast. Working with an LLM (and telling it what I want it to do) I can get that exact same level of quality in more like 30 minutes.

And because it's so much faster, the code I produce is better - because if I spot a small but tedious improvement I apply that improvement. Normally I would weigh that up against my other priorities and often choose not to do it.

So no, I can't do better that an LLM when I'm writing code by hand.

That said: I expect there are all sorts of crufty corners of Claude Code given the rate at which they've been shipping features and the intense competition in their space. I expect they've optimized for speed-of-shipping over quality-of-code, especially given their confidence that they can pay down technical debt fast in the future.

The fact that it works so well (I get occasional glitches but mostly I use it non-stop every day and it all works fine) tells me that the product is good quality, whether or not the lines of code underneath it are pristine.

Re: The cult of vibe coding is dogfooding run amok

#355

Earlier quoted context omitted.

If you are a company founder, what scenario would you rather find yourself in? a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model b) a bad codebase but it correctly models and nails the domain model for your business case Real life example, a fintech with: a) a great codebase but stuck with a single-entry ledger b) a bad codebase that perf…

"Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.

> Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box

Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free

Re: The cult of vibe coding is dogfooding run amok

#356

Earlier quoted context omitted.

This is the product that's claiming "coding is a solved problem" though. I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.

No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.

"No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck.

As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve.

Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.

Re: The cult of vibe coding is dogfooding run amok

#357
post #17

AI is just another layer of abstraction. I'm sure the assembly language folks were grumbling about functions as being too abstracted at one point

AI is non-deterministic. Can it still be considered an abstraction over a deterministic layer?

Does it have to be? The etymology of the word „abstraction“ is „to draw away“. I think it‘s relevant to consider just how far away you want to go.

If I‘m purely focused on the general outcome as written in a requirement or specification document, I‘d consider everything below that as „abstracted away“.

For example, this weekend I built my own MCP server for some services I‘m hosting on my personal server (*arr, Jellyfin, …) to be integrated with claude.ai. I‘ve written down all the things I want it to do, the environment it has to work in and let Claude go.

Not once have I looked at the code. And quite frankly, I don‘t care. As long as it fulfills my general requirements, it can write Python one time and TypeScript the other time should I choose to regenerate from that document. It might behave slightly differently but that is ok to a degree.

From my perspective, that is an abstraction. Deterministic? No, but it also doesn‘t have to be.

Re: The cult of vibe coding is dogfooding run amok

#358
post #88

Earlier quoted context omitted.

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…

> and then replacing those hacks with better code just never happens Yeah, we even have an idiom for this - "Temporary is always permanent"

We'll fix it later.

But as a great man once said: Later == Never.

Re: The cult of vibe coding is dogfooding run amok

#359

My favorite uses of Claude code is to do code quality improvements that would be seen as a total waste of time if I was doing them by hand, but are perfectly fine when they are done mostly for free. Looking for repetitive patterns in unit tests/functional tests. Making sure that all json serialization is done in similar patterns unless there's a particularly good reason. Looking for functions that are way too complic…

Absolutely. I've got a nice multi-paragraph prompt on hunting for subtle bugs, user expectation breaks, crufty/repeated code, useless tests (six tests that actually should be one logical flow; assertions that a ternary is still, indeed, a ternary; etc.), documentation gaps, and a few other bits and bobs. I sick Opus, GPT5.4, and Gemini on it, have them write their own hitlists, and then have a warden Opus instance go…

Mind sharing that prompt? This is one of my favorite uses for AI too, but I’m just using it to fix the stuff that’s already top of mind for me.

Re: The cult of vibe coding is dogfooding run amok

#360

It’s so strange. I think there’s a few different groups: - Shills or people with a financial incentive - Software devs that either never really liked the craft to begin with or who have become jaded over time and are kind of sick of it. - New people that are actually experiencing real, maybe over-excitement about being able to build stuff for the first time. Forgetting the first group as that one is obvious. I’ve enc…

I’ve encountered a heap of group 2. They’re the ones sick of learning new things, for whatever reason.

I think it's easy to dismiss that group, but the truth is there was a lot of flux in our industry in the last decade before AI, and I would say almost none of it was beneficial in any way whatsoever.

If I had more time I could write an essay arguing that the 2010s in software development was the rise of the complexity for complexity's sake that didn't make solving real world problems any easier and often massively increased the cost of software development, and worse the drudgery, with little actually achieved.

The thought leaders were big companies who faced problems almost no-one else did, but everyone copied them.

Which led to an unpleasant coding environment where you felt like a hamster spinning in a wheel, constantly having to learn the new hotness or you were a dinosaur just to do what you could already do.

Right now I can throw a wireframe at an AI and poof it's done, react, angular, or whatever who-gives-a-flying-sock about the next stupid javascript framework it's there. Have you switched from webpack to vite to bun? Poof, AI couldn't care less, I can use whatever stupid acronym command line tool you've decided is flavour of the month. Need to write some Lovecraftian-inspired yaml document for whatever dumbass deploy hotness is trending this week? AI has done it and I didn't have to spend 3 months trying to debug whatever stupid format some tit at netflix or amazon or google or meta came up with because they literally had nothing better to do with their life and bang my head against the wall when it falls over every 3 weeks but management are insisting the k8s is the only way to deploy things.

Post reply on HN