We haven't been software engineers for some time now

I have been working closely with agentic software development tooling for a little over a year now. Long enough to have my own view, not long enough to be cocky about it. In that time I have watched competent practitioners around me produce things they could not have produced before, at speeds that do not fit inside the mental model I brought to this work. I have also watched some of the most senior engineers I know struggle with this transition in ways that are not really about the tools. They are about something deeper, and I think I finally have a name for it.

Here is what I have come to believe, and I expect this will be uncomfortable to read because it has been uncomfortable to arrive at.

Most of us have not been doing software engineering. Not in the proper sense of the word, at least not most of the time. We have been doing something else under that title for the last thirty years, and the something else is what AI now does cheaply. The engineering part of the job — when we were actually doing engineering — was a smaller share than our titles suggested. For some of us it was almost none of the job. For some it was a meaningful slice. For very, very few of us was it the bulk of what we did.

I am implicating myself in this. I have spent years of my career doing work that I called engineering and that paid me as engineering, which I now think was something else. I am not standing outside this conclusion looking in at it. I am inside it. The reckoning is mine as much as it is anyone else’s.

What the job actually was

The thing we called software engineering bundled three different activities together under a single title. We didn’t notice the bundling because all three activities produced the same artifact: working code and we were paid for the artifact rather than for the activity.

The first activity was applying known patterns to produce business functionality. Features, screens, integrations, reports. The pattern was usually known. The work was applying the pattern to the specific situation. We brought judgment, but the judgment was about fit, not about novelty. This was the bulk of most of our days, even if we did not like to think of it that way.

The second activity was building substrate for other people’s pattern-application work. Internal libraries, deployment platforms, observability tools. This had more engineering character because we had to think about consumers we would not meet and failure modes we had to anticipate without being told. But most, if not all, of the substrate work was still pattern-application at a higher level. The platforms we built were variations on platforms others had built. The libraries solved problems that had been solved.

The third activity was actual engineering. Applying technology in novel ways. Building things that had not been built before. Working at the edge of what was possible and pushing past it. This is what engineer meant before our profession captured the word. This activity was present in our work. It just was not most of our work.

The bundle made sense at the time because the three activities looked identical from the outside. We all produced code. We all had the credentials. We all commanded similar compensation. The cost of producing working software was high enough that anyone who could do any of the three activities was scarce and valuable, and the profession treated us as interchangeable instances of the same role because that was the economically rational thing to do. I am not blaming anyone, including myself, for not seeing the distinction. The era did not let us see it.

I think the community has actually been trying to see it for a long time. Anyone who has been in this profession for more than a few years has read the posts, sat through the conference talks, or argued the threads about the difference between a coder and a developer and a software engineer. The arguments never resolved. People tried to draw the line based on credentials, on complexity, on formal training, on domain depth, and none of the lines held. We kept circling around something we could sense but could not quite name. I think what we were trying to name was this. The line between pattern-application and engineering was the line we were reaching for, and we could not reach it because the bundle made the line economically irrelevant. Everyone with the credentials got paid as an engineer regardless of which activity they were doing most of the time, so the boundary question was always theoretical and the debates never had stakes. They have stakes now. The transformation is making the boundary economically legible for the first time, which is why we can finally see what we were arguing about.

The era is over.

What AI actually changed

The thing AI changed is the cost of producing code from a specification. When that cost collapses, the first activity — pattern-application — loses its rationale as a specialized role. Anyone with judgment about the problem can now produce the artifact. The substrate work follows on a delay because it is pattern-application at a higher abstraction, but it follows.

The third activity — actual engineering — does not collapse. There is no pattern for the AI to apply because the work is novel. In even these cases, AI can be brought to bear as a scalable team of implementers to assist the software engineer in experimentation and expression of idea. The challenge is that the skill set of effectively leveraging agents to create software is not compatible with considering AI a tool to be wielded. In my previous post “The future of software engineering looks a lot like management”, I explored this topic in a little more depth.

So the bundle separates. The first two activities, which were most of what we did, move into a new pattern where the qualification is judgment about the problem rather than credentials in producing code. The third activity stands by itself as what it always was — a smaller, distinct role doing the work the word engineer originally pointed at.

This is the part that took me longest to accept, and I think it is the part that is hardest for most engineers I talk to. Most of what I was doing was not engineering. I was good at it. I took pride in it. It was real work that produced real value. But calling it engineering was a courtesy the era extended to anyone who could produce working software, and the era is no longer extending the courtesy.

What I think we actually are now

I think most of the people who currently hold software engineering titles are going to continue their careers as something other than software engineers. Not because the work disappears, but because the work was never really engineering and now we can see it. The work is still valuable. The people doing it are still valuable. The title was the part that was misaligned.

