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

121–130 of 362 posts

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

#121

Post by ryandrake »

jcgrillo wrote: post #107
WarmWash wrote: post #97

Earlier quoted context omitted.

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%…

"The future" is fiction. It's a blank canvas where you can make a fingerpainting of any fantasy you like. Whenever people tell me about "the future" I know they're talking absolute rubbish. And I also like your fantasy! But it probably won't happen.

I call it "Psychics for Programmers." People will scoff at psychics and fortune telling and palm reading, but then the same people will listen to Elon or some founder or VC and be utterly convinced that that person is a visionary and can describe the future.

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

#122

Post by zahlman »

qsera wrote: post #108
WarmWash wrote: post #74

Earlier quoted context omitted.

I don't think people are grasping yet that this is the future of software, if by no metric other than "most software used is created by the user".

>most software used is created by the user You really believe that?

That wasn't being claimed, just proposed as the direction we're headed.

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

#123

Post by spacecadet »

Im an 20 year veteran of application development consulting. Contributor level... not talking head. I do more estimating than anyone you likely know. Consulting is cooked. I just AI native built (not vibe coding...) an application with a buddy, another Principal level engineer and what would cost a client 500-750k and 8-12 weeks, we did for $200 and 1 sprint. Its a passion project but highly complex mapping and navigation app with host/client multi-user sync'd state. Cooked.

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

#124

Post by quater321 »

It already starts with BS. Yes there are apps you can build in 30 minutes and they are great, not buggy or crap as he says it. And there are apps you need 1 hour or even weeks. It depends on what you want to build. To start off by saying that every app build in 30 minutes is crap, simply shows that he did not want to think about it, is ignorant or he simply wanted to push himselve higher up by putting others down. At this point, every programmer who claims that vibecoding doesn't make you at least 10 times more productive is simply lying or worst, doesn't know how to vibe code.

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

#125

Post by qsera »

lelanthran wrote: post #109
hebrides wrote: post #58

I’ve had a similar experience. I’ve been vibecoding a personal kanban app for myself. Claude practically one-shotted 90% of the core functionality (create boards, lanes, cards, etc.) in a single session. But after that I’ve now spent close to 30 hours planning and iterating on the remaining features and UI/UX tweaks to make the app actually work for me, and still, it doesn’t feel "ready" yet. That’s not to say it has…

I've got a few projects I've generated, along with a wholly handwritten project started in Dec. The difference I've noticed is that the act of actually typing out code made me backtrack a few times refining the possible solutions before even starting the integration tests, sometimes before even doing a compile. When generating, the LLM never backtracked, even in the face of broken tests. It would proceed to continue…

> It would add special exceptions to general code instead of determining that the general rule should be refined or changed.

That is pretty bad..

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

#126

Post by marcosdumay »

WarmWash wrote: post #74
sieste wrote: post #43

Earlier quoted context omitted.

Related anecdote: My 12yo son didn't like the speed cubing online timer he was using because it kept crashing the browser and interrupted him with ads. Instead of googling a better alternative we sat down with claude code and put together the version of the website that behaved and looked exactly as he wanted. He got it working all by himself in under an hour with less than 10 prompts, I only helped a bit putting it…

I don't think people are grasping yet that this is the future of software, if by no metric other than "most software used is created by the user".

So... The future is like the past?

That would be good news, but I doubt most people will do things like that.

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

#127

Post by quater321 »

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…

At this point, every programmer who claims that vibecoding doesn't make you at least 10 times more productive is simply lying or worst, doesn't know how to vibe code. -So, you want to tell me that you don't review the code you write? Or that others don't review it? - You bring up ONE example with a bottleneck that has nothing to do with programming. Again, if you claim it doesn't make you 10x more productive, you don't know how to use AI, it is that simple. - I pin up 10 agents, while 5 are working on apps, 5 do reviews and testing, I am at the end of that workflow and review the code WHILE the 10 agents keep working.

For me it is far more than 10x, but I consider noobs by saying 10x instead of 20x or more.

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

#128

Post by qsera »

spacecadet wrote: post #123

Im an 20 year veteran of application development consulting. Contributor level... not talking head. I do more estimating than anyone you likely know. Consulting is cooked. I just AI native built (not vibe coding...) an application with a buddy, another Principal level engineer and what would cost a client 500-750k and 8-12 weeks, we did for $200 and 1 sprint. Its a passion project but highly complex mapping and navig…

>highly complex mapping

Curious. Can you elaborate on this a bit?

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

#129

Post by geetee »

quater321 wrote: post #127
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…

At this point, every programmer who claims that vibecoding doesn't make you at least 10 times more productive is simply lying or worst, doesn't know how to vibe code. -So, you want to tell me that you don't review the code you write? Or that others don't review it? - You bring up ONE example with a bottleneck that has nothing to do with programming. Again, if you claim it doesn't make you 10x more productive, you don…

I can't tell if this is real or a joke.

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

#130

Post by AstroBen »

phillipclapham wrote: post #85

[flagged]

I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.
Post reply on HN