You are hitting the nail on the head. We are not being hired to write code. We are being hired to solve problems. Code is simply the medium.
Most are not paid for results, they're paid for time at desk and regular responsibilities such as making commits, delivering status updates, code reviews, etc. - the daily activities of work are monitored more closely than the output. Most ESOP grant such little equity that working harder could never observably drive an increase in its value. Getting a project done faster just means another project to begin sooner.
Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated.
Wow. I've read a lot of hacker news this past decade, but I've never seen this articulated so well before. You really lifted the veil for me here. I see this everywhere, people thinking the work is the point, but I haven't been able to crystallize my thoughts about it like you did just now.
Im on the side of only enjoy coding to solve problems and i skipped software engineering and coding for work explicitly because i did not want to participate in that dynamic of being removed from the problems. instead i went into business analytics, and now that AI is gaining traction I am able to do more of what I love - improving processes and automation - without ever really needing to "pay dues" doing grunt work I never cared to be skilled at in the first place unless it was necessary.
This gets us to the rule number one of being successful at a job: Make sure your manager likes you. Get 8 layers of people whose priority is just to be sure their manager likes them, and what is getting done is very unlikely to have much to do with shareholder value, customer happiness, or anything like that.
Sometimes you can, sometimes you have to break the problem apart and get the LLM to do each bit separately, sometimes the LLM goes funny and you need to solve it yourself.
Customers don't want you wasting money doing by hand what can be automated, nor do they want you ripping them off by blindly handing over unchecked LLM output when it can't be automated.
If enough people can make the product faster, then competition will drive the price down. But the ability to charge less is not at all an obligation to charge less.
If the experienced engineer is already faster than the LLM, their job is not at risk.
If the LLM is faster then the experienced engineer at making some kind of code product, then the experienced engineer can use it to save time. And in the short term they can spend even more time learning! Maybe it's a net negative because it helps the "new class of devs that just want the easy way out" more, but it's still helping the experienced engineer.
And if increased competition drops the price then the LLM's influence is helping customers.
- a market needs a certain kind of product (feature set, complexity, performance)
- good engineer could apply skills to deliver that
- lazy engineers couldn't, but with llm they can, it gives them solutions without understanding much, which is irrelevant for them, they want to ship
- i myself don't enjoy having code spilled out for me, and the time savings from llm won't bring much more joy (unlike the lazy engineer who is happy)
- a llm might help me do more advanced things but the market might not care for it. say the average user wants a dashboard with a bunch of data points and a few actions. the llm answer will match that perfectly. I could ask the llm to produce a more complex dashboard with more customization, more feature.. but the user will not want it because it's beyond its needs
so yeah it's a matter of ratio, it seems that lazy devs will get a 10x improvement while a skilled one will only get 1.5 and might be squeezed out of the market
ultimately i wonder how long people will need devs at all if you can all prompt your wishes
some will be kept to fix the occasional hallucination and that's it