221–230 of 312 posts
>OH SHIT you're right! We have duplicate mouse handling:
>HOLY SHIT. Let me analyze what's happening:
>HOLY SHIT. NOW I get it. We're calculating the SAME THING in TWO different places:
>You're absolutely right - I fucked up by removing the loading material completely. Looking at the diffs in shame, here's what needs to be fixed:
Earlier quoted context omitted.
LLMs don't just make it easy to accumulate code - they make it easy to throw code away and start again . This already enables taking a different approach to debuggability - if there's a bug and it can't be trivially solved, trash that bit of the code and write it again . It may not be broadly viable just yet, but it will be if the models keep getting cheaper and better. This is also implied in the idea of "vibe codin…
Sounds very maintainable and rigorously constructed
Earlier quoted context omitted.
Nah, the magic/promise of AI is that it has positive chance of getting there, so you can keep feeding it dollars until it eventually gets you the thing you want, and that it's still cheaper than having people do it the old-school way. We're not there yet, but I don't see anything preventing us from getting there in ~5 years. (Remember: 5 years ago, SOTA in this space was letting a genetic algorithm poke at an AST and…
And full self driving is always just 5 years away.
Earlier quoted context omitted.
I think probably people will also use LLMs to debug. At this point, I think you can consider vibe-coding with an LLM to be pretty equivalent to using a fairly junior developer with access to stack overflow. It's going to make a lot of mistakes, it's going to make a lot of questionable decisions. Sometimes it will be able to fix its mistakes, sometimes it will spin its wheels and never fix it. It may make a big ball o…
> I think probably people will also use LLMs to debug. I don’t have a link handy, but someone has already set up a service that’s “JS time travel debugger + LLM that knows how to use it” Pretty sure it was a Show HN recently.
Earlier quoted context omitted.
Open mind here. Spill more details please. We're the 9 good or was their dead weight. Could the 9 to 2 have been done without AI anyway (because less work to do).
They were good... probably a bit bloated. Without AI we could probably be 5 devs. With AI we can do it all in 1-2.
So why wouldn't you keep them? If you're able to produce even more with AI enabled engineers, why downsize? To me, it sounds like a startup's dream to be able to output more without increasing headcount.
Earlier quoted context omitted.
Vibe coding is 100% real. Or maybe we should call it code vibing when there is no coding ability. But I just taught 18 professionals with no coding ability to build functional software. Their minds were blown
Wait until they have to maintain, debug or secure that software. You’ll see things really blow at that point.
Moments ago just saw this ad at the front of HN-
https://www.ycombinator.com/companies/domu-technology-inc/jo...
I honestly am not sure if this ad is a joke. I assume not, which is hilarious. Put in you 12-16 hour days for hilariously bad pay, and your onboarding will be doing one of the most pathetic, deadbeat jobs possible which is making collection calls. And your "vibe coding" is to use voice agents to...make collection calls.
Must be pretty grim pickings if this trash is getting advertised on here.
Making the arguing that these tools have flaws seem like a losing battle. Soon those flaws will be fixed[1] and youll have to find new flaws to complain about. Eventually hopefully you'll realize that you just don't like feeling displaced. [1] it's unbelievable what a difference in quality 1 year made for chat gpt
Why are you so certain that flaws will be fixed? Seems like there is a giant leap between a machine spewing words based on probability and actual deep understanding of the code it's suppose to write
I'm also stricken by the superficiality of analysis like "oh it's just probabilities" from so many devs; might as well say "it's magnets".
I think the bigger "AI hype vs. Reality" gap is about the productivity numbers people casually throw around, like "10x as productive" or even 100x. For example, here are YC partners quoting a company in a batch claiming "100x speedup" in coding performance compared to the previous month: https://www.youtube.com/watch?v=IACHfKmZMr8&t=1837s You can tell this claim is false, because that level of productivity increase w…
To be fair if your benchmark is against demo day, at some point Amdahl's law kicks in regardless of how many multiples you have on engineering. Not sure if I believe the multiple of 10x or 100x anyway, but a better metric is “number of customer feedback loops” is a better metric than “can complete one (1) demo day in X time”. My (non YC) impression is that people are hitting more loops. Also multiples “up” versus “do…
Note that real engineers helps you come up with new features and test your product and all that and not just add code, adding code was never a bottleneck on just about any problem ever.
So Amdahl's law applies in terms of the time to add code, not in terms of engineers, they don't do the work of 100 engineers, at best they take 100x less time to add lines of code when they know what they wanna make. But that isn't particularly game changing, as adding code is not the hard or even time consuming part.