I found all the themes interesting, but "the rigor has to go somewhere" and "the enterprise reality check" resonated.
I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.
When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.
Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)
If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.
Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.
One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.
I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.
When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.
Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)
If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.
Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.
One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.