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

61–70 of 362 posts

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

#61

Post by linsomniac »

jimnotgym wrote: post #37

I have not been coding for a few years now. I was wondering if vibe coding could unstick some of my ideas. Here is my question, can I use TDD to write tests to specify what I want and then get the llm to write code to pass those tests?

To expand on the "Yes": the AI tools work extremely well when they can test for success. Once you have the tests as you'd like them, you may want to tell the LLM not to modify the tests because you can run into situations where it'll "fix" the tests rather than fixing the code.

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

#62

Post by westurner »

westurner wrote: post #51

I keep seeing things that were vibe coded and thinking, "That's really impressive for something that you only spent that much time on". To have a polished software project, you must spend time somewhat menially iterating and refining (as each type of user). To have a polished software project, you need to have started with tests and test coverage from the start for the UI, too. Writing tests later is not as good. I h…

Is 100 hours enough?

A 40-hour work year has 2,080 hours per person per year.

The "10,000" hours necessary to be really good at anything number was the expert threshold that they used to categorize test subjects who performed neuroimaging studies while compassion meditating. "10,000" hours to be an expert is about 5 years at full time.

But how many hours to have a good software product?

Usually I check for tests and test coverage first. You could have spent 1,000 hours on a software project and if it doesn't have automated tests, we can't evolve the software and be sure that we haven't caused regressions.

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

#63

Post by xp84 »

etothet wrote: post #24
skyberrys wrote: post #23

If you ask for something complicated this headline is more than true. But why complicate things, keep it simple and keep it fast. Also this article uses 'pfp' like it's a word, I can't figure out what it means. I'm able to vibe code simple apps in 30 minutes, polish it in four hours and now I've been enjoying it for 2 months.

I noticed this as well. I had to look it up. Apparently ‘pfp’ means ‘profile picture’.

Yeah I’ve always found that a cringe initialism given that it’s not Pro File Picture. I would just say avatar.

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

#64

Post by __mp »

jimnotgym wrote: post #37

I have not been coding for a few years now. I was wondering if vibe coding could unstick some of my ideas. Here is my question, can I use TDD to write tests to specify what I want and then get the llm to write code to pass those tests?

yes. depending on the techstack your experience might be better or worse. HTML/CSS/React/Go worked great, but it struggled with Swift (which I had no experience in).

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

#67

Post by tim-projects »

I started working on one of my apps around a year ago. There was no ai CLI back then. My first prototype was done in Gemini chat. It took a week copy and pasting text between windows. But I was obsessed.

The result worked but that's just a hacked together prototype. I showed it to a few people back then and they said I should turn it into a real app.

To turn it into a full multi user scaleable product... I'm still at it a year later. Turns out it's really hard!

I look at the comments about weekend apps. And I have some of those too, but to create a real actual valuable bug free MVP. It takes work no matter what you do.

Sure, I can build apps way faster now. I spent months learning how to use ai. I did a refactor back in may that was a disaster. The models back then were markedly worse and it rewrote my app effectively destroying it. I sat at my desk for 12 hours a day for 2 weeks trying to unpick that mess.

Since December things have definitely gotten better. I can run an agent up to 8 hours unattended, testing every little thing and produce working code quite often.

But there is still a long way to go to produce quality.

Most of the reason it's taking this long is that the agent can't solve the design and infra problems on its own. I end up going down one path, realising there is another way and backtracking. If I accepted everything the ai wanted, then finishing would be impossible.

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

#68

Post by jcgrillo »

CuriouslyC wrote: post #54
jcgrillo wrote: post #46

Earlier quoted context omitted.

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…

Github is on the chopping block as a tool (it's sticky as a social network). The other stuff not so much. The things that are going away are tools that provide convenience on top of a workflow that's commoditized. Anything where the commercial offering provides convenience rather than capabilities over the open source offerings is gonna get toasted.

Even at recent levels of uptime I think it would be very difficult to build a competing product that could function at the scale of even a small company (10 engineers). How would you implement Actions? Code review comments/history? Pull requests? Issues? Permalinks? All of these things have serious operational requirements. If you just want some place to store a git repository any filesystem you like will do it but when you start talking about replacing github that's a different story altogether and TBH I don't think building something that appears to function the same is even the hard part, it's the scaling challenges you run into very quickly.

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

#69

Post by jsdalton »

lacedeconstruct wrote: post #9
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.

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

The metaphor that’s popped into my head recently is baking bread.

You can learn to bake good bread. It’s not _that_ hard. And it’ll probably taste better than store bought bread.

But it almost certainly won’t be cheaper. And it’ll take a more more time and effort.

Still, sometimes you might bake your own bread for kicks. But most of the time, you’ll just buy the bread someone else has already perfected.

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

#70

Post by FpUser »

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…

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