They're... launching an NFT product in 2026... I know it's not the point of this article, but really?
I have friends (well, friends of friends) who still play the NFT lottery. People love gambling lol
The 100 hour gap between a vibecoded prototype and a working product
211–220 of 362 posts
Re: The 100 hour gap between a vibecoded prototype and a working product
#212I 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…
More generally: LLM effectiveness is inversely proportional to domain specificity. They are very good at producing the average, but completely stumble at the tails. Highly particular brownfield optimization falls into the tails.
Re: The 100 hour gap between a vibecoded prototype and a working product
#213if something like a popup appears that i didnt ask the page to do i snap close the page and never look at it again
Re: The 100 hour gap between a vibecoded prototype and a working product
#214Earlier 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".
> I don't think people are grasping yet that this is the future of software
What about this is new?
Sitting down with a child to teach them the very basics of javascript in an hour? Trivial.
Needing Claude to do it is kind of embarassing, if anything.
Re: The 100 hour gap between a vibecoded prototype and a working product
#215Everyone 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 the actual problem is three layers back. You're not doing the "hard 20%." You're paying interest on shortcuts you didn't even know were taken. (As I type this I'm having flashbacks to helping my kid build lego sets.)
The author figured this out by accident. He stopped prompting and opened Figma to design what he actually wanted. That's the move. He broke the chain before the next stage could build on it. The 100 hours is what it costs when you don't do that.
Re: The 100 hour gap between a vibecoded prototype and a working product
#216[flagged]
c'm'on, drop that
Re: The 100 hour gap between a vibecoded prototype and a working product
#217[flagged]
> probably 30% of the total dev time was wrapping every async call in try/catch with timeouts, handling permission denials gracefully, making sure corrupted AsyncStorage doesn't brick the app
This is the exact kind of task that LLMs excel at
Re: The 100 hour gap between a vibecoded prototype and a working product
#218Earlier quoted context omitted.
>most software used is created by the user You really believe that?
Yes, because the current software paradigm (a shed/barn/warehouse full of tools to suite every possible users every possible need) doesn't make sense when LLMs can turn plain English into a software tool in the matter of minutes.
>LLMs can turn plain English into a software tool in the matter of minutes.
Unless LLMs can read minds, no one will bother to specify, even in plain english with the required level of detail. And that is assuming the user has the details in mind, which is also something pretty improbable...
Re: The 100 hour gap between a vibecoded prototype and a working product
#219Earlier 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(++)?
I personally know of an HFT firm that used Java approximately a decade ago. My guess would be they're still using it today given Java performance has only improved since then.