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

351–360 of 362 posts

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

#351

Post by swixisagrifter »

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…

| You're not doing the "hard 20%." You're paying interest on...

Ok clanker

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

#353

Post by j45 »

jacquesm wrote: post #89
matt_heimer wrote: post #45

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…

AI is extremely good at the things that it has many examples for. If what you are doing is novel then it is much less of a help, and it is far more likely to start hallucinating because 'I don't know' is not in the vocabulary of any AI.

I don’t know can be added to the vocabulary depending on the technique being used.

There are so many overlapping and also unique approaches to software development beyond vibe coding and ai driven software development.

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

#354

Post by j45 »

riffraff wrote: post #92
mtrovo wrote: post #56

Earlier quoted context omitted.

I think the main issue is treating LLM as a unrestrained black box, there's a reason nobody outside tech trust so blindly on LLMs. The only way to make LLMs useful for now is to restrain their hallucinations as much as possible with evals, and these evals need to be very clear about what are the goal you're optimizing for. See karpathy's work on the autoresearch agent and how it carry experiments, it might be useful…

> 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.

There’s a possibility the same people might believe anything they read on social media or via Google and it’s something worthy of attention.

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

#356

Post by bmurphy1976 »

sevenseacat wrote: post #337
bmurphy1976 wrote: post #322

Earlier quoted context omitted.

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

Except when you've worked on building the software yourself instead of getting the LLM to do it, you have a loooooooot of built-up context that you can use to know why decisions were made, to debug faster, and to get things done more efficiently. I can look at code I wrote years ago and have absolutely no memory of writing it, but I know its my code and I know where some of the warts and traps are. I can answer quest…

Agreed but that's also a documentation problem. Every time I have to make a tricky decision that I know will trip me up later or some kind of compromise, I now ask the AI to document it and the reasons why. That information has definitely come in handy later and serves as a form of long-term memory.

Best part, it's good for people too.

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

#357

Post by sieste »

kaffekaka wrote: post #333
sieste wrote: post #260

Earlier quoted context omitted.

yes. claude added a suggested random scramble (if that's what you mean?), also running average of 5/12/100, local storage of past times on first iteration, my son told it to also add a button for +2s penalties and touch screen support.

Ok cool! I have not done any cubing related coding so I don't know how complicated it gets but making sure suggested scrambles are solvable etc seems like it could be non-trivial?

You just get a sequence of random moves to go from solved to scrambled, it's quite trivial.

See here if you're interested: stefansiegert.net/cube-timer

Let me know if you adapt it in any way, my son would be delighted to see open source work its magic :)

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

#358

Post by Gareth321 »

qsera wrote: post #327
Gareth321 wrote: post #284

Earlier quoted context omitted.

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?

The same place all creative reference comes from: someone or something else. We have a nearly unlimited well of creative and technical reference now.

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

#360

Post by kaffekaka »

sieste wrote: post #357
kaffekaka wrote: post #333

Earlier quoted context omitted.

Ok cool! I have not done any cubing related coding so I don't know how complicated it gets but making sure suggested scrambles are solvable etc seems like it could be non-trivial?

You just get a sequence of random moves to go from solved to scrambled, it's quite trivial. See here if you're interested: stefansiegert.net/cube-timer Let me know if you adapt it in any way, my son would be delighted to see open source work its magic :)

Ah of course, thank you. Defining the moves to get to the scramble makes sure it is solvable.
Post reply on HN