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

251–260 of 362 posts

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

#251

Post by worik »

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…

There is no science to testing, no provable best way, despite many people's vehement opinions

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

#252

Post by suzzer99 »

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.

I recently had to build a widget that lets the user pick from a list of canned reports and then preview them in an overlay before sending to the printer (or save to PDF). All I knew was that I wanted each individual report's logic and display to be in its own file, so if the system needed to grow to 100 reports, it wouldn't get any more complicated than with 6 reports.

The final solution ended up being something like: 1. Page includes new React report widget. 2. Widget imports generic overlay component and all canned reports, and lets user pick a report. 3. User picks report, widget sets that specific report component as a child of the overlay component, launches overlay. 4. Report component makes call to database with filters and business logic, passes generic set of inputs (report title, other specifics, report data) to a shared report display template.

My original plan was for the report display template to also be unique to each report file. But when the dust settled, they were so similar that it made sense to use a shared component. If a future report diverges significantly, we can just skip the shared component and create a one-off in the file.

I could have designed all this ahead of time, as I would need to do with an LLM. But it was 10x easier to just start coding it while keeping my ultimate scalability goals in mind.

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

#253

Post by tstenner »

withinboredom wrote: post #199
riffraff wrote: post #92

Earlier quoted context omitted.

> there's a reason nobody outside tech trust so blindly on LLMs. Man, I wish this was true. I know a bunch of non tech people who just trusts random shit that chatgpt made up. I had an architect tell me "ask chatgpt" when I asked her the difference between two industrial standard measures :) We had politicians share LLM crap, researchers doing papers with hallucinated citations.. It's not just tech people.

We were working on translations for Arabic and in the spec it said to use "Arabic numerals" for numbers. Our PM said that "according to ChatGPT that means we need to use Arabic script numbers, not Arabic numerals". It took a lot of back-and-forths with her to convince her that the numbers she uses every day are "Arabic numerals". Even the author of the spec could barely convince her -- it took a meeting with the Arab…

The architect should have required Hindu numbers. Same result, but even more confusion.

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

#254

Post by cyk21 »

phillipclapham wrote: post #85

[flagged]

This.

Additionally, the author seems to build an app just for the sake of building an app / learning, not to solve any real serious business problem. Another "big" claim on LLM capabilities based on a solo toy project.

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

#255

Post by suzzer99 »

s1mon wrote: post #52
raincole wrote: post #49

They're... launching an NFT product in 2026... I know it's not the point of this article, but really?

Yep. As much as the rest of it resonated with LLM coding experiences I'm having, the NFT thing is unfortunate.

I'd pay a few bucks for some cool avatar or w/e this is. It seems like a good use of NFTs.

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

#256

Post by dwaltrip »

jacquesm wrote: post #183
Filligree wrote: post #158

Earlier quoted context omitted.

> because 'I don't know' is not in the vocabulary of any AI. That is clearly false. I’m only familiar with Opus, but it quite regularly tells me that, and/or decides it needs to do research before answering. If I instruct it to answer regardless, it generally turns out that it indeed didn’t know.

I haven't had that at all, not even a single time. What I have had is endless round trips with me saying 'no, that can't work' and the bot then turning around and explaining to me why it is obvious that it can't work... that's quite annoying.

Try something like:

> Please carefully review (whatever it is) and list out the parts that have the most risk and uncertainty. Also, for each major claim or assumption can you list a few questions that come to mind? Rank those questions and ambiguities as: minor, moderate, or critical.

> Afterwards, review the (plan / design / document / implementation) again thoroughly under this new light and present your analysis as well as your confidence about each aspect.

There's a million variations on patterns like this. It can work surprisingly well.

You can also inject 1-2 key insights to guide the process. E.g. "I don't think X is completely correct because of A and B. We need to look into that and also see how it affects the rest of (whatever you are working on)."

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

#258

Post by jacquesm »

dwaltrip wrote: post #256
jacquesm wrote: post #183

Earlier quoted context omitted.

I haven't had that at all, not even a single time. What I have had is endless round trips with me saying 'no, that can't work' and the bot then turning around and explaining to me why it is obvious that it can't work... that's quite annoying.

Try something like: > Please carefully review (whatever it is) and list out the parts that have the most risk and uncertainty. Also, for each major claim or assumption can you list a few questions that come to mind? Rank those questions and ambiguities as: minor, moderate, or critical. > Afterwards, review the (plan / design / document / implementation) again thoroughly under this new light and present your analysis…

Ok! I will try that, thank you very much.

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

#259

Post by ryandrake »

piersj225 wrote: post #210
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…

I found one example of this going very wrong on reddit the other day - https://www.reddit.com/r/selfhosted/comments/1rckopd/huntarr... One redditor security reviews a vibe coded project

Wow, great example, and great example of what these fakers do when called out. Summary:

The maintainer, instead of listening to the security researcher and accepting feedback about his development process, instead:

1. Denied the problem

2. Censored discussion of the problem

3. Banned the people calling out the problem

...and then when the security issues were posted more publicly and got traction...

4. Made the subreddit private

5. Wiped and deleted his account

6. Wiped and deleted the GitHub repo

7. Took the project's web site off the web

Absolutely wild and unhinged behavior.

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

#260

Post by sieste »

kaffekaka wrote: post #226
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…

Out of curiosity, did you also implement scramble support? Or just the timing stuff?

yes. claude added a suggested random scramble (if that's what you mean?), also running average of 5/12/100, local storage of past times on first iteration, my son told it to also add a button for +2s penalties and touch screen support.
Post reply on HN