Software engineering is dead. Today this was the hot topic on X. I think the hot takes on this topic are getting hotter day by day, thanks to the advancements of the AI models and the harnesses supporting them. To be fair, it’s something I have also been thinking about for a while. As I see most of my work getting automated by agents, I sometimes feel like I am catching up rather than steering the workflow. It’s very scary. Not the catching-up part, but the fact that there is no going back.
Is software engineering actually dead? In a broad sense, if you ask me, NO. A big no. First, let’s try to understand what someone who hears this will think. There can be a few interpretations, all valid. “Going ahead, no more new software will be produced.” “Humans will stop writing new kinds of software by hand.” “No one will pay for software anymore.” “Original software will now behave like an OEM (original equipment manufacturer): it will be made by a few highly specialised individuals in a few select places.” “Software is just a tool for agents now, used and discarded when the job is done. New job, new temporary software.” “Software subscriptions are dead.” “People will have personal software for everything; software mass production is dead”…
The list goes on, but you get the idea.
What is dead, according to me, is the way we used to build software. And that’s completely normal. It’s almost cyclical. Think of how, every few decades, there are cycles of mass disruption in different aspects of human life and nature. Software development is no different. What each transformation has brought to software development, if I have to oversimplify, is a new layer of abstraction for engineers, so that they can focus on more important stuff. It was the same when we moved from plugboards and patch cables to assembly, from assembly to a low-level language like C, and then to more business-oriented languages like Java and Python. The layer of abstraction added a much-needed break from worrying about things that usually didn’t matter to people who were trying to build something on top of the layer, but had to worry about the quirks of the current layer.
And if we follow the above trail of thought, then all the above doomer scenarios are true. Nobody pays for an assembler or a compiler anymore. Nobody pays for a C memory manager anymore.
Nobody pays for the layer that got abstracted anymore.
- Very few people in the world still write and maintain it.
- For most applications, there are APIs and interfaces that just use those layers as tools, temporarily, to execute something and then forget about it.
- They now mostly ship with the original manufacturer (read: the software enterprise) that you buy from.
- The buyer or the user of the application running on top of that abstraction doesn’t maintain it or worry about it by hand. The tools sitting between their application and the layer deal with it.
People still pay for the software that solves their problem.
Welcome to the new world, where writing human-understandable and machine-compilable end-to-end software, with a front end, back end, database, API and domain, is now abstracted.
This means all the players in the software business (big, small, indie, OSS) are now free from things like “legacy code”, “clean code”, “maintainability”, “migrations”, “support ticket priorities”, “task queues”, “PRDs/FRDs” and “design specs”.
Free doesn’t mean you don’t need them. You still do. You just don’t have to worry about them. Worry, as in wasting your time perfecting them. The business requirement is plain English. But the expertise to translate it into an actual use case is still needed. You still need to know what is going on behind the scenes. At least for the layer that is just below your application. Just like how C programmers still have to worry about memory management. The agents can produce the required outputs for you. The outcomes are owned by you. The abstraction layer does not absolve you of that. The outputs move fast, and sure, you can feel like an imposter trying to catch up. But that’s great: you either get to learn new things, or you ask it to dumb it down.
And what each layer of abstraction has taught us from the past is that the possibilities it opens are endless. And the software engineering market only increases. The roles change, but we still need dependable people to build great things. We now have another tool available in our arsenal to help us.
Source: US Bureau of Economic Analysis, private fixed investment in software, via FRED. Current dollars.
Source: US Bureau of Labor Statistics, Occupational Employment and Wage Statistics, national estimates for May of each year. Software developers are applications plus systems software; 2019 and 2020 are left out because those years’ codes counted developers together with QA testers. 2023 is the latest year included.
So when I say there is no going back, it means there is no going back to the output aspect of software development. The PRD doesn’t need to be perfect. It needs to be clear. The code doesn’t need to be a work of art. It should solve the problem, utilise resources effectively and be more or less bug-free, and that’s it. The artisans can now focus on the design and the choice of fabric and leave the weaving to machines. But they should still check that the quality is met.