We treat software engineering as its own practice, with all its ways of doing things and all its overhead. It's easy to forget that software is just a means to a much greater thing. Writing software for the sake of software was never really the end goal.
Building software is basically a loop. You write some code and deploy it. You watch what happens: the metrics, the logs, what people actually do with it. You analyze what you saw and decide what to do next. Then you write code again.
The loop doesn't really start anywhere. You just have to begin working on it somewhere and keep going around, and each time the product gets a bit closer to what customers need.
That's why I think obsessing over writing code is a really bad way to think about where the value is. For a business, the value is this iteration, and the goal of it is to provide value to customers. If developers are only meant to write code, they're only looking at one stop out of five.
Every stop has its job titles: software engineer, DevOps, data scientist, analyst, product owner, business analyst. They are different people only because there is so much to do in each of those areas. Nothing about the work itself says one person can't understand all of it.
I tend to view myself as a generalist. I specialize in writing code, yes, but I've also done DevOps work and taught DevOps courses. I'm basically a lead, so I also work with stakeholders, figure out what's worth building, scope it down to something we can actually deliver, make sure the running application just works, and get things out of the analytics.
I really like to understand why things work the way they do and how else they could work. I see something work one way, then I go into a different project or a different area and wonder if we can apply it there, or if there's something we can borrow.
You've probably seen those charts with skills around a circle, where the further a shape reaches in one direction, the better you are at that thing. Put the five stops of the loop on one. A specialist is a long spike toward writing code. A generalist is a small round shape, someone who knows something about every stop and not a lot about any of them.
AI is what changes this for me. If you understand a stop, you can now hand off a lot of the work there to AI and check what comes back. You can delegate the code. You can ask an agent to look at the usage patterns and find you something. So the small round shape gets a lot bigger.
My guess is about eight out of ten on every stop. It doesn't get to ten, and maybe one person won't do it as well as dedicated people would. But a single person can now cover really a lot of ground. You still have to understand what you hand off, though. Someone has to look at the graph and know what it means.
This only works if we keep things simple. By simple I mean understandable, and by understandable I mean that things follow a certain reasoning, a certain philosophy. Then you can keep them in your head when you move from one stop to the next. I wrote about getting to this point in a year of building, then unbuilding: I want software where I can see what's going on and the file in front of me says what it does.
Yes, computers and programming and AI itself are interesting. But it was never about them being the center of it all. They're just tools, and we should treat them as tools.