tl;dr if you think of yourself as an optimizer, not an implementer, you’ll likely be in demand for a long time. Your value is to discover and steer good outcomes for your customers (in partnership with your employer). The fact that it’s currently effective to do this by writing code will change over time, but that won’t matter to those with a knack for it.
Epistemic status: I’m old, and I’m an AGI skeptic. This is my 70% estimate, it could happen much faster than I think could affect more of life than I think, and could just blow up entirely in which case it doesn’t matter.
Well, most low-end jobs will change radically. This includes a lot of office work including “software engineer”. The skilled/high-end versions will remain very valuable. Those people who can actually solve problems and understand customer needs in enough detail to build software that works at the scale needed are going to be needed until the actual singularity (when NOBODY is needed).
The unpleasant truth of software engineering is that writing code isn’t the hard part. Many Staff and Principal engineers spend less than 20% of their time on code, and that mostly as a way to communicate with other engineers, along with benchmarking and prototyping, and proving out harebrained ideas. It’s not primarily writing production code for actual use. It’s more “understand the universe (of human interactions and customer needs) well enough to describe it in machine-level detail”.
Relatedly, in any large system, FAR more developer time goes into observability, monitoring, debugging, recovery, and edge-case identification than to the automatable part of “make it work”. Even here, LLMs are going to help a lot. I look forward to having on-demand dashboards and less-arcane outputs of profiling runs. But they don’t eliminate (and may even increase) the need for understanding and human-level modeling of complex systems.
I expect that some of the whitepapers, demos, and designs I write will include a fair bit of prompt engineering, and I’ll be able to include more trials and prototypes in my proposals. My beliefs about what our company should do will become less wrong, as I have better tools to test them. But my job really can’t be automated.
Note that this applies to the top ~20% of people who would become software engineers today. there are a LOT (too many, IMO) of people worldwide who think it’s about writing good code, or just implementing someone else’s spec and walking away. Those folks will need to either get more dedicated and open to the idea that they’re responsible for outcomes, not just “doing a job”, or find other things that computers can’t do.
tl;dr if you think of yourself as an optimizer, not an implementer, you’ll likely be in demand for a long time. Your value is to discover and steer good outcomes for your customers (in partnership with your employer). The fact that it’s currently effective to do this by writing code will change over time, but that won’t matter to those with a knack for it.
Epistemic status: I’m old, and I’m an AGI skeptic. This is my 70% estimate, it could happen much faster than I think could affect more of life than I think, and could just blow up entirely in which case it doesn’t matter.
Well, most low-end jobs will change radically. This includes a lot of office work including “software engineer”. The skilled/high-end versions will remain very valuable. Those people who can actually solve problems and understand customer needs in enough detail to build software that works at the scale needed are going to be needed until the actual singularity (when NOBODY is needed).
The unpleasant truth of software engineering is that writing code isn’t the hard part. Many Staff and Principal engineers spend less than 20% of their time on code, and that mostly as a way to communicate with other engineers, along with benchmarking and prototyping, and proving out harebrained ideas. It’s not primarily writing production code for actual use. It’s more “understand the universe (of human interactions and customer needs) well enough to describe it in machine-level detail”.
Relatedly, in any large system, FAR more developer time goes into observability, monitoring, debugging, recovery, and edge-case identification than to the automatable part of “make it work”. Even here, LLMs are going to help a lot. I look forward to having on-demand dashboards and less-arcane outputs of profiling runs. But they don’t eliminate (and may even increase) the need for understanding and human-level modeling of complex systems.
I expect that some of the whitepapers, demos, and designs I write will include a fair bit of prompt engineering, and I’ll be able to include more trials and prototypes in my proposals. My beliefs about what our company should do will become less wrong, as I have better tools to test them. But my job really can’t be automated.
Note that this applies to the top ~20% of people who would become software engineers today. there are a LOT (too many, IMO) of people worldwide who think it’s about writing good code, or just implementing someone else’s spec and walking away. Those folks will need to either get more dedicated and open to the idea that they’re responsible for outcomes, not just “doing a job”, or find other things that computers can’t do.