Live data from Hacker News

Will vibe coding end like the maker movement?

read.technically.dev

341–350 of 459 posts

Re: Will vibe coding end like the maker movement?

#341
post #136

Earlier quoted context omitted.

> The higher paid engineers i've worked with are always worth their salary/hourly rate because of the way they approach problems and the solutions they come up with. I'm honestly just happy at the moment, because our two junior admins/platform engineers have made some really good points to me in preparation for their annual reviews. One now completed his own bigger terraform project, with the great praise of "That lo…

It makes sense for junior admins and junior platform engineers to leverage LLM's but I'd be highly skeptical for the future skillset of any junior software engineer who leverages LLM's right off the bat, unless we have already moved that goalpost.

Depends how they use them as arguably was the case with stack overflow or other resources in the past. E.g. an LLM can be a valid and useful way to start discovering or understanding code and architecture. You can ask for a summary , distill important concepts and then read in more detail about them.

Re: Will vibe coding end like the maker movement?

#342

I agree the central promise of 3D printers was they would get cheaper, better, and more like industrial grade and we would end up with this thing that could build replacement parts for anything in our home. Instead what we were left with was an endless hunt for 'models', and no companies publishing their specs. Everything had to be done custom, and at best some niche manufacturing for weird side quests like adds ons…

I've had plenty of use for mine, but I wish I had a library of mechanisms that work well that I could put together to build easily.

Learning modelling is a huge time sink, learning to make threaded parts, or anything modular to not have to re-print everything for changes. It's great but the printing is the easy part

Re: Will vibe coding end like the maker movement?

#343
post #64

> The central promise—that distributed digital fabrication would bring manufacturing back to America, that every city would have micro-factories, that 3D printing would decentralize production—simply didn’t materialize. I never heard that. It didn’t seem like 3D-printing ever showed sings of displacing existing ways of manufacturing at scale, did it? Units per hour and dollars per unit was never its strength. It was…

The great thing about vibecoding is we're at the point where people like me have to come in to fix core problems for apps and platforms that non-domain experts are outputting as slop.

Those problems span from fundamental architecture flaws, to issues anyone who spent 5 minutes reading the docs would never do, like create an entire app that slows to a crawl when more than one user uses it, because all parallel work gets serialized due to a complete misunderstanding of how concurrency, async/await and threads work in the language they're "writing".

People with too much money build entire apps on foundations that crumble and significantly hold them back from doing simple things, and I love it.

Re: Will vibe coding end like the maker movement?

#344

Earlier quoted context omitted.

I think it's really dependent on the software. And frankly, with the current rate of development, I feel like this continues to shift. No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code. But as a generalist - I'm absolutely able to ship software and tools that solve ou…

> No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But…

> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But your customer doesn't see your code, they don't see how many servers you need or how often an on-call engineer is woken up. They just see how well the app meets their needs

Your customers definitely see the quality of code, just by proxy. When features take forever to ship, and things fall over all the time, those are code quality and design problems.

Honestly, code quality is somewhat more important right now, because use common and clear patterns will help AI make better changes, and using a more resilient architecture will you hand more off without worry things will fall over.

Re: Will vibe coding end like the maker movement?

#345
I totally get the point of the article but the analogy isn’t a good one. It’s got the vibe that it’s written by someone who hasn’t been following the 3D printing/maker scene in a long time, which is more popular than ever.

I realize that the wildest promises of 3D printing and maker stuff like Arduono never came to fruition, but maker spaces have matured greatly. If that is the analogy we are making, that means that vibecoding won’t reach “the masses” necessarily but it will be popular beyond the present audience.

Re: Will vibe coding end like the maker movement?

#346
post #64

> The central promise—that distributed digital fabrication would bring manufacturing back to America, that every city would have micro-factories, that 3D printing would decentralize production—simply didn’t materialize. I never heard that. It didn’t seem like 3D-printing ever showed sings of displacing existing ways of manufacturing at scale, did it? Units per hour and dollars per unit was never its strength. It was…

