Vibe coding cleanup as a service • Hacker News Board

Re: Vibe coding cleanup as a service

#121

Post by sseagull » Sun, Sep 21, 2025, 4:39 PM UTC

flir wrote: post #40

norskeld wrote: post #19

Janitor Engineers [0] are already a thing? Damn. Also, all links in this article starting from the "Why AI code fails at scale" section are dead for some reason, even though it was written only 5 days ago. That raises some questions... EDIT: Not trying to offend anyone with this [0], I've actually had the same half-joking retirement plan since the dawn of vibe coding, to become an "all-organic-code" consultant who un…

I think specialising in brownfield has always been a thing. If anything, it's greenfield that's the rarity.

I’ve always found the pioneer, settler, town planner model to be a great way of thinking about this. Successful, long-term projects or organizations eventually can use all 3 types.

Maybe vibe coding replaces some pioneering work, but that still leaves a lot for settlers to do.

(I admit I’m generally in the settler category)

https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...

Re: Vibe coding cleanup as a service

#122

Post by BinaryIgor » Sun, Sep 21, 2025, 4:43 PM UTC

bluefirebrand wrote: post #94

BinaryIgor wrote: post #26

Earlier quoted context omitted.

Interesting idea for some kind of blog post: * come up with requirements for a non-obvious system * try to vibe-code it * clean it up manually * add detailed description and comparisons of before and after; especially, was it faster or slower than just writing everything manually in the first place?

> was it faster or slower than just writing everything manually in the first place? My suspicion is that for any experienced dev this is slower every time It is only faster when the person doing the work probably could not have built the thing themselves in the first place

That's also my intuition, but I would like to test and measure it against a real and non-obvious system use case; some day I will and will write about it :)

Re: Vibe coding cleanup as a service

#123

Post by bdzr » Sun, Sep 21, 2025, 4:50 PM UTC

icyfox wrote: post #112

From the jump, even without the emdashes, it was crystal clear that this post was written by Claude. I'm sure the OP put their own ideas into the prompt, provided some sources, etc. But reading some of these phrases provoked a pretty visceral sense that I'm just reading an LLM's output: "The harsh reality" "he perfectly captured" "architectural decisions that make senior engineers weep" "fundamental issue" It makes m…

I've made heavy use of emdashes my whole life. It feels like I have to eliminate them now :(

Re: Vibe coding cleanup as a service

#124

Post by JKCalhoun » Sun, Sep 21, 2025, 4:56 PM UTC

bdzr wrote: post #123

icyfox wrote: post #112

From the jump, even without the emdashes, it was crystal clear that this post was written by Claude. I'm sure the OP put their own ideas into the prompt, provided some sources, etc. But reading some of these phrases provoked a pretty visceral sense that I'm just reading an LLM's output: "The harsh reality" "he perfectly captured" "architectural decisions that make senior engineers weep" "fundamental issue" It makes m…

I've made heavy use of emdashes my whole life. It feels like I have to eliminate them now :(

Fight it — otherwise the terrorists win.

Re: Vibe coding cleanup as a service

#125

Post by mattgreenrocks » Sun, Sep 21, 2025, 5:02 PM UTC

HarHarVeryFunny wrote: post #101

It's a bit strange that Karpathy's "vibe coding" ever gained traction as a concept, although perhaps only among those without enough experience to know better. As I understand it, what Karpathy was referring to as "vibe coding" was some sort of flow state "just talk to the AI, never look back" thing. Don't look at the generated code, just feel the AGI vibes ... It sounds absolutely horrific if you care even the tinie…

> It's a bit strange that Karpathy's "vibe coding" ever gained traction as a concept

This point in history is not characterized by any real sort of seriousness about...anything, really.

Alternatively, it is the same sort of pleasant fiction that is being fed to CEOs about their workforce being able to be replaced Real Soon.

Re: Vibe coding cleanup as a service

#126

Post by HarHarVeryFunny » Sun, Sep 21, 2025, 5:04 PM UTC

