Software Engineering is dead, long live Software Engineering

Everything has changed - so where do we go from here?

Software Engineering has had a wild ride the last couple of months. The whole industry has declared that things are changing completely - from companies laying off engineers claiming they will be replaced with AI, junior developer roles disappearing, and plenty of hyperbole about the benefits and dangers of LLMs. Underlying all the panic, hyperbole, and excitement is a fundamental truth - things are changing. Things are changing fast.

However, I think only one part of Software Engineering has actually been handed off to AI. It's the part we engineers spent most of our time doing - writing code - but all of the other parts still require us humans. Those parts will have to change to keep up, but the good news for us engineers is that they matter more than ever. So what does it mean to do Software Engineering now? If we don't write code, what do we spend our time doing? How do we continue to build things (and hopefully enjoy it)?

From building to architecting

Software Engineering has always had a career progression from builder to architect. Now that coding agents do most of the building, more of our time will go into how an application is organized. Agents can write code quickly, but left alone they fall into the same traps we do: pull requests get massive, changing one feature breaks another, and the system gets harder to understand. Keeping an application organized is still up to us. That means thinking about an application as a set of parts, catching when changes drift from that structure, and writing linting tools so agents can catch it themselves. It also means thinking hard about how our systems interoperate and expose themselves to the world.

The good news is that none of this is new. The books and blog posts on application design still apply, and coding agents know the common patterns too. If you work with an agent to apply one, it can help you tell whether you're getting it right. Be careful, though: if the agent suggests a direction, make sure you understand it well, including both the pros and the cons.

Discovery, triage, and research

I've put these three subjects together because they follow the same high level pattern: Identify a problem (a bug, a new feature, or an unknown topic), propose possible solutions, and then assess the viability of the solutions. This general "problem solving" skill will continue to be highly important to engineers. I know for myself this is the fun part of software - it's a puzzle that needs solving.

Agents can help us identify solutions to problems or their viability, but at the end of the day we humans have to decide what problem we're trying to solve, and how closely the solution fits into what we actually need. We humans are notoriously bad at defining problems completely and accurately, so it's up to us engineers to make the ultimate call on whether a solution solves the problem we've been working on (vs perhaps what we initially thought the problem was).

Directing agents

Coding agents are great at writing code and working through a specific set of problems. They can build plans and complete them. But ultimately organizations need people to coordinate that work - what gets done when, how we measure success, and the quality of the output are all up to humans. Software engineers are a natural fit for this role - they already have a sense of what quality output looks like, they know when to say work is done, and they know how to organize the work so that it's deployed to customers in the correct order. Software engineers will need to employ more management skills to direct their agents than they may currently, but those management skills are more about coordinating systems than they are about traditional management work.

Agents don't need training, they need skills, linters, or documentation. Agents don't need meetings to define work, they need an understanding of where their work starts and stops within the process, and what other agents will complete before and after them.

Reviewing software

Coding agents can write code really fast. In order for us humans to keep up with what is happening in an application we will need to fundamentally change how we review that work. I expect a whole new set of tools and services to arise around this particular part of the agentic coding era, but for now we humans need to know two things: which parts of the project agents are trustworthy on, and how to review the parts they are weak on.

We will need to learn how to review code at the macro level instead of the micro level. This will mean looking at function signatures, interfaces, models, and the interconnection of these components, rather than the individual lines of syntax. Unlike architecture, there isn't a shelf of books to lean on here yet, which is why I think this will prove one of the most challenging parts of the process in the short term.

Long live Software Engineering

Software Engineering isn't going anywhere, but how we do it is already changing. Over the next few posts I want to define how we keep doing Software Engineering in this new era: what is the same, what is different but similar, and what is or will be completely new. I'll also cover some of the challenges that are starting to take shape as we use coding agents more and more.

I'll dig into this puzzle and figure out how to start putting the pieces together in the next post, where I look at what it means to architect software for coding agents.