The 100 hour gap between a vibecoded prototype and a working product
kanfa.macbudkowski.com
The 100 hour gap between a vibecoded prototype and a working product
1–10 of 362 posts
Re: The 100 hour gap between a vibecoded prototype and a working product
#2>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects,
those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo.
with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app.
If we are talking something more difficult - it will be years - or you will need a team and it will still take a long time.
Everything less will result in an unusable product that works only for demo and has 80% churn.
Re: The 100 hour gap between a vibecoded prototype and a working product
#3The 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.
Re: The 100 hour gap between a vibecoded prototype and a working product
#4With sufficiently advanced vibe coding the need for certain type of product just vanishes.
I needed it, I quickly build it myself for myself, and for myself only.
Re: The 100 hour gap between a vibecoded prototype and a working product
#5Of course vibe coding is going to be a headache if you have very particular aesthetic constraints around both the code and UX, and you aren't capable of clearly and explicitly explaining those constraints (which is often hard to do for aesthetics).
There are some good points here to improve harnesses around development and deployment though, like a deployment agent should ask if there is an existing S3 bucket instead of assuming it has to set everything up. Deployment these days is unnecessarily complicated in general, IMO.
Re: The 100 hour gap between a vibecoded prototype and a working product
#6>> people who say they "vibecoded an app in 30 minutes" are either building simple copies of existing projects, those are not copies, they aren't even features. usually part of a tiny feature that barely works only in demo. with all vibe coding in the world today you still need at least 6 months full time to build a nice note taking app . If we are talking something more difficult - it will be years - or you will nee…
Can you expand on this? You definitely don’t need 6 months for a note taking app to be useable it is more you need to compete with the state of the art right
Re: The 100 hour gap between a vibecoded prototype and a working product
#7Woodworking is an analogy that I like to use in deciding how to apply coding agents. The finished product needs to be built by me, but now I can make more, and more sophisticated, jigs with the coding agents, and that in turn lets me improve both quality and quantity.
Re: The 100 hour gap between a vibecoded prototype and a working product
#8With sufficiently advanced vibe coding the need for certain type of product just vanishes. I needed it, I quickly build it myself for myself, and for myself only.
I built a jira with attachments and all sorts of bells and whistles. Purrs like a kitten. Saas are going extinct. At least the jobs that charged $1000 a day to write jira plugins.
Re: The 100 hour gap between a vibecoded prototype and a working product
#9With sufficiently advanced vibe coding the need for certain type of product just vanishes. I needed it, I quickly build it myself for myself, and for myself only.
I dont want that though, I want someone to spend much more time than I can afford thinking about and perfecting a product that I can pay for and dont worry about it
Re: The 100 hour gap between a vibecoded prototype and a working product
#10I 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, security etc
- The LLM makes this easier but the improvement drops to about 2-3x b/c there is a lot of back and forth + me reading the code to confirm etc (yes, another LLM could do some of this but then that needs to get setup correctly etc)
- The back and forth part can be faster if e.g. you have scripts/programs that deterministically check outputs
- Testing workloads that take hours to run still take hours to run with either a human or LLM testing them out (aka that is still the bottleneck)
So overall, this is why I think we're getting wildly different reports on how effective vibe coding is. If you've never built a data pipeline and a LLM can spin one up in a few minutes, you think it's magic. But if you've spent years debugging complicated trading or compliance data pipelines you realize that the LLM is saving you some time but not 10x time.