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

161–170 of 362 posts

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

#161

Post by tqwhite »

youknownothing wrote: post #149

I'm having somewhat good experiences with AI but I think that's because I'm only half-adopting it: instead of the full agentic / Ralphing / the-AI-can-do-anything way, I still do work in very small increments and review each commit. I'm not as fast as others, but I can catch issues earlier. I also can see when code is becoming a mess and stop to fix things. I mean, I don't fix them manually, I point Claude at the mes…

I would love it if someone explained what their ten agents Ralphing away were actually told to do.

I suppose if you are doing something that truly can be decided based on a test but, I just don't see it, at least for anything I do.

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

#162

Post by amelius »

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…

Also, now you're reading someone else's code and not everybody likes that. In fact, most self-proclaimed 10x coders I know hate it.

So instead of the 10x coder doing it, the 1x coder does it, but then that factor of 3x becomes 0.3x.

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

#163

Post by aenis »

The interesting part about vibe coding is the spectrum of experiences and attitudes. I have been playing with it for 2-3hrs a day for the last 4 months now. None of my friends who are using it are using it in the same way. Some people vibe and then refactor, some spec-everything and micro-prompt the solutions. Nobody is feeling like this thing can go unsupervised.

And then there is one guy, a friend of mine, who is planning to release a "submit a bug report, we will fix it immediately" feature (so, collect error report from a user, possibly interview them, then assess if its a bug or not with a "product owner LLM", and then autonomously do it, and if it passes the tests - merge and push to prod - all under one hour. Thats for a mid cap company, for their client-facing product. F*** hell! I have a full bag of bug reports ready for when this hits prod :->

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

#165

Post by robhlt »

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.

How does that test suite get built and validated? A comprehensive and high quality test suite is usually much larger than the codebase it tests. For example, the sqlite test suite is 590x [1] the size of the library itself

1. https://sqlite.org/testing.html

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

#166

Post by phillipclapham »

AstroBen wrote: post #130
phillipclapham wrote: post #85

[flagged]

I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.

[flagged]

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

#167

Post by zahlman »

mentalgear wrote: post #95

> The "remaining 10 percent" is a difference between slop and something people enjoy. I would say the remaining 10% are about how robust your solution is - anything associated with 'vibe' feels inherently unsecure. If you can objectively proof it is not, that's 10 % time well spend.

> anything associated with 'vibe' feels inherently unsecure.

Only "feels"?

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

#168

Post by phillipclapham »

tqwhite wrote: post #159
phillipclapham wrote: post #85

[flagged]

YES YES YES!! I so wish that we could go back in time and never, ever have even suggested anything other that what you say here. AI doesn't do it for you. It does it with you. You have to figure out what you want before the AI codes. The thinking BEFORE is the entire game. Though I will also say that I use Claude for working out designs a lot. Literally hours sometimes with long periods of me thinking it through. And…

[flagged]

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

#169

Post by tqwhite »

carterparks wrote: post #42

I think there's a lot to pick apart here but I think the core premise is full of truth. This gap is real contrary to what you might see influencers saying and I think it comes from a lot of places but the biggest one is writing code is very different than architecting a product. I've always said, the easiest part of building software is "making something work." The hardest part is building software that can sustain m…

An advantage I have enjoyed is that I am insanely careful about my fundamental architecture and I have a project scaffold that works correctly.

It has examples of all the parts of a web app written, over many years, to be my own ideal structure. When the LLM era arrived, I added a ton of comments explaining what, why and how.

It turns out to serves as a sort of seed crystal for decent code. Though, if I do not remind it to mimic that architecture, it sometimes doesn't and that's very weird.

Still, that's a tip I suggest. Give it examples of good code that are commented to explain why its good.

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

#170

Post by apitman »

AstroBen wrote: post #130
phillipclapham wrote: post #85

[flagged]

I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.

See "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf
Post reply on HN