Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The next two years of software engineering

addyosmani.com

Post reply on HN
Print view View original

131–140 of 403 posts

Re: The next two years of software engineering

#131

Post by Chris2048 »

latexr wrote: post #120
Chris2048 wrote: post #105

Earlier quoted context omitted.

I'd assume the straw-man isn't that vibe-coding (vbc) doesn't exist, but that all/most ai-dev is vbc, or that it's ok to derail any discussion on ai-assisted dev with complaints applicable only/mainly to vbc.

Neither of those would be a strawman, though. One would be a faulty generalization and the other is airing a grievance (could maybe be a bad faith argument?). https://en.wikipedia.org/wiki/Faulty_generalization Though I get that these days people tend to use “strawman” for anything they see as a bad argument, so you could be right in your assessment. Would be nice to have clarification on what they mean.

Hmm, if the purpose of either is so an "easier" target can be made, I think it could still qualify as a straw-man; I think an accusation of straw-manning is in part a accusation of another's intent (or bad faith - not engaging with the argument).

Re: The next two years of software engineering

#132

Post by cowl »

globular-toast wrote: post #78

This article suggests it is specialists who are "at risk", but as much more of a generalist I was thinking the opposite and starting to regret not specialising more. My value so far in my career has been my very broad knowledge of basically the entire of computer science, IT, engineering, science, mathematics, and even beyond. Basically, I read a lot, at least 10x more than most people it seems. I was starting to won…

LLMs have read EVERYTHING yes. that includes a lot of not optimal solutions, repeating mantras about past best practices that are not relevant anymore, thousands of blog posts about how to draw an owl by drawing two circles and leaving the rest as an exercise to the reader etc.

The value of a good engineer is his current-context judgment. Something that LLMs can not do Well.

Second point, something that is being mentioned occasionally but not discussed seriously enough, is that the Dead Internet Theory is becoming a reality. The amount of good, professionally written training materials is by now exhausted and LLMs will start to feed on their own slop. See How little the LLM's core competency increased in the last year even with the big expansion of their parameters.

Babysitting LLM's output will be the big thing in the next two years.

Re: The next two years of software engineering

#133

Post by iknowSFR »

miki123211 wrote: post #82
Aurornis wrote: post #25

Earlier quoted context omitted.

> My experience hasn't been LLMs automate coding, just speeds it up. This is how basically everyone I know actually uses LLMs. The whole story about vibecoding and LLMs replacing engineers has become a huge distraction from the really useful discussions to be had. It’s almost impossible to discuss LLMs on HN because everyone is busy attacking the vibecoding strawman all the time.

As a professional programmer, I think both are useful in different scenarios. You're maintaining a large, professional codebase? You definitely shouldn't be vibe coding. The fact that some people are is a genuine problem. You want a simple app that you and your friends will use for a few weeks and throw away? Sure, you can probably vibe code something in 2 hours instead of paying for a SaaS. Both have their place.

I’m seeing vibe coding redefine what the product manager is doing. Specifically, adding solution execution to its existing strategy and decision making responsibilities. The PM puts solutions in front of a customer and sees what sticks, then hands over the concept to engineering to bake into the larger code base. The primary change here is no longer relying on interviews and research to make product decisions that engineering spends months building only to have flop when it hits market. The PM is being required to build and test dozens of solutions before anything makes its way to engineering resources. How engineering builds the overall solution is still under their control but the fit is validated before it hits their desk.

Re: The next two years of software engineering

#134

Post by thw_9a83c »

misja111 wrote: post #125

> Senior developers: Fewer juniors means more grunt work landing on your plate I'm not sure I agree with that. Right now as a senior my task involves reviewing code from juniors; replace juniors with AI and it means reviewing code from AI. More or less the same thing.

> More or less the same thing.

Worse. The AI doesn't share any responsibility.

Re: The next two years of software engineering

#135

Post by torben-friis »

osigurdson wrote: post #41

