Live data from Hacker News

The cult of vibe coding is dogfooding run amok

bramcohen.com

441–450 of 555 posts

Re: The cult of vibe coding is dogfooding run amok

#441
post #425

Earlier quoted context omitted.

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.

"Code quality" here isn't referring to some aesthetic value. Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while. They get to the point where fixing one bug causes another, and then the codebase is in such a state that no human or agent can salvage. People who say they don't care about the quality of code produced by agents are those who haven't been evolving non-trivial…

[flagged]

Re: The cult of vibe coding is dogfooding run amok

#442

Earlier quoted context omitted.

If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.

How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either. That said it's so trivial to do, why haven't you done that already?

I have actually, for my personal projects. I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. I have a Java version that works right now and I will likely be pushing it within the next week.

But more generally, I actually have been building some CI stuff to automate how I'm saying.

I don't have much of a say how this is handled at work so they're just committing the generated code, but I actually am doing what I am talking about.

Re: The cult of vibe coding is dogfooding run amok

#443

Earlier quoted context omitted.

You’re missing the group of high performers who love coding, who just want to bring more stuff in the world than their limited human brains have the energy or time to build. I love coding. I taught myself from a book (no internet yet) when I was 10, and haven’t stopped for 30 years. Turned down becoming a manager several times. I loved it so much that I went through an existential crisis in February as I had to let g…

[flagged]

^ This is a troll; new account, troll username.

Re: The cult of vibe coding is dogfooding run amok

#444
post #289
post #227

Earlier quoted context omitted.

To clarify, does this mean that Anthropic employees don't understand Claude Code's code since it's level 7? I've got to believe they have staff capable of understanding the output and they would spend at least some time reviewing code for a product like this?

Yes, I believe the creator has outright stated that they just YOLO vibe and don't even look at the code.

I'm not sure I believe them though, at face value anyway. Or at least, I would suspect the entire spectrum of levels 0-9 are constantly at play at Anthropic (or any sizeable company). Fully disavowing the code as a matter of policy seems needlessly reckless.

(Thanks for visidata btw, awesome tool that helped me with a side project not long ago.)

Re: The cult of vibe coding is dogfooding run amok

#445
post #425

Earlier quoted context omitted.

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.

"Code quality" here isn't referring to some aesthetic value. Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while. They get to the point where fixing one bug causes another, and then the codebase is in such a state that no human or agent can salvage. People who say they don't care about the quality of code produced by agents are those who haven't been evolving non-trivial…

Yep. Good quality, succinct code saves time and money. Always has and always will.

Re: The cult of vibe coding is dogfooding run amok

#446

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'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.

Re: The cult of vibe coding is dogfooding run amok

#447

Earlier quoted context omitted.

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…

Maybe vibe coding gets so good that we completely trash what was written and build from zero. I've seen that with badly written code as well, easier to rewrite than fix the un-goldly mess.

Yes, if you know what you want exactly it is not difficult to rewrite. Writing is the easiest part of coding.

The challenge is knowing exactly what is needed. No matter how bad the code, it is never easy to justify a rewrite .

In a large and old enough code base, documentation is always incomplete or incorrect, the code becomes is the spec. Tens or hundreds of thousands of hours would have been expended in making it "work". A refactor inevitably breaks things, because no single person can fully understand everything.

There is a reason why it is a well know principle don't fix what is not broken. Same reasons why we still have banking or aviation systems still running mainframe and COBOL from 70s.

A rewrite requires the same or likely more number of hours of testing and adoption in a typically much shorter span of time in ironing out the issues [1]. Few organizations either private or public have the appetite to go through the pain and if its money facing or public facing component it is even harder to get buy-in from leadership or the users of app even.

---

[1] During the original deployment the issues(bugs or feature gaps) would have been incrementally solved over many years or decades even. During the rewrite you don't have 10-20 years, so you not only have to expend the same or more number of hours you will have to do it much quicker as well.

Re: The cult of vibe coding is dogfooding run amok

#448
post #425

Earlier quoted context omitted.

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.

"Code quality" here isn't referring to some aesthetic value. Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while. They get to the point where fixing one bug causes another, and then the codebase is in such a state that no human or agent can salvage. People who say they don't care about the quality of code produced by agents are those who haven't been evolving non-trivial…

> Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while

That's not true, and I'm not sure what that even means. It's totally up to you the human to ensure AI code mergable or evolvable, or meet your quality standard in general. I certainly have had to tell Claude to use different approaches for maintainability, and the result is not different than if I do it myself.

Re: The cult of vibe coding is dogfooding run amok

#449

Earlier quoted context omitted.

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.

For sure. This is a straight copy-paste of my prompt which references my architecture, codebase, references folder (God, that's so golden -- .gitignored, but saving the tokens of googling or cloning and just having the codebases we depend on locally is killer) so this is not ready to be copy pasted. However, with the context that this is an interface for a peer-to-peer encrypted radio mesh client (for MeshCore; my code is https://github.com/jkingsman/Remote-Terminal-for-MeshCore), that can maybe give you a mote of context around things that are obviously key (e.g. sending/receiving) or important but not a topline acceptance criteria (message ordering, async radio operations, etc.) to port this and try it out on your codebase.

Prompts: https://gist.github.com/jkingsman/30a61882917c68c114ee28fe5f...

Also, I say "prior to public release" and obviously, this codebase is super publicly released, but that doesn't matter -- what I'm doing in the prompt is priming my agents for a this matters tone. I have no opinions I'd state publicly on the consciousness argument, but I generally dislike deception; in this case, I find declaring this to be our last ditch review before public release puts it in a context state to be more details-oriented than other primers I tried ("this is our final release" led to too many interoperability/future-proof finds; "this codebase has subtle bugs introduced by an adversarial engineer" had too many security false positives or true-but-absurd positives; "please be detailed and carefully dig deep" just wasn't as good. Plus, the "public release" paradigm helped it to do innate classification of "gotta fix before release" vs. "fix soon after" vs. "fix when able" which maps pretty well to my personal taste in the severity of bugs it's found I've evaluated, so I've kept it).

Re: The cult of vibe coding is dogfooding run amok

#450
post #88

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…

i worked at companies in US

where uptime monitoring was Page Refresh by QA team.

where there was no centralized logs

postgres had no backup or replication or anything

Post reply on HN