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

81–90 of 362 posts

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

#81

Post by advancespace »

101008 wrote: post #59
keyle wrote: post #8

Earlier quoted context omitted.

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.

SaaS are not going exctinct. This reminds me of the LinkedIn posts saying they clone Slack in two hours, copying the UI, etc. Yeah, if you think Slack is private chat rooms then you should use IRC for your company. One of the most valuable things about Slack is the ecosystem: apps, API support, etc. If you need to receive notifications from external apps (like PageDuty or Incident.io or something like that), good luc…

[dead]

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

#82

Post by [deleted] »

jcgrillo wrote: post #46
niemandhier wrote: post #4

With 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.

How many products are actually like that? If I could easily replace github, datadog/sentry/whatever, cloudflare, aws, tailscale that would be great. In my view building and owning is better than buying or renting. Especially when it comes to data--it would be much better for me to own my telemetry data for example than to ship it off to another company. But I don't think you (or anyone) will be vibecoding replacement…

[deleted]

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

#83

Post by PunchTornado »

rhoopr wrote: post #25

This seems more like he is bad at describing what he wants and is prompting for “a UI” and then iterating “no, not like that” for 99 hours.

Yeah but if you have to describe in very much details in english, you're better of just writing it with autocomplete.

I find that vibe coding is useful when it can be build with little details and it makes the right assumptions.

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

#84

Post by neonbrain »

Aperocky wrote: post #48
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…

The magic is testing. Having locally available testing and high throughput testing with high amount of test cases now unlocks more speed. The test cases themselves becomes the foci - the LLM usually can't get them right.

The word "Testing" is a very loaded term. Few non-professionals, or even many professionals, fully understand what is meant by it.

Consider the the following: Unit, Integration, System, UAT, Smoke, Sanity, Regression, API Testing, Performance, Load, Stress, Soak, Scalability, Reliability, Recovery, Volume Testing, White Box Testing, Mutation Testing, SAST, Code Coverage, Control Flow, Penetration Testing, Vulnerability Scanning, DAST, Compliance (GDPR/HIPAA), Usability, Accessibility (a11y), Localization (L10n), Internationalization (i18n), A/B Testing, Chaos Engineering, Fault Injection, Disaster Recovery, Negative Testing, Fuzzing, Monkey Testing, Ad-hoc, Guerilla Testing, Error Guessing, Snapshot Testing, Pixel-Perfect Testing, Compatibility Testing, Canary Testing, Installation Testing, Alpha/Beta Testing...

...and I'm certain I've missed dozens of other test approaches.

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

#86

Post by ianm218 »

risyachka wrote: post #33
ianm218 wrote: post #6

Earlier quoted context omitted.

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

> Can you expand on this? sure. does your note taking app supports formatting? you don't need it today. you will need it at some point. images? same. does it handle file corruption etc? no? then its pretty much useless. does it work across devices? in modern world, again, it is pretty much useless without it it works across devices? then it needs hosting. if it is hosted it needs auth, it needs backups you can go on…

Obsidian is super popular and is generally local first and device specific.

And even so if your starting a note taking app most of those problems like file corruption and image support are largely solved problems. There is also the benefit of being able to reference tons of open source implementations.

I think one month to notion like app that is prod ready if you just need Auth + markdown + images + standard text editing

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

#87

Post by yojo »

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…

> - This is partly b/c it is good at things I'm not good at (e.g. front end design)

Everyone thinks LLMs are good at the things they are bad at. In many cases they are still just giving “plausible” code that you don’t have the experience to accurately judge.

I have a lot of frontend app dev experience. Even modern tools (Claude w/Opus 4.6 and a decent Claude.md) will slip in unmaintainable slop in frontend changes. I catch cases multiple times a day in code review.

Not contradicting your broader point. Indeed, I think if you’ve spent years working on any topic, you quickly realize Claude needs human guidance for production quality code in that domain.

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

#88

Post by tyingq »

grim_io wrote: post #73
matt_heimer wrote: post #45

Earlier 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(++)?

Depends. Many reasons, but one is that Java has a much richer set of 3rd party libraries to do things versus rolling your own. And often (not always) third party libraries that have been extensively optimized, real world proven, etc.

Then things like the jit, by default, doing run time profiling and adaptation.

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

#89

Post by jacquesm »

matt_heimer wrote: post #45
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…

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…

AI is extremely good at the things that it has many examples for. If what you are doing is novel then it is much less of a help, and it is far more likely to start hallucinating because 'I don't know' is not in the vocabulary of any AI.

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

#90

Post by tossandthrow »

nemo44x wrote: post #3

The 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.

Yes, so 80% of 100 hours is considerably less than 80% of 600 hours
Post reply on HN