Live data from Hacker News

Will vibe coding end like the maker movement?

read.technically.dev

441–450 of 459 posts

Re: Will vibe coding end like the maker movement?

#442
post #440

Earlier quoted context omitted.

Oh man, I have that exact same CD player! That project is great, well done.

Thanks, just browsed to your blog, I did some board designs a few years back for another guy with a horticulture business, that little ESP clock project you just did would have been ideal back then. Amazing the tech you can get for a few dollars these days.

Seriously, it's a great time to be a hacker.

Re: Will vibe coding end like the maker movement?

#443

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…

> Right now, my company identified an expensive software platform that was set to cost us around $250k/year. A single engineer assigned to maintain your in-house solution will cost more than this.

That's assuming you won't need anyone to manage the purchased software platform and its integrations and that you need a full time engineer to maintain your version.

Re: Will vibe coding end like the maker movement?

#444
post #253

Earlier quoted context omitted.

> Looks at the scores of Ycombinator startups that wrote a shitload of awful code and failed. This can also be restated as, look at all the startups that wrote a shitload of awful code and succeeded. That’s an indicator code quality doesn’t matter at macro scales. We already knew this though even if we didn’t explicitly say it. It’s more about organization, coordination, and execution than code.

This seems like it's reading too much into things. I'm sure driving an ambulance slower vs faster doesn't make a difference to survival in most cases, but on the margins it absolutely does. Startups are also quite different from ambulances; surviving and minimising patient harm isn't the most important thing for a startup. Instead, it's building a profitable and valuable business. You're not just worrying about the m…

My statement applies equally to startups and nasdaq 100 enterprises alike.

I’m not following this ambulance analogy.

Re: Will vibe coding end like the maker movement?

#445

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

For sure. Have you tried to use AI to build the models themselves yet? I'm curious if it can build mechanical systems well.

Re: Will vibe coding end like the maker movement?

#446

Earlier quoted context omitted.

> adversarial AI reviewers, runtime tests (also by AI), or something else? And spec management, change previews, feedback capture at runtime, skill libraries, project scaffolding, task scoping analysis, etc. Right now this stuff is all rudimentary, DIY, or non-existent. As the more effective ways to use LLMs becomes clearer I expect we'll see far more polished, tightly-integrated tooling built to use LLMs in those wa…

Agents require tests to keep from spinning out of control when writing more than a few thousand lines, but we know that tests are wildly insufficient to describe the state of the actual code. You are essentially saying that we should develop other methods of capturing the state of the program to prevent unintended changes. However there’s no reason to believe that these other systems will be any easier to reason abou…

> Agents require tests to keep from spinning out of control when writing more than a few thousand lines, but we know that tests are wildly insufficient to describe the state of the actual code.

Provide them with a mature, well-structured codebase to work within. Break the work down into tasks sized such that it's unlikely they'll spin out of control. Limit the scope/nature of changes such that they're changing one thing at a time rather than trying to one-shot huge programs. Use static analysis to identify affected user-facing flows and flag for human review. Provide the human-in-the-loop with fully functional before and after dev builds. Allow the human-in-the-loop to provide direct feedback within the dev build. Track the feedback the same way you track other changes. And, yes, have some automated tests that ensure core functionality matches requirements.

I think everything I've listed there can be built with existing technology.

> You are essentially saying that we should develop other methods of capturing the state of the program to prevent unintended changes.

I think you're imagining something far more sophisticated than what I'm actually suggesting. I also think you're setting a higher bar for agents to clear than what's actually required in practice.

Tests don't need to catch every issue, agents should be expected to make some mistakes (as humans do).

> However there’s no reason to believe that these other systems will be any easier to reason about than the code itself. If we had these other methods of ensuring that observerable behavior doesn’t change and they were substantially easier than reasoning about the code directly, they would be very useful for human developers as well.

There are lots of powerful static analysis tools out there than can be helpful in improving correctness and reducing the incidence of regressions. IME most human developers tend to eschew tools that are unfamiliar, have steep learning curves, or require extra effort when writing code.

> The fact that we’ve not developed something like this in 75 years of writing programs, says it’s probably not as easy as you’re making it out.

I think the cost/benefit of what I'm describing has changed. We've only had LLMs capable of reliably producing working code changes for around a year.

Re: Will vibe coding end like the maker movement?

#447
post #426

Earlier quoted context omitted.

Even in CRUD line of business software, lack of performance causes enormous problems that the current software development culture glosses over. Just one example I've seen time and again. You take an application that if optimized could run on a single server (maybe 2 if you absolutely have to have zero downtime deployments), but because no one cares about performance it runs on 10 or more. You now have a complexity a…

Agreed. I wanted to give some credence to the fact many cookie-cutter CRUD apps can absorb a ton of inefficiencies until they truly burst at the seams, but yeah, even in that case software bloat and bad use of resources matters. I find it intriguing seeing this new batch of dev-types completely giving up on the matter. The conversation of machine vs developer efficiency is not new, but completely giving up on any san…

I've been in industry for >15 years and have given up on sane use of resources because it's been actively disincentivised everywhere I've worked.

Sanity is for my personal projects.

Re: Will vibe coding end like the maker movement?

#448
post #407

Earlier quoted context omitted.

Don't worry, LLMs are perfectly ok for getting information. Just ask drugs.com about penisomab https://bsky.app/profile/harrisonk.bsky.social/post/3mfs6adw...

Again: not doing anything at all with health or chemistry. They aren't what I am interested in, even peripherally. What you seem to be missing is that LLMs are better at/for some things than others. Legal review, 3D geometry, therapy and apparently chemistry are off the list. It doesn't make sense to project that onto domains where it excels.

> What you seem to be missing is that LLMs are better at/for some things than others.

I guarantee it is using the same system to write code and teach you about electronics that it is using to teach people about chemistry, and if you can't see how that means the resulting information is suspicious at best, then I don't even know what to say anymore.

Re: Will vibe coding end like the maker movement?

#450
post #406

Earlier quoted context omitted.

If the point is to make a plastic switch cover, why is it important that the person CADs it themselves, rather than hitting print of a model they found online? Does it fail some sort of piety test that the end result that comes out the other end is a functional piece of plastic in a specific shape?

Because 90% of the time you won't find the one you need pre-designed.

You just made that number up. The Internet is really big and there are many people on it. I could just as easily claim that you'll find something close enough 99% of the time.
Post reply on HN