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

171–180 of 362 posts

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

#171

Post by [deleted] »

FpUser wrote: post #70
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…

I am curious about what causes some to choose Java for HFT. From what I remember the amount of virgin sacrifices and dances with the wolves one must do to approach native speed in this particular area is just way too much of development time overhead.

[deleted]

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

#172

Post by megous »

neonbrain wrote: post #84
Aperocky wrote: post #48

Earlier quoted context omitted.

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, Vulnerabili…

You forgot a hope-driven development and release process and other optimism based ("i'm sure it's fine" method), or faith based approaches to testing (ship and pray, ...). Customer driven invluntary beta testing also comes to mind and "let's see what happens" 0-day testing before deployment. We also do user-driven error discovery, frequently.

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

#173

Post by nunez »

makingstuffs wrote: post #151

I’m sure someone else has probably coined the term before me (or it’s just me being dumb, often the case) but I’ve started calling this phase of SWE ‘Ricky Bobby Development’. So many people are just shouting ‘I wanna go fast’ and completely forgetting the lessons learned over the past few decades. Something is going to crash and burn, eventually. I say this as a daily LLM user, albeit a user with a very skeptical vi…

I love this!

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

#174

Post by colechristensen »

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…

Then you list all of the things you want it not to do and construct a prompt to audit the codebase for the presence of those things. LLMs are much better at reviewing code than writing it so getting what you want requires focusing more on feedback than creation instructions.

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

#175

Post by snovv_crash »

wierdbytes wrote: post #141
ryandrake wrote: post #110

Earlier quoted context omitted.

> I rarely read the LinkedIn social feed but when I check mine it’s now filled with claims from people about going from idea to shipped product in N days (with a note at the bottom that they’re looking for a new job or available to consult with your company). This always seems to be the pattern. "I vibe coded my product and shipped it in 96 hours!" OK, what's the product? Why haven't I heard of it? Why can't it repla…

> Where are all of the actual shipping vibecoded products that millions of users are using? Claude Code and OpenClaw - they are vibecoded. And I believe more coming.

But it's like crypto then, good for buying other crypto, or illegal stuff.

Also people are using CC for the cheap access to the model, otherwise they'd be using opencode.

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

#176

Post by apitman »

tqwhite wrote: post #161
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.

I think ralphing is for purely vibe coded stuff, where you're literally never looking at the code and only asking for changes to the final output.

If I'm reviewing all the code, so far I'm still the bottleneck even with a single agent and I don't see an easy way to change that.

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

#177

Post by nunez »

capitalsigma wrote: post #60
fzeroracer wrote: post #22

I can't say I'm impressed by this at all. 100+ hours to build a shitty NFT app that takes one picture and a predefined prompt, then mints you a dinosaur NFT. This is the kind of thing I would've seen college students slam out over a weekend for a coding jam with no experience and a few cans of red bull with more quality and effort. Has our standards really gotten so low? I don't see any craftsmanship at play here.

Also the process sounds like a nightmare: "it broke and I asked 4 different LLMs to fix it; my `AGENTS.md` file contained hundreds of special cases; etc." I thought this article was intended to be a horror story, not an advertisement

If nothing else, at least the age of AI finally got devs to write good documentation!

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

#178

Post by sieste »

zahlman wrote: post #120
sieste wrote: post #43

Earlier 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…

... So at no point in this did anyone even question why it should be a website ?

"use it from anywhere" was important, and I don't think there's an easier way than a freely hosted static website.

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

#179

Post by hsuduebc2 »

quater321 wrote: post #127
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…

At this point, every programmer who claims that vibecoding doesn't make you at least 10 times more productive is simply lying or worst, doesn't know how to vibe code. -So, you want to tell me that you don't review the code you write? Or that others don't review it? - You bring up ONE example with a bottleneck that has nothing to do with programming. Again, if you claim it doesn't make you 10x more productive, you don…

What exactly are you producing? LinkedIn posts?

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

#180

Post by mordechai9000 »

youknownothing wrote: post #138
ryandrake wrote: post #110

Earlier quoted context omitted.

> I rarely read the LinkedIn social feed but when I check mine it’s now filled with claims from people about going from idea to shipped product in N days (with a note at the bottom that they’re looking for a new job or available to consult with your company). This always seems to be the pattern. "I vibe coded my product and shipped it in 96 hours!" OK, what's the product? Why haven't I heard of it? Why can't it repla…

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
Post reply on HN