jstummbillig wrote: post #107

Lu2025 wrote: post #86

Earlier quoted context omitted.

It's worse. With plumbing, at least you can see what you are doing. Vibe code? One day, it just breaks and you don't know why.

Unless, of course, there is a better AI at a future point, which is able to easily spot and correct the more underlying problems.

Sure but in the software field a few years is a lifetime.

It's taken 8 years to go from introduction of the Transformer (attention paper) to today's LLMs, so I wouldn't be holding your breath waiting for something significantly different or more capable to replace it. It may well take AGI to replace a human "vibe coded mess" fixer-upper.

The technical debt you're building up by vibe coding your product may well become a boat anchor well before some product you are fantasizing about materializes to bail you out.

If you've somehow vibe coded an MVP good enough to push out to customers, and achieved some degree of success with it, then what you need to keep going is momentum - to be responsive to customer feedback, add new features, etc. If you've built such a poorly designed and flaky MVP that you can't rapidly iterate on it, then that is probably not going to go well.

Re: Vibe coding cleanup as a service

#127

Post by andy99 » Sun, Sep 21, 2025, 5:06 PM UTC

HarHarVeryFunny wrote: post #101

It's a bit strange that Karpathy's "vibe coding" ever gained traction as a concept, although perhaps only among those without enough experience to know better. As I understand it, what Karpathy was referring to as "vibe coding" was some sort of flow state "just talk to the AI, never look back" thing. Don't look at the generated code, just feel the AGI vibes ... It sounds absolutely horrific if you care even the tinie…

I still maintain that the original tweet about it was a joke, or at least not a suggestion for doing real work but just a reflection on the freedom of yolo mode coding. It wasn't meant to be instructions.

Re: Vibe coding cleanup as a service

#128

Post by bethekidyouwant » Sun, Sep 21, 2025, 5:14 PM UTC

jplusequalt wrote: post #97

baq wrote: post #48

Earlier quoted context omitted.

The real skill is guiding generation carefully so the generated software isn’t crap. Some people here see Claude code and think it’s state of the art, whereas for best results you need a much more involved process. It isn’t that different from any other form of engineering, really. Minimize cost, fulfill requirements; smarts-deficient folks won’t put maintainability in their spec and will get exactly what they asked…

Let me know when aerospace engineers are letting an AI build their planes for them.

https://uwaterloo.ca/news/math-innovation/pioneering-future-...

Re: Vibe coding cleanup as a service

#129

Post by junon » Sun, Sep 21, 2025, 5:15 PM UTC

bdzr wrote: post #123

icyfox wrote: post #112

From the jump, even without the emdashes, it was crystal clear that this post was written by Claude. I'm sure the OP put their own ideas into the prompt, provided some sources, etc. But reading some of these phrases provoked a pretty visceral sense that I'm just reading an LLM's output: "The harsh reality" "he perfectly captured" "architectural decisions that make senior engineers weep" "fundamental issue" It makes m…

I've made heavy use of emdashes my whole life. It feels like I have to eliminate them now :(

Surround them with spaces. LLMs don't do that.

Re: Vibe coding cleanup as a service

#130

Post by HarHarVeryFunny » Sun, Sep 21, 2025, 5:15 PM UTC

sltr wrote: post #12

Vibe code has a lot in common with legacy code. Low confidence to change it, low internal and external quality. Also some differences: low age-to-quantity ratio, schedule pressure, inflated expectations. It's most cost-effective to shift errors from runtime to compile time and from compile time to design time. Unfortunately, AI rushes people to runtime as fast as possible.

Legacy code isn't necessarily bad - it may just be complex, or poorly documented, having accumulated a lot of production fixes over the years that were never properly documented (if if the original project was - typically not).

Your legacy code products may be happily running without problems, due to all those production issues (incl. new requirements) that were identified and fixed over the years, with the problem only coming when there is a need to change it, especially when there is no-one left familiar with the codebase, maybe not even with the language/tools used to build it.