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

291–300 of 362 posts

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

#291

Post by Tadpole9181 »

johnfn wrote: post #261
redgridtactical wrote: post #204

[flagged]

This comment is written by an LLM, right? Edit: It's interesting how I am getting downvoted here when pangram confirms my suspicions that this is 100% AI generated.

It's impossible to be sure, but...

- Em dash

- "Not just X, it's Y"

- "It's the difference between."

- "Narrow statement. Broad statement."

I'm more and more convinced that humans were fundamentally not ready for LLMs and are not taking how existential of a threat it poses to basic communication and social normals seriously enough.

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

#292

Post by coderenegade »

phillipclapham wrote: post #168
tqwhite wrote: post #159

Earlier quoted context omitted.

YES YES YES!! I so wish that we could go back in time and never, ever have even suggested anything other that what you say here. AI doesn't do it for you. It does it with you. You have to figure out what you want before the AI codes. The thinking BEFORE is the entire game. Though I will also say that I use Claude for working out designs a lot. Literally hours sometimes with long periods of me thinking it through. And…

[flagged]

This. Code generation is cheap, so you can rapidly explore the space and figure out the architecture that best suits the problem. From there, I start fresh and pseudocode the basic pattern I want and have Claude fill in the gaps.

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

#293

Post by steveBK123 »

alexpotato wrote: post #283
steveBK123 wrote: post #201

Earlier quoted context omitted.

Absolutely. In my experience there are more “good coders” than people who are good at code review/PR/iterative feedback with another dev. A lot of people are OCD pedants about stuff that can be solved with a linter (but can’t be bothered to implement one) or just “LGTM” everything. Neither provide value or feedback to help develop other devs.

> A lot of people are OCD pedants about stuff that can be solved with a linter (but can’t be bothered to implement one) or just “LGTM” everything. Neither provide value or feedback to help develop other devs. This many be one of the best quotes on HN in a while.

Thank you, I felt old & cranky today

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

#294

Post by user34283 »

jcgrillo wrote: post #228
user34283 wrote: post #206

Earlier quoted context omitted.

And what exactly is preventing you from building bespoke software for "infrastructure monitoring and operational tooling tailed to your specific needs"? I could certainly imagine building myself some sort of dashboard. It would seem like a prime use case. You want to hear about a problem solved? Recently I extended a tool that snaps high resolution images to a Pixel art grid, adding a GUI. I added features to remove…

> And what exactly is preventing you from building bespoke software for "infrastructure monitoring and operational tooling tailed to your specific needs"? Let's say I emit roughly 1TB of telemetry data per day--logs, metrics, etc. That's roughly what you might expect from medium sized tech company or a specific department (say, security) at a large company. There is going to be a significant infrastructure investment…

I agree, that does not seem like a smart undertaking. I was thinking more of a dashboard within the existing software, or above it.

For my use case I wanted bespoke software to work with Pixel art, but obviously I would not try to build Photoshop or Aseprite from scratch. I needed only specific functionality and I was able to build that in a way fitting my workflow better than any existing software could.

I was able to build it with Claude Code and Codex. Maybe the implementation is sloppy, I did not care to check. The program works, and it's like a side project to my side project. It would not have been possible in the past, I would have needed to work with what Aseprite offers out of the box.

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

#295

Post by djaro »

IAmGraydon wrote: post #26
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.

This is a pipe dream and “sufficiently advanced” is doing a lot of heavy lifting. You really think people would rather spin up and debug their own self-made software rather than pay for something that has been tested, debugged, and proven by thousands of users? Why would anyone do that for anything more than a very simple script? It makes zero sense unless the LLM outputs literally perfect one-shot software reliably.

In which case, if LLMs can perfectly one shot simple programs, creating and maintaining a really advanced program would presumably be very cheap since it could just one shot every feature. So instead of generating new image editing programs for every task, why not pay $10/month for the guy who spent a week guiding an LLM into making ultra photoshop with every feature Ill ever need?

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

#296

Post by kantselovich »

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?

TDD helps a lot, but it’s no guarantee - LLM is smart enough to “fake” the code to pass tests .

I’m working on project - a password manager, where I have full end to end test harnesses - cli client makes changes, sync them to the server and then observe the data in iOS app running in the emulator. More than once I noticed codex just hard coded expected values from the test harnesses directly into UI layout in iOS app to make the test pass…

Similar issues in the crypto layer - tests were written first , then code was written . During the review I noticed that the code was made to just pass the test - the logic was to check if signature values exists instead of checking if crypto signature is valid.

LLM can help with code reviews as well, but it has to be guided specifically what to look for for. This is with codex 5.4 model

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

#297

Post by dijksterhuis »

johnfn wrote: post #261
redgridtactical wrote: post #204

[flagged]

This comment is written by an LLM, right? Edit: It's interesting how I am getting downvoted here when pangram confirms my suspicions that this is 100% AI generated.

scanned through history of the original commentator. i lean towards agreeing either using AI for heavy editing or fully generating comments.

---

@redgridtactical -- if you are doing so and are not aware of the new guideline

> Don't post generated comments or AI-edited comments. HN is for conversation between humans.

https://news.ycombinator.com/newsguidelines.html

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

#298

Post by ThrowawayR2 »

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…

Kind of a tangent but that did make me curious about how numbers are written in Arabic: https://en.wikipedia.org/wiki/Eastern_Arabic_numerals

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

#299

Post by kantselovich »

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.

100%! Lots of issues are only discovered when enough code has been written. More than that , other issues are discovered only when the project is actually deployed as MVP.

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

#300

Post by djeastm »

cvhc wrote: post #282
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…

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