Live data from Hacker News

The cult of vibe coding is dogfooding run amok

bramcohen.com

501–510 of 555 posts

Re: The cult of vibe coding is dogfooding run amok

#501
post #387

Earlier quoted context omitted.

I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily. I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like a…

Exactly. I thought AI was going to be smarter. I thought AI would give us expert coders. Instead we have idiot savants.

[dead]

Re: The cult of vibe coding is dogfooding run amok

#502

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 don't think it's bad code that's necessarily the problem - it's bad architecture and systems which will bite you! Often bad code can be easily replaced if it's easy to refactor.

Of course, bad business can ruin it all. I wrote a beautiful and reliable distributed rust agent, but was later laid off due to the company doing poorly.

Re: The cult of vibe coding is dogfooding run amok

#503

Earlier quoted context omitted.

This is not just true of code; it is true of everything - the whole world is held together with spit, bailing wire, a prayer, and some old dude who remembers.

It doesn't mean it's something to strive for

Totally agree; we've created a system that goes so far beyond technical debt we're going to have to call it technical usury, and we're piling it up at rapid rates.

Given that most code gets thrown away, perhaps it won't matter much.

Perhaps

Re: The cult of vibe coding is dogfooding run amok

#505

Earlier quoted context omitted.

Down the road AI is smarter than all of us. Today (including one time literally today), my experience is that it’s occasionally helpful at cleaning up its own mess but often tries to change behavior in a way that’s unacceptable for a production project.

> often tries to change behavior yes, and (in my experience) at the same time re-write the unit tests that are supposed to guarantee behavior doesn't change...

[flagged]

Re: The cult of vibe coding is dogfooding run amok

#506
post #288

Earlier quoted context omitted.

> I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important. The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.

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.

  > 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.
Your prompt may work on the specific state of code base and not before or after some changes. Your tests can check for the specific behavior but not for the absence of undesirable behaviors induced by absence of some specific code or by addition of other specific code.

  > I assure you that's already happening. A lot.
Thank you for assurance. Can we have less of it? Thank you again.

Re: The cult of vibe coding is dogfooding run amok

#507

Earlier quoted context omitted.

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 we…

  > 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.
This is very much like good old djinn [1], which would generate code from Haskell type specification.

[1] https://mail.haskell.org/pipermail/haskell/2005-December/017...

And this is why I boldly compare current LLM craze to the much less hyped craze of strong type systems. I was a part of that strong type system discussion, advocating for them. ;)

Re: The cult of vibe coding is dogfooding run amok

#508
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…

> I suspect if people saw the handwritten code Somehow, everyone has forgotten the terrible code quality that existed prior to 2020. https://www.youtube.com/watch?v=UjZQGRATlwA Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.

  > AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.
Most probably, you are not looking into that well enough.

Average duration for AWS outages [2] was 1.5 hours per outage, 38 hours total. Most recent AWS outage in 2026 [1] downed AWS for 13 hours, a third of 38 hours spanning an year before, and was caused by AWS LLM coding tool.

[1] https://www.theguardian.com/technology/2026/feb/20/amazon-cl...

[2] https://www.cherryservers.com/blog/cloud-outages

Re: The cult of vibe coding is dogfooding run amok

#509
post #369

Earlier quoted context omitted.

If you make a working and functional bad code, and put it on maintenance mode, it can keep churning for decades with no major issues. Everything depends on context. Most code written by humans is indeed, garbage.

> Most code written by humans is indeed, garbage. I think that this is the problem, actually. It's similar to writing. Most people suck at writing so badly that the LLM/AI writing is almost always better when writing is "output". Code is similar. Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). Remember, a huge number of programmers couldn't pass FizzBuzz. So,…

  >  Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+).
How do you know?

Re: The cult of vibe coding is dogfooding run amok

#510
post #275

Earlier quoted context omitted.

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…

> Bad code works fine until it doesn't. Who is to judge the "good" or "bad" anyway?

It is important to question "how to judge," not "who is to judge."

My answer of "how to judge?" question is the question "how easy is it to implement new unforeseen functionality with the code under scrutiny?"

Post reply on HN