Live data from Hacker News

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

kanfa.macbudkowski.com

101–110 of 362 posts

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

#101
post #13

I have had the experience with creating https://swiftbook.dev/learn Used Codex for the whole project. At first I used claude for the architect of the backend since thats where I usually work and got experience in. The code runner and API endpoints were easy to create for the first prototype. But then it got to the UI and here's where sh1t got real. The first UI was in react though I had specifically told it to use Vu…

You can say "shit" here if you like.

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

#102
What I really want to know is... as a software developer for 25+ years, when using these AI tools- it is still called "vibecoding"? Or is "vibecoding" reserved for people with no/little software development background that are building apps. Genuine question.

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

#103

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…

There’s a big gap between reality and the influencer posts about LLMs. I agree with you that LLMs do provide some significant acceleration, but the influencers have tried to exaggerate this into unbelievable numbers. Even non-influencers are trying to exaggerate their LLM skills as a way to get hired or raise their status on LinkedIn. I rarely read the LinkedIn social feed but when I check mine it’s now filled with c…

Day 7 of using Claude Code here are my takes...

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

#104
post #73

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…

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

As long as you tune the JVM right it can be faster. But its a big if with the tune, and you need to write performant code

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

#105
post #47

Earlier quoted context omitted.

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

And some people do, both things can be true. I'd rather make a tool just for me that breaks when I introduce a new requirement and I just add into it and keep going.

The statement wasn't: "no one ever vibe codes an alternative to product X"

It was: "With sufficiently advanced vibe coding the need for certain type of product just vanishes."

If a product has 100 thousand users and 1% of them vibe codes an alternative for themselves, the product / business doesn't vanish. They still have 99 thousand of users.

That was the rebuttal, even if not presented as persuasively and intelligently as I just did.

So no, it's not the case of "both things being true". It's a case of: he was wrong.

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

#106
post #73

Earlier quoted context omitted.

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

Not necessarily. Java can be insanely performant, far more than I ever gave it credit for in the first decade of its existence. There has been a ton of optimization and you can now saturate your links even if you do fairly heavy processing. I'm still not a fan of the language but performance issues seem to be 'mostly solved'.

"Saturating your links" is rarely the goal in HFT.

You want low deterministic latency with sharp tails.

If all you care about is throughput then deep pipelines + lots of threads will get you there at the cost of latency.

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

#107

Earlier quoted context omitted.

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

The future is narrow bespoke apps custom tailored for exactly that one single users use case. An example would be if the user only ever works with .jpg files, then you don't need to support any of the dozens of other formats an image program would support. I cannot stress enough how many software users out there are only using 1-10% of a program's capability, yet they have to pay for a team of devs who maintain 100%…

"The future" is fiction. It's a blank canvas where you can make a fingerpainting of any fantasy you like. Whenever people tell me about "the future" I know they're talking absolute rubbish. And I also like your fantasy! But it probably won't happen.

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

#108
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…

I don't think people are grasping yet that this is the future of software, if by no metric other than "most software used is created by the user".

>most software used is created by the user

You really believe that?

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

#109

I’ve had a similar experience. I’ve been vibecoding a personal kanban app for myself. Claude practically one-shotted 90% of the core functionality (create boards, lanes, cards, etc.) in a single session. But after that I’ve now spent close to 30 hours planning and iterating on the remaining features and UI/UX tweaks to make the app actually work for me, and still, it doesn’t feel "ready" yet. That’s not to say it has…

I've got a few projects I've generated, along with a wholly handwritten project started in Dec.

The difference I've noticed is that the act of actually typing out code made me backtrack a few times refining the possible solutions before even starting the integration tests, sometimes before even doing a compile.

When generating, the LLM never backtracked, even in the face of broken tests. It would proceed to continue band-aiding until everything passed. It would add special exceptions to general code instead of determining that the general rule should be refined or changed.

The reason that some devs are reporting 10x productivity is because a bunch of duct-taped, band-aided, instant-legacy code is acceptable. Others who dont see that level of productivity increase are spending time fixing the code to be something they can read.

Not sure yet if accepting the spaghetti is the right course. If future LLMs can understand this spaghetti then theres no point in good code. If we still need human coders, then the productivity increase is very small.

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

#110

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…

There’s a big gap between reality and the influencer posts about LLMs. I agree with you that LLMs do provide some significant acceleration, but the influencers have tried to exaggerate this into unbelievable numbers. Even non-influencers are trying to exaggerate their LLM skills as a way to get hired or raise their status on LinkedIn. I rarely read the LinkedIn social feed but when I check mine it’s now filled with c…

> 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 replace the current software I'm using? So, you're looking for work? Why is nobody buying it?

Where is the Quicken replacement that was vibecoded and shipping today? Where are the vibecoded AAA games that are going to kill Fortnite? Where is the vibecoded Photoshop alternative? Heck, where is the vibecoded replacement for exim3 that I can deploy on my self hosted E-mail server? Where are all of the actual shipping vibecoded products that millions of users are using?

Post reply on HN