Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 100 hour gap between a vibecoded prototype and a working product

kanfa.macbudkowski.com

Post reply on HN
Print view View original

91–100 of 362 posts

Re: The 100 hour gap between a vibecoded prototype and a working product

#91

Post by program_whiz »

user34283 wrote: post #36
IAmGraydon wrote: post #26

Earlier quoted context omitted.

This is a pipe dream and “sufficiently advanced” is doing a lot of heavy lifting. You really think people would rather spin up and debug their own self-made software rather than pay for something that has been tested, debugged, and proven by thousands of users? Why would anyone do that for anything more than a very simple script? It makes zero sense unless the LLM outputs literally perfect one-shot software reliably.

It makes sense if you want bespoke software to do a specific job in a way best suited to your workflow. Could you do the same in eg. Photoshop? Maybe, but even if, you would need to learn how.

Photoshop is a good example -- not that I agree with everything in the app, but just to design all the interactions properly in photoshop would take hundreds of hours (not to mention testing and figuring out the edges). If your goal is a 1-to-1 clone why not use Krita or photoshop? With LLM you'll get "mostly there" with many many hours of work, and lots of sharp edges. If all you need is paint bucket, basic brush / pencil, and save/load, ok maybe you can one-shot it in a few hours... or just use paint / aesprite...

Re: The 100 hour gap between a vibecoded prototype and a working product

#92

Post by riffraff »

mtrovo wrote: post #56
matt_heimer wrote: post #45

Earlier quoted context omitted.

I'm building a Java HFT engine and the amount of things AI gets wrong is eye opening. If I didn't benchmark everything I'd end up with much less optimized solution. Examples: AI really wants to use Project Panama (FFM) and while that can be significantly faster than traditional OO approaches it is almost never the best. And I'm not taking about using deprecated Unsafe calls, I'm talking about using primative arrays b…

I think the main issue is treating LLM as a unrestrained black box, there's a reason nobody outside tech trust so blindly on LLMs. The only way to make LLMs useful for now is to restrain their hallucinations as much as possible with evals, and these evals need to be very clear about what are the goal you're optimizing for. See karpathy's work on the autoresearch agent and how it carry experiments, it might be useful…

> there's a reason nobody outside tech trust so blindly on LLMs.

Man, I wish this was true. I know a bunch of non tech people who just trusts random shit that chatgpt made up.

I had an architect tell me "ask chatgpt" when I asked her the difference between two industrial standard measures :)

We had politicians share LLM crap, researchers doing papers with hallucinated citations..

It's not just tech people.

Re: The 100 hour gap between a vibecoded prototype and a working product

#93

Post by iamcalledrob »

nemo44x wrote: post #3

The 80/20 rule doesn’t go away. I am an AI true believer and I appreciate how fast we can get from nothing to 80% but the last “20%” still takes 80%+ of the time. The old rules still apply mainly.

In my experience, the last 20% tends to be the stuff that's less obvious, too, by it's very nature.

The details and pitfalls that are unique to your specific scenario, that you only discover by running into them.

And yet this less obvious, more uncommon stuff is also what AI will be weakest at.

Re: The 100 hour gap between a vibecoded prototype and a working product

#94

Post by i_love_retros »

> With AI, it’s easier to get the first 90 percent out there. This means we can spend more time on the remaining 10 percent, which means more time for craftsmanship and figuring out how to make your users happy.

EXCEPT... you've just vibe coded the first 90 percent of the product, so completing the remaining 10 percent will take WAY longer than normal because the developers have to work with spaghetti mess.

And right there this guy has shown exactly how little people who are not software developers with experience understand about building software.

Re: The 100 hour gap between a vibecoded prototype and a working product

#95

Post by mentalgear »

> The "remaining 10 percent" is a difference between slop and something people enjoy.

I would say the remaining 10% are about how robust your solution is - anything associated with 'vibe' feels inherently unsecure. If you can objectively proof it is not, that's 10 % time well spend.

Re: The 100 hour gap between a vibecoded prototype and a working product

#96

Post by jacquesm »

grim_io wrote: post #73
matt_heimer wrote: post #45

Earlier quoted context omitted.

I'm building a Java HFT engine and the amount of things AI gets wrong is eye opening. If I didn't benchmark everything I'd end up with much less optimized solution. Examples: AI really wants to use Project Panama (FFM) and while that can be significantly faster than traditional OO approaches it is almost never the best. And I'm not taking about using deprecated Unsafe calls, I'm talking about using primative arrays b…

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