>> The skillset is shifting from implementing algorithms to knowing how to ask the AI the right questions and verify its output. The question is, how much faster is verification only vs writing the code by hand? You gain a lot of understanding when you write the code yourself, and understanding is a prerequisite for verification. The idea seems to be a quick review is all that should be needed "LGTM". That's fine as…

And there's a ton of human incentives here to take shortcuts in the review part. The process almost pushes you to drop your guard: you spend less physical time observing the code while you write, you get huge chunks of code dropped on you, iterations change a lot to keep a mind model, there's FOMO involved about the speed gain you're supposed to get... We're going to see worse review quality just by a mater of UX and friction of the tool.

Re: The next two years of software engineering

#136

Post by cppluajs »

thfuran wrote: post #122
falloutx wrote: post #91

Earlier quoted context omitted.

What a benevolent bossman here, keeping 50% of the jockeys around this quarter. He is probably sacrificing one of his yachts for this.

He’s keeping some around so he can fire half again next quarter for another bonus. That’s the sort of forward-thinking strategic direction that made him the boss man.

So log(N) times the bonus. Very smart boss here.

Re: The next two years of software engineering

#137

Post by haspok »

danieltanfh95 wrote: post #76

The most useful thing juniors can do now is use AI to rapidly get up to the speed with the new skill floor. Learn like crazy. Self learning is empowered by AI. Engineers > developers > coders.

That is quite some wishful thinking there. Most juniors won't care, just vibe-code their way through.

It takes extra discipline and willpower to force yourself do the painful thing, if there is a less painful way to do it.

Re: The next two years of software engineering

#138

Post by Eupolemos »

Jean-Papoulos wrote: post #112

>The flip scenario: AI unlocks massive demand for developers across every industry, not just tech. Healthcare, agriculture, manufacturing, and finance all start embedding software and automation. I find this one hard to believe. Software is already massively present in all these industries and has already replaced jobs. The last step is complete automation (ie drone tractors that can load up at a hub, go to the field…

I think there's a good chance demand goes up in Europe.

We are going to need to de-risk our software dependencies, and Germany is going to need to use computers.

Germany is going to be crazy, I think.

Re: The next two years of software engineering

#139

Post by therealpygon »

noufalibrahim wrote: post #73
trueismywork wrote: post #64

Earlier quoted context omitted.

You can think of LLMs as a higher level language for whatever programming language you are using, but informal with ambiguous grammar.

I don't think that works. The fact that it can produce different output for the same input, usage of tools etc. don't really fit into the analogy or mental model. What has worked for me is treating it like an enthusiastic intern with his foot always on the accelerator pedal. I need to steer and manage the brakes otherwise, it'll code itself off a cliff and take my software with it. The most workable thing is a pair p…

I feel like some of the frontier models are approaching run-of-the-mill engineer who does dumb stuff frequently. That said, with appropriate harnessing, it’s more like go-karts on a track; you can’t keep them out of the wall, but you can reset them and get them back on a path (when needed). Not every kart ends up in the wall, but all of them want to go fast, so the better defined the track is the more likely the karts will find a finish line. Certainly more likely than if you just stuck them in a field with no finish line and said “go!”.

Re: The next two years of software engineering

#140

Post by torben-friis »

danieltanfh95 wrote: post #76

The most useful thing juniors can do now is use AI to rapidly get up to the speed with the new skill floor. Learn like crazy. Self learning is empowered by AI. Engineers > developers > coders.

AI has a lot of potential as a personal, always on teaching assistant.

It's also an 'skip intro' button for the friction that comes with learning.

You're getting a bug? just ask the thing rather than spending time figuring it out. You don't know how to start a project from scratch? ask for scaffolding. Your first boss asks for a ticket? Better not to screw up, hand it to the machine just to be safe.

If those temptations are avoided you can progress, but I'm not sure that lots of people will succeed. Furthermore, will people be afforded that space to be slow, when their colleagues are going at 5x?

Modern life offers little hope. We're all using uber eats to avoid the friction of cooking, tinder to avoid the awkwardness of a club, and so on. Frictionless tends to win.

Post reply on HN