Maybe its replacing the simplistic forms of backend web development and the keast capable frontend devs. If your job was building with DaisyUI/Tailwind you're prob replaceable by this tech. People building their first SaaS are amazed (its literally heroin for non technical idea guys). But serious engineers I know, old heads, don't seem to be that impressed and neither am I.

I don't see it competing with anyone doing anything serious, outside of ML engineers and lets be honest, they always sucked at writing code, hated writing code so its not surprising how much they sing it's praise.

Re: Will vibe coding end like the maker movement?

#347

Earlier quoted context omitted.

I think it's really dependent on the software. And frankly, with the current rate of development, I feel like this continues to shift. No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code. But as a generalist - I'm absolutely able to ship software and tools that solve ou…

> No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But…

> I predict we will see a lot of domain experts without engineering background spin up incredibly successful apps. Just like the Tea app many of them will crash and burn from poor engineering.

This rollercoaster is going to be wild to ride over the next decade. I've done a few experiments where I've intentionally "vibe coded" either a few features for an existing project of mine or for a few completely clean-sheet ideas.

I completely agree with you. There are going to be a lot of domain experts who do successfully spin stuff up.

> But there will also be enough people who've grown wise to this and after reaching some success with their app spend the resources to have others mitigate all the unknown-to-them issues

Here's the part that shocked me when I tried this... it did not take long for the no-engineering-guidance codebases to turn into complete disasters. Like... in an afternoon I had a pretty functional application that filled a gap for me. It was also... I don't think it'd remain even remotely maintainable for more than a week based on the direction it was going.

We live in interesting times.

Re: Will vibe coding end like the maker movement?

#348

I've got to be honest: my complete skepticism that the maker movement is somehow past tense makes it extremely difficult for me to take this tenuous comparison to LLM coding particularly seriously. The author talks about lowered barriers to prototyping as though they represent a failure state; that's absurd, and it has absolutely nothing to do with whether most people have membership-based maker spaces nearby. Meanwh…

> It's now possible for people to buy affordable CNCs, laser cutters and UV printers.

And for the most part they just aren't

Re: Will vibe coding end like the maker movement?

#349
post #148

Earlier quoted context omitted.

It's not awesome, not for us. 30% productivity gain would be enormous. Just imagine 30% of developers losing their jobs, in addition to outsourcing and all the new graduates flooding out of colleges after CS has been hyped so much in the recent years.

I really doubt that 30% productivity gain would result in 30% developers losing their jobs. Believing this would require an assumption that businesses and economies will never grow.

It also doesn't mathematically make any sense. If you now have 130% developer capacity, then the percentage of developers you need to keep is `x` defined by 130%*x = 100%, x ≈ 76.9% implying you'd lay off about 23.1% of developers.

Percentage increases are not the same as percentage losses.

Re: Will vibe coding end like the maker movement?

#350

Earlier quoted context omitted.

The problem you describe is real, but I think it can be addressed by improving tooling without any improvement in available LLM technology.

How? Are you thinking of adversarial AI reviewers, runtime tests (also by AI), or something else? Guess I just don't see how you can take the human out of the loop and replace them with non-deterministic AIs and informal prompts / specs.

Humans are also non-deterministic, though. Why does replacing one non-deterministic actor with another matter here?

I'm not particularly swayed by arguments of consciousness, whether AI is currently capable of "thinking", etc. Those may matter right now... but how long will they continue to matter for the vast majority of use cases?

Generally speaking, my feeling is that most code doesn't need to be carefully-crafted. We have error budgets for a reason, and AI is just shifting how we allocate them. It's only in certain roles where small mistakes can end your company - think hedge funds, aerospace, etc. - where there's safety in the non-determinism argument. And I say this as someone who is not in one of those roles. I don't think my job is safe for more than a couple of years at this point.

Post reply on HN