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…
The 100 hour gap between a vibecoded prototype and a working product
331–340 of 362 posts
Re: The 100 hour gap between a vibecoded prototype and a working product
#332Earlier 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…
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
#333Earlier 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.
Re: The 100 hour gap between a vibecoded prototype and a working product
#334Re: The 100 hour gap between a vibecoded prototype and a working product
#335Earlier 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.
Re: The 100 hour gap between a vibecoded prototype and a working product
#336Earlier 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
Re: The 100 hour gap between a vibecoded prototype and a working product
#337Everyone 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…
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
#338Earlier 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]
Re: The 100 hour gap between a vibecoded prototype and a working product
#339Earlier 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]
Writing code was always way faster than delivering software that people actually need or want. That's always been the hard part.