[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.
The 100 hour gap between a vibecoded prototype and a working product
261–270 of 362 posts
Re: The 100 hour gap between a vibecoded prototype and a working product
#262Earlier quoted context omitted.
This is exactly my experience at Lovable. For some parts of the organization, LLMs are incredibly powerful and a productivity multiplier. For the team I am in, Infra, it's many times distraction and a negative multiplier. I can't say how many times the LLM-proposed solution to a jittery behavior is adding retries. At this point we have to be even more careful with controlling the implementation of things in the hot p…
My colleague recently shipped a "bug fix" that addresses a race condition by adding a 200ms delay somewhere, almost completely coded by LLM. LLM even suggests that "if this is not good enough, increase it to 300ms". That says something about how much some people care about this.
Even doubly so because that's how most people have solved a similar problem, so that the LLM suggests that
Re: The 100 hour gap between a vibecoded prototype and a working product
#263[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.
- version 1 -- we build what we think is needed
- version 2 -- we realise we're solving a completely different problem to what is needed
- version 3 -- we build what is actually needed
Re: The 100 hour gap between a vibecoded prototype and a working product
#264I 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 would say that if AI has to make decisions about picking between framework or constructs irrelevant to the domain at hand, it feels to me like you are not using the AI correctly.
Re: The 100 hour gap between a vibecoded prototype and a working product
#265Earlier quoted context omitted.
Try something like: > Please carefully review (whatever it is) and list out the parts that have the most risk and uncertainty. Also, for each major claim or assumption can you list a few questions that come to mind? Rank those questions and ambiguities as: minor, moderate, or critical. > Afterwards, review the (plan / design / document / implementation) again thoroughly under this new light and present your analysis…
Ok! I will try that, thank you very much.
Of course! I get pretty lazy so my follow-up is often usually something like:
"Ok let's look at these issues 1 at a time. Can you walk me through each one and help me think through how to address it"
And then it will usually give a few options for what to do for each one as well as a recommendation. The recommendation is often fairly decent, in which case I can just say "sounds good". Or maybe provide a small bit of color like: "sounds good but make sure to consider X".
Often we will have a side discussion about that particular issue until I'm satisfied. This happen more when I'm doing design / architectural / planning sessions with the AI. It can be as short or as long as it needs. And then we move on to the next one.
My main goal with these strategies is to help the AI get the relevant knowledge and expertise from my brain with as little effort as possible on my part. :D
A few other tactics:
- You can address multiple at once: "Item 3, 4, and 7 sound good, but lets work through the others together."
- Defer a discussion or issue until later: "Let's come back to item 2 or possibly save for that for a later session".
- Save the review notes / analysis / design sketch to a markdown doc to use in a future session. Or just as a reference to remember why something was done a certain way when I'm coming back to it. Can be useful to give to the AI for future related work as well.
- Send the content to a sub-agent for a detailed review and then discuss with the main agent.
Re: The 100 hour gap between a vibecoded prototype and a working product
#266100 hours try 500 hours at least if you want a competitive product, unless you are a wizard at marketing where you out market the 80/20 guys.
Re: The 100 hour gap between a vibecoded prototype and a working product
#267Earlier quoted context omitted.
I have friends (well, friends of friends) who still play the NFT lottery. People love gambling lol
I thought everyone realized by now that a digital image made available via block chain or any other mechanism, can be duplicated indefinitely. The only thing you get is a copyright on some generated image or set of bits. And what are the chances any random digital image is going to be appreciated as art? You can't hang it in a living room or sit it on a coffee table. It's beanie babies, but without even a hill of bea…
Isn't the same true of any intellectual property?
A movie can be duplicated indefinitely. There's no guarantee your song will be appreciated as art. I'm not sure why you say you can't print out an image and hang it in your living room; we do that all the time at home.
I've personally never dabbled in NFTs, but I don't think it's fair to ascribe the inherent conflict between information and scarcity uniquely to them.
Re: The 100 hour gap between a vibecoded prototype and a working product
#268Earlier quoted context omitted.
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...
“Day 7" would be amazing - all that I see YouTube recommending is "I tried it for 24 hours"
I was listening to an "expert" on a podcast earlier today up until the point where the interviewer asked how long his amazing new vibe-coded tooling has been in production, and the self-proclaimed expert replied "actually we have an all-hands meeting later today so I can brief the team and we will then start using the output..."
Re: The 100 hour gap between a vibecoded prototype and a working product
#269Earlier quoted context omitted.
I personally know of an HFT firm that used Java approximately a decade ago. My guess would be they're still using it today given Java performance has only improved since then.
it doesn't mean Java is optimal or close to optimal choice. Amount of extra effort they do to achieve goals could be significant.
Optimal in what sense? In the java shops I've worked at it's usually viewed as a pretty optimal situation to have everything in one language. This makes code reuse, packaging, deployment, etc much simpler.
In terms of speed, memory usage, runtime characteristics... sure there are better options. But if java is good enough, or can be made good enough by writing the code correctly, why add another toolchain?
Re: The 100 hour gap between a vibecoded prototype and a working product
#270Earlier quoted context omitted.
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 repla…
I agree with your general point but ... "Where are the vibecoded AAA games". A game dev team is typically less than 15% programmers. Most of the team are artists, followed by game designers. Maybe someday those will be replaced too but at the moment, while you can get some interesting pictures from stable-diffusion techniques it's unlikely to make a cohesive game and even prompting to create all of it would still take many person years.
That said, I have had some good experiences getting a few features from zero to working via LLMs and it's helped me find lots of bugs far easier than my own looking.
I can imagine a vibe coded todo app. I can also kind of imagine a vibe coded gIMP/Photoshop though it would still take several person years, prompting through each and every feature.