Earlier quoted context omitted.
Yes. No agents, no deep research, no tools, and just Sonnet-3.5 and 3.7 - I’d love to see the same study today with Opus-4.6 and Codex-5.3
Probably 38% slower now...
Please don’t project. :)
Breaking the spell of vibe coding
191–200 of 375 posts
Re: Breaking the spell of vibe coding
#192Earlier quoted context omitted.
>must be so focused on the future They're focused no the short-term future, not the long-term future. So if everyone else adopts AI but you don't and the stock price suffers because of that (merely because of the "perception" that your company has fallen behind affecting market value), then that is an issue. There's no true long-term planning at play, otherwise you wouldn't have obvious copypcat behavior amongst CEOs…
Every company should have hired over the pandemic due to there being a higher EV than not hiring. It's like if someone offered an opportunity to pay $1000 for a 50% chance to make $8000, where the outcome is the same between everyone taking the offer. If you are maximizing for the long term everyone should take the offer even if it does result in a reality where everyone loses $1000.
Where did they get the notion that the EV of overhiring was high by any measure?
Re: Breaking the spell of vibe coding
#193I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…
[deleted]
Re: Breaking the spell of vibe coding
#194I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…
Even if you believe that many are too far on one side now, you have to account for the fact that AI will get better rapidly. If you're not using it now you may end up lacking preparation when it becomes more valuable
> If you're not using it now you may end up lacking preparation when it becomes more valuable
You think it's going to get harder to use as time goes on?
Re: Breaking the spell of vibe coding
#195Earlier quoted context omitted.
Or just wait for things to settle. As fast as the field is moving, staying ahead of the game is probably high investment with little return, as the things you spend a ton of time honing today may be obsolete tomorrow, or simply built into existing products with much lower learning cost. Note, if staying on the bleeding edge is what excites you, by all means do. I'm just saying for people who don't feel that urge, the…
Interesting - what makes you think things will slow down?
What makes you think they won’t? And even if they won’t, not wasting energy going through the churn is a winning strategy if eventually AI reads your mind to know what you want to do.
Re: Breaking the spell of vibe coding
#196Earlier quoted context omitted.
More specifically regarding spec-driven development: There's a good reason that most successful examples of those tools like openspec are to-do apps etc. As soon as the project grows to 'relevant' size of complexity, maintaining specs is just as hard as whatever other methodology offers. Also from my brief attempts - similar to human based coding, we actually do quite well with incomplete specs. So do agents, but the…
> if you nail everything down hard, the specs get unwieldy - large and overly detailed That's a rather short-sighted way of putting it. There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better. If it gets too large, work on splitting a self-contained subset of it to a separate document.
> There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better.
I disagree - the spec is more unwieldy, simply by the fact of using ambiguous language without even the benefit of a type checker or compiler to verify that the language has no ambiguities.
Re: Breaking the spell of vibe coding
#197Earlier quoted context omitted.
But as it gets better, it'll also get easier, be built into existing products you already use, etc. So I wouldn't worry too much about that aspect. If you enjoy tinkering, or really want to dive deep into fundamentals, that's one thing, but I wouldn't worry too much about "learning to use some tool", as fast as things are changing.
I don't think so. That's a good point but the capability has been outpacing people's ability to use it for a while and that will continue. Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses
> Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses
Is it, lol? Know any case where those “the best users of AI” get salary bumps or promotions? Outside of switching to the dedicated AI role that is? So far I see clowns doing triple the work for the same salary.
Re: Breaking the spell of vibe coding
#198Earlier quoted context omitted.
Nothing gets worse in computers. Name me one thing. And if the current output quality of LLM stays the same but speed goes up 1000, quality of the generated code can be higher.
Hot keys. Used to be, you could drive a program from the keyboard with hotkeys and macros. No mouse. The function keys did functions. You could drive the interface blindfolded, once you learned it. Speed is another one. Why does VSCode take so long to open? and use so much memory and CPU? it's got a lot of features for a text editor, but it's worse than vim/emacs in a lot of ways. Boot time. Understandability. A Z80…
> Wtf is a typescript.
A godsend.
> Native GUI libraries are so much better but we decided those aren't cool anymore.
Lolno.
Re: Breaking the spell of vibe coding
#199Earlier quoted context omitted.
Why should I worry about lacking preparation in the future? Why can't I just learn this as any other skill at any other time?
You'll be behind by a few months at least, and that could be anywhere from slightly harmful to devasting to your career
Lmao, this is your brain on brainrot LLM FOMO. Better not waste time on HN, you’re wasting precious minutes getting ahead of (imaginary) competition!
Re: Breaking the spell of vibe coding
#200Earlier quoted context omitted.
My gripe with "developer accepts bad code without reading it" is two fold. 1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved. 2. Where exactly…
"Where exactly is the skill to know good code from bad code supposed to come from?" Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Al…
bait used to be believable
(i.e. I don't think that's your honest opinion and you're just trolling)