Live data from Hacker News

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

kanfa.macbudkowski.com

331–340 of 362 posts

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

#331

Earlier quoted context omitted.

You seem to be making the assumption that "app" means "sellable product", rather than "one off that works for me". It doesn't. When everyone is able to make their own one off prototype in 30 minutes, no one will pay for the thing that took someone 6 months.

whatever you prototype - the one who built it in 6 month will have economy of scale to make it cheaper than your diy solution, and because they serve many customers and developed it for 6 months - their product will be 100x better than the one you diy there is very very rare use case when diy makes sense. in 99% of cases its just a toy that feels nice as you kinda did it. but if you factor in the time etc it is alway…

With that logic LEGO sets and Salesforce subscriptions should be virtually free due to their economy of scale

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

#332

Earlier quoted context omitted.

I haven't had that at all, not even a single time. What I have had is endless round trips with me saying 'no, that can't work' and the bot then turning around and explaining to me why it is obvious that it can't work... that's quite annoying.

Try something like: > Please carefully review (whatever it is) and list out the parts that have the most risk and uncertainty. Also, for each major claim or assumption can you list a few questions that come to mind? Rank those questions and ambiguities as: minor, moderate, or critical. > Afterwards, review the (plan / design / document / implementation) again thoroughly under this new light and present your analysis…

Eh… I am not sure if that translate to “I don’t know”.

IDK would require the LLM to be aware of the frequency of cases seen in its own training.

I can see this working as a risk ranking, which is certainly worth trying in its own right.

Does it actually say “I don’t know?”

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

#333
post #260

Earlier quoted context omitted.

Out of curiosity, did you also implement scramble support? Or just the timing stuff?

yes. claude added a suggested random scramble (if that's what you mean?), also running average of 5/12/100, local storage of past times on first iteration, my son told it to also add a button for +2s penalties and touch screen support.

Ok cool! I have not done any cubing related coding so I don't know how complicated it gets but making sure suggested scrambles are solvable etc seems like it could be non-trivial?

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

#335
post #63
post #24

Earlier quoted context omitted.

I noticed this as well. I had to look it up. Apparently ‘pfp’ means ‘profile picture’.

Yeah I’ve always found that a cringe initialism given that it’s not Pro File Picture. I would just say avatar.

It’s a Gen-Z initialism, who are too young to be familiar with ‘avatar’, unless you’re talking about the movie.

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

#336

Earlier quoted context omitted.

Yeah, I really wonder if someone would trust to do their taxes in a vibe-coded version of Turbotax...

Do you really need Turbotax? Just feed it the tax code, your financial data, and the relevant forms and it should be good to go. Now we have freed up the labor of accountants so they can go be productive in another segment of society. /s

Looking from outside the US tax system, I feel taxes are intentionally complex to keep some people employed and to hide from questions.

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

#337

Everyone keeps saying 80/20 but that undersells what's going on. The last 20% isn't just hard. It's hard because of what happened during the first 80%. When an agent takes a shortcut early on, the next step doesn't know it was a shortcut. It just builds on whatever it was handed. And then the step after that does the same thing. So by hour 80 you're sitting there trying to fix what looks like a UI bug and you realize…

This is how all software projects play out. The difference is when it's people we call it tech debt or bad desing and then start a project to refactor. Apparently LLMs break some devs brains though. Because it's not one shot perfect they throw their hands in the air claim AI can't ever do it and move on, forgetting all those skills they (hopefully) spent years building to manage complex software. Of course a newbie v…

Except when you've worked on building the software yourself instead of getting the LLM to do it, you have a loooooooot of built-up context that you can use to know why decisions were made, to debug faster, and to get things done more efficiently.

I can look at code I wrote years ago and have absolutely no memory of writing it, but I know its my code and I know where some of the warts and traps are. I can answer questions about why things work a certain way.

With an LLM, you don't get that. You're basically starting from scratch when it comes to solving any problem or answering any question.

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

#338

Earlier quoted context omitted.

... writing the code was never the slow part. correctness (according to what people actually needed) has always been the slow part.

[flagged]

Because you did a lot of the validation along the way. Incrementally testing, thinking about design and architecture before typing.

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

#339

Earlier quoted context omitted.

... writing the code was never the slow part. correctness (according to what people actually needed) has always been the slow part.

[flagged]

No. It has nothing to do with workflows.

Writing code was always way faster than delivering software that people actually need or want. That's always been the hard part.

Post reply on HN