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

311–320 of 362 posts

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

#311

Post by dehrmann »

devld wrote: post #221

My non-technical client has totally vibe coded a SaaS prototype with lots of features, way bigger product than OP and it sort of works. They spent like 200 hours on it. I wonder what would have been the time needed to clean it up and approve it is secure. I declined to work on it, as I was not sure if it's even possible or if it would be better to rewrite the entire thing from scratch with better prompts. I was not t…

> I declined to work on it, as I was not sure if it's even possible or if it would be better to rewrite the entire thing from scratch with better prompts.

This is a bit of an unknown right now. If you get a working prototype, but need to productionize it, make sure it can scale, and get it looked over with a security mineset, how long it might take isn't clear, so finding someone who will do that is hard.

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

#312

Post by aeonfox »

djeastm wrote: post #300
cvhc wrote: post #282

Earlier quoted context omitted.

> Testing workloads that take hours to run still take hours to run with either a human or LLM testing them out (aka that is still the bottleneck) Actually I had some terrible experiences when asking the agent to do something simple in our codebase (like, rename these files and fix build scripts and dependencies) but it spent much longer time than a human, because it kept running the full CI pipelines to check the pro…

Can't this be solved with something like "Don't run any CI commands" in the AGENTS.md?

Except for the times you do want it to run the CI.

LLM issues can often be solved by being more and more specific, but at some point being specific enough is just as time consuming as jumping in and doing it yourself.

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

#313

Post by teleforce »

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 LLM makes this easier but the improvement drops to about 2-3x b/c there is a lot of back and forth + me reading the code to confirm etc (yes, another LLM could do some of this but then that needs to get setup correctly etc)

> The back and forth part can be faster if e.g. you have scripts/programs that deterministically check outputs

This is where configuration language like CUE can be useful in complementing LLM [1].

It's the deterministic NLP cousin of the stochastic LLM based on mathematically sound latticed-value logic [2].

[1] Guardrailing Intuition: Towards Reliable AI:

https://cue.dev/blog/guardrailing-intuition-towards-reliable...

[2] The Logic of CUE:

https://cuelang.org/docs/concept/the-logic-of-cue/

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

#314

Post by shepherdjerred »

pindab0ter wrote: post #279
shepherdjerred wrote: post #272

My experience is that Claude Code, when used appropriately, can produce work better than most programmers. "when used appropriately" means: - Setting up guardrails: use a statically typed language, linters, CLAUDE.md/skills for best practices. - Told to do research when making technical decisions, e.g. "look online for prior art" or "do research and compare libraries for X" - Told to prioritize quality and maintainab…

Where do you keep the skills it generates from docs? Does this not become a mess?

It can go in your repo or your home dir.

Why would it become a mess? If I made a skill for, say, BuildKite, Claude will only load it when applicable.

They will eventually get out of date, so that is something you’ll have to accept or perhaps make some meta skill-updater program to run on a schedule

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

#315

Post by Aperocky »

robhlt wrote: post #165
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.

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

By sweat and tears, and unfortunately, AI can only help so much in those cases. You'll have to have a really concrete idea about what your product is and how it should work.

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

#316

Post by Aperocky »

worik wrote: post #248
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 magic is testing. No it is not. There os no amount of testing that can fix a flawed design

That is a given, similar to how no amount of implementation can fix a wrong product. Both statements are not very meaningful.

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

#319

Post by plastic041 »

> Since my main goal was to learn, I decided to do it "the right way". This means I didn’t want to rely on Replit or Lovable where the infra part is obfuscated. I wanted to deal with that complexity myself.

I expected OP to actually 'learn' devops, but what they did was just asking LLMs to do everything.

Also...

> 180+ paid $2 for a dino

People pays $2 for an image of dinosaur with human face?

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

#320

Post by capplexham »

This isn’t surprising when you consider how LLMs are actually trained to write code.

Expecting a one-shot 1.0 release is unrealistic because the sheer volume of context and decision-making required for a finished product is enormous.

Instead, I think of LLMs as being trained on the "delta" of software development: the pull requests, review comments, and issue discussions that move a project from one version to the next.

When you use an LLM for coding, you are effectively tapping into the collective output of a team of developers and a crowd of users. My mental model has shifted accordingly: I no longer try to be the "coder." Instead, I act as the PR reviewer and the passionate power user. My job is to point out edge cases and refine the output, rather than expecting a finished product in one go.

It’s making me a better maintainer and a more precise communicator, even if the "100-hour gap" to production remains a reality.

Post reply on HN