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

321–330 of 362 posts

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

#321

Post by capplexham »

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

This makes sense when you stop viewing the LLM as a "vending machine" for apps and start seeing it as a repository of software deltas.

LLMs aren't just trained on final code; they are trained on the entire history of pull requests, review comments, and issue discussions that move a project from one version to the next.

When I use an LLM now, my workflow has shifted entirely. I’ve stopped trying to be the "coder" and have instead stepped into the role of PR Reviewer and Power User. My job is to point out edge cases, define the spec, and catch regressions—effectively managing a "virtual team" that handles the boilerplate and feature implementation.

Expecting a one-shot 1.0 release is unrealistic because it bypasses the thousand micro-decisions that happen in a real dev cycle. By embracing the "review and refine" loop, I’m becoming a better maintainer, even if that 100-hour gap to a polished product still exists.

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

#322

Post by bmurphy1976 »

mrothroc wrote: post #215

Everyone keeps saying 80/20 but that undersells what's going on. The last 20% isn't just hard. It's hard because of what happened during the first 80%. When an agent takes a shortcut early on, the next step doesn't know it was a shortcut. It just builds on whatever it was handed. And then the step after that does the same thing. So by hour 80 you're sitting there trying to fix what looks like a UI bug and you realize…

This is how all software projects play out. The difference is when it's people we call it tech debt or bad desing and then start a project to refactor.

Apparently LLMs break some devs brains though. Because it's not one shot perfect they throw their hands in the air claim AI can't ever do it and move on, forgetting all those skills they (hopefully) spent years building to manage complex software. Of course a newbie vibe coder won't know this but an experienced developer should.

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

#323

Post by neonbrain »

worik wrote: post #251
neonbrain wrote: post #84

Earlier quoted context omitted.

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

Why did you assume I'm talking about a "provable best way"? I meant that it doesn't make sense to talk simply about "testing" without clarifying what one means by it. If you assume that the absence of a "provable best way" implies a lack of utility, let me remind you that there is no "provable best way" for training LLMs either. Does that matter in practice?

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

#325

Post by nanobuilds »

stainlu wrote: post #324

[flagged]

One can hope that vibecoded apps will eventually be vibe-maintained with agents trained specifically for the kind of novel and weird bugs ai-coding tends to bring up. These tools will hopefully also get better at identifying security risks created but previous generations of ai models. 6 months is a long time in the life of a vibe coded app.

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

#327

Post by qsera »

Gareth321 wrote: post #284
qsera wrote: post #218

Earlier quoted context omitted.

>LLMs can turn plain English into a software tool in the matter of minutes. Unless LLMs can read minds, no one will bother to specify, even in plain english with the required level of detail. And that is assuming the user has the details in mind, which is also something pretty improbable...

You need to think outside the box a little. They're not going to need to write a requirements doc from scratch. They'll tell it to copy a piece of software which is already established and make some customisations or improvements based on their needs. This is a few sentences.

But if most software is created by user, then where does this reference piece come from?

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

#328

Post by godelski »

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…

Honestly I think we're just becoming more aware of this way of thinking. It's certainly exacerbated it now that everyone has "an expert" in their pocket.

It's no different than conspiracy theorists. We saw a lot more with the rise in access to the internet. Not because they didn't put in work to find answers to their questions, but because they don't know how to properly evaluate things and because they think that if they're wrong then it's a (very) bad thing.

But the same thing happens with tons of topics, and it's way more socially acceptable. Look how everyone has strong opinions on topics like climate, rockets, nuclear, immigration, and all that. The problem isn't having opinions or thoughts, but the strength of them compared to the level of expertise. How many people think they're experts after a few YouTube videos or just reading the intro to the wiki page?

Your PM is no different. The only difference is the things they believed in, not the way they formed beliefs. But they still had strong feelings about something they didn't know much about. It became "their expert" vs "your expert" rather than "oh, thanks for letting me know". And that's the underlying problem. It's terrifying to see how common it is. But I think it also leads to a (partial) solution. At least a first step. But then again, domain experts typically have strong self doubt. It's a feature, not a bug, but I'm not sure how many people are willing to be comfortable with being uncomfortable

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

#329

Post by [deleted] »

andriy_koval wrote: post #234
tyingq wrote: post #88

Earlier quoted context omitted.

Depends. Many reasons, but one is that Java has a much richer set of 3rd party libraries to do things versus rolling your own. And often (not always) third party libraries that have been extensively optimized, real world proven, etc. Then things like the jit, by default, doing run time profiling and adaptation.

Java has huge ecosystem in enterprise dev, but very unlikely it has ecosystem edge in high performance/real time compute.

[deleted]

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

#330

Post by andriy_koval »

matt_heimer wrote: post #278
andriy_koval wrote: post #240

Earlier quoted context omitted.

> Passing data between them is off heap how exactly you are passing data? You can pass some primitives without allocating them on heap. You can use some tiny subset of Java+standard library to write high performance code, but why would you do this instead of using Rust or C++?

In some places I'm using https://github.com/aeron-io/agrona Strangely this is one of the areas where I want to use project panama so I might re-implement some of the ring buffers constructs. You allocate off heap memory and dump data into it. With modern Java classes like Arena, MemoryLayout, and VarHandle it's honestly a lot like C structs. I answered "why" in another post in this thread.

> You allocate off heap memory and dump data into it. With modern Java classes like Arena, MemoryLayout, and VarHandle it's honestly a lot like C structs.

my opinion is that no, it is not, declaring and using C struct is 20x times more transparent, cost efficient and predictable. And that's we talking about C raw stucts, which has lots of additional ergonomics/safety/expression improvements in both c++ and rust on top of it.

Post reply on HN