Easy, I made the switch in my 30s, now I manage software engineers :)

I think you need to read the studies linked in the footnotes. This is a well-studied issued.

You're misrepresenting the potential problem. It's more along the lines of using AI stops you exercising the cognitive processes you would doing things yourself and those encompass skills, knowledge and brain function that can atrophy. For an extreme example you can look at cognitive decline in the elderly which can be mitigated by taking part in activities that are cognitively stimulating.

Pretty much every study says so, so I guess?

You can definitely feel it when you talk against an AI vs doing the churn yourself. It's comfortable, simple, it doesn't aggravate you.

If you constantly pawn a task or cognitive load onto someone else (AI or not), you'll eventually get worse and worse at that particular type of thinking. Your overall mind doesn't necessarily get weaker, but you definitely start to get worse at anything you don't regularly practice.

Why do people think there will be fixing AI slop software? I see that opinion here and there on HN. The cost of codegen is next to nothing. It makes no sense to spend large sums of money having an engineer fix something that could be generated over and over until gods of stochasticity come in your favour.

We've entered a period of single-use-plastic software, piling up and polluting everything, because it's cheaper than the alternative

The problem partially is that AI can also fix AI slop. At this point I am in doubt whether code quality matters anymore in most non-critical software. You can ask an LLM if the code has quality issues and refactor to a _better_ version. It will reason through, prepare a plan and refactor. So now with this "better" code you can expect that your LLM will be able to deliver higher quality results but that's all the quality that is needed.

Actually, at this point I feel that the value in software engineering is moving from coding to testing and quality assurance.

Software engineering isn't a tool, it's the task.

> No carpenter is a specialist in drills.

There's no category difference between being an expert in carpentry vs masonry and being an expert in drills vs hammers. They are both just areas of expertise.

Going down the path of trying to define what is expert functions and what is "merely" a tool using anything but descriptive technique is nonsense.

Expert functions are just those areas where using a tool is sufficiently difficult to require expertise.

I kind of disagree. You are describing a kind person who is extremely valuable, a person who is proficient in SWE but also has domain specific skills in some niche.

That's great, but its nowhere near the norm, and people have been doing generalist software engineering for decades. There has been a sufficient amount of work for a long time to be performed by generalists that it has been a very reasonable career.

IMO AI is the first thing that has ever actually challenged that.

Software is wood, not drills, and if we somehow invented bacteria that gradually built an ugly but saleable house when fed on water and nutrients and nudged into shape, I bet carpenters (well, framers or whatever they're called in the US) would have an identity crisis too.

It most certainly was a lifelong career.

I’m kind of confused how you might think it wasn’t. Going through a career as a software dev until retirement was very common.

Software engineers didn’t just disappear after age 40.

I think the logical next step is that "XYZ knowledge worker" will become a software engineer of sorts. Not literally writing code, but at minimum encoding processes/workflows into some language.

If you're a paralegal or an accountant who can't manage their workflows with AI, you're going to be way less productive than someone who can.

And if you're a paralegal or an accountant who can manage a lot of your workflows with AI, you don't need custom software (hence less dedicated software engineers).

Id disagree with this analogy: "No carpenter is a specialist in drills." and i think its an interesting lens through which to look at the evolution of our tools.

I think there are trades where tool (or process if i may be allowed to extend the analogy) specialists exist and are highly valued. My dad is a plumber, so ill use that example but id trust similar is true for carpentry. there are specialists by task/output (new construction, repairs, boilers etc) but also tool specialist plumbers and companies for example drain clearing equipment or certain kinds of pipe for handling chemicals other than water are very specialised, and there are roles for them because the thing they enable, and the criticality of the task, and often the cost and complexity of using the tool are high enough to make specialisation valuable.

IMO software has, for the 10 years ive been working in it, been in an unusual position where the tools (languages, engineering practices, tech stacks) were super technical and involved, but also could be applied to a large number of problems. That is the perfect recipe for tool specialists: complex tool with high value and broad domain/problem space applicability.

Because of that tool specialisation, we've separated the application of the tool to a problem/domain from the tool use. reduction of complexity of applying these tools to many problems, means all domain specialists will use them, relying less on tool specialists.

imaging a mcguffin tool for attaching any two materials together, but which took a degree to figure out (loose hyperbole here), that sudenly you could use for 5 bucks and a quick glance at the first page of the manual. An industry that used to have lots of mcguffin engineers, would be mega disrupted, and you could argue that those tool specialists would have to identify more with what they were building than the mcguffin they were using.

why is the LLM-compiler analogy flawed? Is it only because LLM output is non deterministic?

My concern would be whether creating that software pays enough to keep up with skyrocketing costs of living. In the past, the jobs created by automation have generally been lower paid with less autonomy.

> However, I never read what those careers are or who is going to pay for retraining.

There aren't any careers and if there were, you would have to pay. Corporations certainly won't except under extremely rare situations where they have to to compete.

The same is true of the industries that software disrupted.

If AI becomes good enough to easily produce maintainable and high quality software, then I really can't see how demand for software engineers would not plummet. Even lots of non-coding work that software engineers do, such as accurately capturing what client actually wants, will become much less valuable - e.g. currently misunderstanding of client's requirements is catastrophic and can lead to waste of months of labour; with AI it could become matter of max few hours lost. So I can understand argument that software engineering careers might be safe because AI may plateau and we might never reach level where it's actually capable of producing good software. But I absolutely don't buy that software engineering will be safe even if such AI exists. Even if your current work is just 20% actually coding, you must remember about second order effects that will take place once quality code generation is 1000 times faster.