Hacker News new | past | comments | ask | show | jobs | submit
deadbabe | on: Domain expertise has always been the real moat
You will never beat the vibe coders.

The vibe coders have a key advantage you don’t: they don’t give a fuck.

They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.

When shit breaks later on down the line, and fires have to be put out and things rewritten, the vibe coders do NOT get the blame. They do NOT get punished. Most engineering teams operate on a blameless culture. If code was approved for production, then it should have been good enough. Vibe coders will keep on doing what they do, and skilled experts will be left cleaning up their messes.

For anyone who actually cares, it’s over. You are not steering development anymore.

bg24 | parent | next
This will invariably be a problem in organizations where tokens, lines of code, PR count etc are the metrics - which happens to be in most places. I do not know if there are metrics or rewards for maintainable code, OR penalty for write code that breaks down and causes product incidents down the line. By then those engineers would have been promoted and moved on to better things.
wiseowise | parent | next
> You are not steering development anymore.

This hasn't been the case for at least a decade. Long before LLMs.

simonw | parent | next
That might be true in the short-term, but I'd be very surprised to see that hold for the long-term.

We've had plenty of technology trends in the past that have promised faster development but has later turned out to have problems. Organizations that stick around learn lessons about what works and what doesn't.

If in a year's time organizations aren't feeling severe downsides from all of the unreviewed vibe-coded junk they put into production then maybe the vibe-coders were right. I'll believe that when I see it.

toastmaster11 | root | parent | next
If the vibe coders are right I would give at least 90% of the credit to all the well made libraries, rules, and best practices that developers have built up over the decades. That’s what is embedded into LLMs and what might be the saving grace of slop code bases in the future.
locknitpicker | root | parent
> (...) rules, and best practices that developers have built up over the decades.

It seems you are not understanding that the reason all these "rules, best practices" had to be created in the first place was the fact that your average old times developer was churning out shit code and weaving spaghetti just as hard as today's vibecoders.

Those "rules, best practices" spawned from the same evolutionary pressure as today's instruction files, skills, custom agents, etc.

Why do you think one of the first AI features rolled out by GitHub was the automatic code reviewer?

You guys are talking as if everyone working on software before 2020 was this immaculate developer with pristine sense of architecture and style. No, they were not.

toastmaster11 | root | parent | next
All that stuff you mentioned is derived from a core set of principles established by decades of software best practices applied to a new means of generating code. Like quite literally those instruction files/skills essentially just reiterate the practices themselves.

To your last paragraph, I never say that nor do I imply it. I find that as a pretty disingenuous interpretation of what I said actually. The practices I mentioned were derived from hard learned lessons and designed as a means of mitigating the human tendency to write bad code.

deadbabe | root | parent
They were not, but they were outputting code at a pace that was reasonable to review. Now they go straight to prod, 10x faster.
deadbabe | root | parent
The problem is downsides are random and not well understood. Sometimes by luck, an organization might not encounter any significant downsides. These kind of survivor case studies will perpetuate the myth that vibe coding is good enough.

The vibe coders aren’t “right”, they just get lucky.

derwiki | parent | next
Who approved the vibe coders’ PRs?
wiseowise | root | parent | next
Another vibe coder and Claude?
deadbabe | root | parent
It’s all just vibe coders high fiving each other and saying LGTM.

Here’s a secret: I haven’t really bothered reviewing any PRs since September of last year or so. I just click approve and don’t even read it. It has been way less stressful for me.

Do bugs get through? Sure. But someone will just come in and vibe it out anyway. And I have yet to see a vibe coder or anyone who approved their flawed work get any repercussions. So yea, it doesn’t matter.

No one’s going to come after you asking “why did you approve this shitty PR?” And if they do you can forward it to the author and ask why they wrote a shitty PR. But that just doesn’t happen. It doesn’t matter.

locknitpicker | parent
> The vibe coders have a key advantage you don’t: they don’t give a fuck. They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.

This is a complete unrealistic assessment. Who do you think vibecoders are? They are yesterday's software developers using today's tools.

The people who manually write their PRs are also not giving a fuck when they break production code with spaghetti code that later has to be thrown out and rewritten. They are the same people.

The key difference is that now their output volume is much greater, and they iterate much faster. They roll out plenty of bullshit, but it also hits the fan much faster and triggers fixes at a higher rate.

People hate on vibecoders because they do exactly what your average developer does but at a much higher rate.