Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.
I really disagree with this. I don’t think you can be a good software engineer without being a good product manager and a good architect.
Breaking the spell of vibe coding
91–100 of 375 posts
Re: Breaking the spell of vibe coding
#92Earlier quoted context omitted.
It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?
And if you can never catch up, how would someone new to the game ever be a meaningful player?
Re: Breaking the spell of vibe coding
#93I 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…
It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?
Oooh, let me dive in with an analogy:
Screwdriver.
Metal screws needed inventing first - they augment or replace dowels, nails, glue, "joints" (think tenon/dovetail etc), nuts and bolts and many more fixings. Early screws were simply slotted. PH (Philips cross head) and PZ (Pozidrive) came rather later.
All of these require quite a lot of wrist effort. If you have ever screwed a few 100 screws in a session then you know it is quite an effort.
Drill driver.
I'm not talking about one of those electric screw driver thingies but say a De W or Maq or whatever jobbies. They will have a Li-ion battery and have a chuck capable of holding something like a 10mm shank, round or hex. It'll have around 15 torque settings, two or three speed settings, drill and hammer drill settings. Usually you have two - one to drill and one to drive. I have one that will seriously wrench your wrist if you allow it to. You need to know how to use your legs or whatever to block the handle from spinning when the torque gets a bit much.
...
You can use a modern drill driver to deploy a small screw (PZ1, 2.5mm) to a PZ3 20+cm effort. It can also drill with a long auger bit or hammer drill up to around 20mm and 400mm deep. All jolly exciting.
I still use an "old school" screwdriver or twenty. There are times when you need to feel the screw (without deploying an inadvertent double entendre).
I do find the new search engines very useful. I will always put up with some mild hallucinations to avoid social.microsoft and nerd.linux.bollocks and the like.
Re: Breaking the spell of vibe coding
#94Earlier 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
Re: Breaking the spell of vibe coding
#95Earlier quoted context omitted.
Of those 3 DDD books - which did you find the most valuable?
Not GP, but the most impactful one I read was Learning DDD from O’Reilly https://www.amazon.com/Learning-Domain-Driven-Design-Alignin... It presents the main concepts like a good lecture and a more modern take than the blue book. Then you can read the blue book. But DDD should be taken as a philosophy rather than a pattern. Trying to follow it religiously tends to results in good software, but it’s very hard to nail…
Thanks for the recommendation!
Re: Breaking the spell of vibe coding
#96Earlier quoted context omitted.
> I think it all boils down to, which is higher risk, using AI too much, or using AI too little? This framing is exactly how lots of people in the industry are thinking about AI right now, but I think it's wrong. The way to adopt new science, new technology, new anything really, has always been that you validate it for small use cases, then expand usage from there. Test on mice, test in clinical trials, then go to ma…
Those of us working from the bottom, looking up, do tend to take the clinical progressive approach. Our focus is on the next ticket. My theory is that executives must be so focused on the future that they develop a (hopefully) rational FOMO. After all, missing some industry shaking phenomenon could mean death. If that FOMO is justified then they've saved the company. If it's not, then maybe the budget suffers but the…
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 such as pandemic overhiring.
Re: Breaking the spell of vibe coding
#97Earlier 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
Re: Breaking the spell of vibe coding
#98Earlier quoted context omitted.
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
That’s the comical understanding being pushed by management in software companies yes. The people who never actually use the tools themselves, but the concept of it. It’s the same AGI nonesense, but dumped down to something they think they can control.
Re: Breaking the spell of vibe coding
#99Earlier 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.
The baseline, out-of-the-box basic tool level will lift, but so will the more obscure esoteric high-level tools that the better programmers will learn to control, further separating themselves in ability from the people who wait for the lowest common denominator to do their job for them.
Until coding systems are truly at human-replacement level, I think I'd always prefer to hire an engineer with strong manual coding skills than one who specializes in vibe coding. It's far easier to teach AI tools to a good coder than to teach coding discipline to a vibe coder.
Re: Breaking the spell of vibe coding
#100Earlier quoted context omitted.
I mean, right now "bleeding edge" is an autonomous agents system that spends a million dollars making an unbelievably bad browser prototype in a week. Very high effort and the results are jibberish. By the time these sorts of things are actually reliable, they'll be productized single-click installer apps on your network server, with a simple web interface to manage them. If you just mean, "hey you should learn to us…
I mean that you should stay up to date and practiced on how to get the most out of models. Using harnesses like Claude code sure, but also knowing their strengths and weaknesses so you can learn when and how to delegate and take on more scope