[Aurornis]

There’s some gate keeping, but many of us are also worried about the inevitable future where we have to take over someone else’s “vibe coding” mess of code.

The vibe coding style translates to trying a lot of different prompts and small adjustments until it looks like it works. In the past these people copied from StackOverflow and poked at lines until it compiled and appeared to work, but that only gets you so far. Now those same people can bang away at an LLM assistant all day long and produce volumes of code that appear to kind of work.

I’m in another forum dedicated to programming careers. Every day there’s a new thread from someone asking how to deal with all of their junior employees spamming code review with obvious LLM generated code that they don’t even understand.

A lot of the defenses of vibe coding rely on the assumption that it’s in the hands of someone knowledgeable who only wants to save a little time for something inconsequential. That’s fine. What’s worrying is that vibe coding is being used as a replacement for understanding code for many juniors and lazy seniors across the industry as long as they think they can get away with it.

[dingnuts]

> worried about the inevitable future where we have to take over someone else’s “vibe coding” mess of code.

worried? we're going to make a goddamned fortune

[Aurornis]

Doubtful. Usually when one person makes the proof of concept they do 20% of the work and collect 80% of the credit.

The people tasked with cleaning up the mess and making it usable in production do the remaining 80% of the work, but management is always disappointed that it’s going so slow relative to how quickly the proof of concept was created.

At one company it was widely known that the key to taking credit for technical work was to be the team presenting the GUI pieces to management. If you were working on something that couldn’t be shown to management with a “wow” factor, you were not valued. I see the same thing happening here, with vibe coders capturing the wow factor and the people who actually make it production stable being viewed as the slow and expendable ones.

[plorkyeran]

People who made the initial thing in the absolute cheapest way possible expect the maintenance work to be similarly cheap. If it turns out it just can't be done on that budget, it'll often just not get done rather than pay what it would cost.

[itishappy]

> ... many of us are also worried about the inevitable future where we have to take over someone else’s “vibe coding” mess of code.

Another potential alternative is that these things progress quickly and soon can code and review code at or above the level of most SWEs. I suspect that's driving a non-zero amount of anxiety in the comments.

I'm not an SWE, and frankly, they're above my level today. Saying "plz don't code if you can't understand it" applies to my code today without AI assistance. Are you suggesting I shouldn't release anything because others might need to read it? The way to prevent this within an organization is smart hiring practices, not restrictions on tool use.