Not necessarily. Java can be insanely performant, far more than I ever gave it credit for in the first decade of its existence. There has been a ton of optimization and you can now saturate your links even if you do fairly heavy processing. I'm still not a fan of the language but performance issues seem to be 'mostly solved'.

Re: The 100 hour gap between a vibecoded prototype and a working product

#97

Post by WarmWash »

jcgrillo wrote: post #68
CuriouslyC wrote: post #54

Earlier quoted context omitted.

Github is on the chopping block as a tool (it's sticky as a social network). The other stuff not so much. The things that are going away are tools that provide convenience on top of a workflow that's commoditized. Anything where the commercial offering provides convenience rather than capabilities over the open source offerings is gonna get toasted.

Even at recent levels of uptime I think it would be very difficult to build a competing product that could function at the scale of even a small company (10 engineers). How would you implement Actions? Code review comments/history? Pull requests? Issues? Permalinks? All of these things have serious operational requirements. If you just want some place to store a git repository any filesystem you like will do it but w…

The future is narrow bespoke apps custom tailored for exactly that one single users use case.

An example would be if the user only ever works with .jpg files, then you don't need to support any of the dozens of other formats an image program would support.

I cannot stress enough how many software users out there are only using 1-10% of a program's capability, yet they have to pay for a team of devs who maintain 100% of it.

Re: The 100 hour gap between a vibecoded prototype and a working product

#98

Post by Aurornis »

alexpotato wrote: post #10

I work as a DevOps/SRE and have been doing it FinTech (bank, hedge funds, startups) and Crypto (L1 chain) for almost 20 years. My thoughts on vibe coding vs production code: - vibe coding can 100% get you to a PoC/MVP probably 10x faster than pre LLMs - This is partly b/c it is good at things I'm not good at (e.g. front end design) - But then I need to go in and double check performance, correctness, information flow…

There’s a big gap between reality and the influencer posts about LLMs. I agree with you that LLMs do provide some significant acceleration, but the influencers have tried to exaggerate this into unbelievable numbers.

Even non-influencers are trying to exaggerate their LLM skills as a way to get hired or raise their status on LinkedIn. I rarely read the LinkedIn social feed but when I check mine it’s now filled with claims from people about going from idea to shipped product in N days (with a note at the bottom that they’re looking for a new job or available to consult with your company). Many of these posts come from people who were all in on crypto companies a few years ago.

The world really is changing but there’s a wave of influencers and trend followers trying to stake out their claims as leaders on this new frontier. They should be ignored if you want any realistic information.

I also think these exaggerated posts are causing a lot of people to miss out on the real progress that is happening. They see these obviously false exaggerations and think the opposite must be true, that LLMs don’t provide any benefit at all. This is creating a counter-wave of LLM deniers who think it’s just a fad that will be going away shortly. They’re diminishing in numbers but every LLM thread on HN attracts a few people who want to believe it’s all just temporary and we’re going back to the old ways in a couple years.

Re: The 100 hour gap between a vibecoded prototype and a working product

#99

Post by baxtr »

alexpotato wrote: post #10

I work as a DevOps/SRE and have been doing it FinTech (bank, hedge funds, startups) and Crypto (L1 chain) for almost 20 years. My thoughts on vibe coding vs production code: - vibe coding can 100% get you to a PoC/MVP probably 10x faster than pre LLMs - This is partly b/c it is good at things I'm not good at (e.g. front end design) - But then I need to go in and double check performance, correctness, information flow…

Isn’t that the reason why people advocate for spec-driven development instead of vibe coding?

Re: The 100 hour gap between a vibecoded prototype and a working product

#100

Post by bojangleslover »

alexpotato wrote: post #10

I work as a DevOps/SRE and have been doing it FinTech (bank, hedge funds, startups) and Crypto (L1 chain) for almost 20 years. My thoughts on vibe coding vs production code: - vibe coding can 100% get you to a PoC/MVP probably 10x faster than pre LLMs - This is partly b/c it is good at things I'm not good at (e.g. front end design) - But then I need to go in and double check performance, correctness, information flow…

What I do now is I make an MVP with the AI, get it working. And then tear it all down and start over again, but go a little slower. Maybe tear down again and then go even more slowly. Until I get to the point where I'm looking at everything the AI does and every line of code goes through me.
Post reply on HN