What we are becoming, most of us, is operators. The word does not yet have settled meaning and the title is going to take a while to land, but the activity is clear enough. An operator is someone who uses AI fluently to solve real problems in a domain they understand. The domain might be accounting, customer service, supply chain, marketing, or any other function where understanding the problem is the bottleneck. The domain might also be the technology and infrastructure that supports the rest of the enterprise — which is where most of us with engineering backgrounds will land, because that is where our substrate is most useful.

The accountant who builds a reconciliation tool that compresses two days of monthly work into a button press is an operator. The customer service lead who builds workflow automation their team adopts is an operator. The person who used to be a software engineer and now builds the deployment platform their organization runs on is also an operator. We are the same kind of professional doing the same kind of work in different domains. Our substrates differ. Our activity does not.

This is the part that bruises if you let it. I spent a long time building an identity around being an engineer. Watching that identity become inaccurate is not pleasant. But the alternative is worse — clinging to a title that no longer describes what I do, while the work I actually do gets done by people who are not weighed down by an obsolete identity. The accountant building reconciliation tooling is not slowed down by feelings about being an accountant. They just do the work. The operators who come up cleanly into this new shape, without an engineering identity to negotiate with, are going to outpace the ones who cannot let the identity go. I would like to be in the first group. I am not sure I always will be.

A smaller number of us will be doing actual engineering. Applying technology in novel ways, working on things that have not been built before, extending capability rather than applying known patterns. The honorific is real for this role because the activity is real. It was always real, even when it was buried inside the bundle. It is more visible now because the pattern-application work has moved somewhere else and the engineering work is no longer surrounded by it.

The most fertile place for this work right now is AI itself. The technology is young, capable, and fast-moving enough that working at its edge produces genuine novelty. But the role is not defined by AI. It is defined by the activity. Wherever the next frontier opens, engineers in this recovered sense will be there. The current AI moment happens to be the brightest version of the frontier, which is why so much of the recovered engineering work is happening there.

I do not know yet whether I am going to be in this group or in the operator group. I think I am going to find out by doing the work. Some of what I am doing right now is operator work and some of it is closer to recovered engineering, and I do not yet have the calibration to tell which is which from the inside. I expect that will become clearer over the next year or two, and I expect a lot of people in the profession will be running the same private experiment without talking about it.

What this means for the people I work with

If you lead engineers, you are carrying a version of the same question I have been carrying. What do I do with the senior people whose identity is built on the activity that is being commoditized? The honest answer is that some of them will make the transition and some will not, and the difference is not predicted by tenure or credential or even effort. It is predicted by something closer to disposition — whether the person can let the old identity go and pick up the new activity without spending most of their energy defending what they used to be.

I have stopped using seniority as my primary lens for who will make this transition well. The signal is something more like naive curiosity. The willingness to encounter a new tool and ask what it can do, instead of immediately fitting it into a prior framework. The willingness to keep asking the next question. The willingness to treat agent failure as information rather than as evidence the tool is broken. The most senior engineers I know are sometimes the worst at this and sometimes the best at it, and the difference inside that population is the thing that predicts who transitions and who does not. The credentials predict almost nothing.

I am also more careful now about how I handle the people who are not going to make this transition. Some of them have given decades to the profession. They are not failures and they are not lazy. They are people whose identity investment is in the activity that is being commoditized, and the transition is not equally available to everyone. The honest move is to give them honest signal and appropriate runway, rather than indefinite ambiguous pressure that lets the organization avoid the hard conversation. I have not always done this well. I am trying to do it better.

The part I am still working out

I do not know what to call any of this. The bundle is dissolving and the activities are separating, but the words we have are still the bundle’s words. I am writing the word engineer in this post and meaning slightly different things by it depending on context. The recovered engineering role does not have a settled name. The operator role does not have a settled name. The middle ground that most of us are heading into is not even agreed to be a real category by everyone in the profession.

I expect the names will catch up. They usually do, eventually. In the meantime I am trying to be careful about which thing I mean when I say engineer, and I am trying to extend the same care to the people I work with — not telling them they have stopped being engineers when what I mean is the activity they were doing has changed, and not pretending the title still means what it did when both of us know it does not.

What I am sure of is this. The career that I built, and that most of my peers built, is ending in the form we knew it. Something is replacing it that is partly continuous with what came before and partly something new. Most of us will find a home in operator work, in some domain, doing real and valuable things. A smaller number of us will do work that deserves the engineering honorific in its original sense, and that work will be smaller in volume than the profession has been but more genuinely what the word always pointed at. Some of us will not make the transition at all.

I think that is the honest shape of it. I think it is what I would want someone to tell me if I were a few years earlier in this and trying to understand what was happening. So that is what I am telling you. I am still working out what it means for me. I expect you are too. We can compare notes.