Finding Identity in Software Engineering in the age of AI
We’re still in the middle of the AI upheaval in tech. It’s a time of great uncertainty with nobody really knowing how this will turn out. One thing does seem certain though, AI is not going away. What does this mean for the identity of the software developer or engineer? What might the future look like and how might we meet it positively without vapid ‘trust me bro’ ‘influencer’ hot takes. What’s with the picture of an airliner crew in a cockpit?
Cockpit of a Boeing 707. Photo: Greg, N707JT Cockpit, CC BY 2.0
What’s the problem we’re discussing here?
I’m not pretending that there aren’t other issues around AI but here I’m focussing on personal identity. I’m going to use the term ‘SDE’ here to cover software developers, engineers, DevOps people, etc. For many, we appear to be moving from stage 3 on to stage 4 of the ‘5 stages of grief’/‘Sarah cycle’/‘Change curve’:
Shock → Denial → Anger → Bargaining → Acceptance
We have moved past the naysayers claiming that ‘you can’t use AI in production’ and on to what I’ll call here the ‘Loss of Identity Posts/Posters’ (‘LOIP’) on social media. The common thread in these is complaining about how with the advent of AI, the poster has lost the parts of professional software development that attracted them to the field and they enjoy, typically ‘coding’. In some places there has been such an avalanche of these posts that they have been banned or restricted- not because everyone else thinks AI is great, but because otherwise this would be the only topic of conversation, drowning out everything else, and it’s a pretty dead-end one. It isn’t about being unsympathetic or that the anguish isn’t real, human and understandable, but like trying to support a friend the first time they get dumped, it’s draining. You might do it for a friend but few would want, or even be able, to do this for people in general, full-time. There isn’t really much to say - the LOIP isn’t looking for ‘answers’, they just want affirmation. Ultimately it’s their internal conversation out loud.
Is this just an SDE problem?
In some senses SDEs seem to be both further ahead and also behind mathematicians on the change curve. This group seems to have experienced something approaching generational trauma in October 2026 with the sudden release by OpenAI of AI-generated solutions to some 100 open problems in mathematics. Perhaps most notable of these are the Navier-Stokes equations which I understand have lacked a formal proof for 90 years. I’m not a mathematician, so I have to go on received wisdom and published responses, including:
- BBC short article: OpenAI says it cracked 90-year-old maths problem in 88 hours
- Collected individual responses from individual mathematicians: 100+ reactions to 100+ solutions
- And this response from the notable celebrity mathematician Professor Hannah Fry:
While the world of mathematics checks, digests, and discusses this latest development, we asked our colleague, the well-known mathematician and broadcaster Hannah Fry, for her take on the topic. After all, Hannah worked on the Navier-Stokes equations for her PhD and is also an expert on AI. She chose to focus on what the result means for the equations:
It’s worth noting that amongst all the reporting, comment and criticisms, nobody is saying that the proofs delivered are incorrect- although there is caution that there has not yet been time to review and refute them either!
Some conclusions here are obvious, regardless of sympathy towards mathematicians and their field:
- The nature of the field and working in it has fundamentally changed
- No matter how regrettable, controversial, etc. we might find it, we now have solutions where we did not before
- Nobody who actually ‘needs’ a solution in the field is going to ignore AI as a potential resource in future
What’s the alternative take?
Returning to SDE, the Outcome Oriented Engineering manifesto (o16g) was published in February 2026. On a personal level I continue to be surprised that SDEs might expect to be paid specifically for what now has become essentially a hobby- coding by hand- when the actual requirement is, and (nearly) always was, solutions to business problems. For a ‘real world’ comparison, earlier this year I needed a lawn fixed - half of it was grass and half of it trampled mud. Gardening is a popular hobby and there’s all manner of things you can do with it. The thing is, I just wanted my lawn fixed- I was paying for the result, not someone else’s hobby with an incidental outcome. I hired a gardener to fix it to be all grass and he did a great job. If he wants to do hobby stuff then he is welcome in his own garden. Yes of course there is a market for artisanal products - handmade sweaters, boutique barista coffee, etc.- but in the real world these are the exceptions not the rule- most people are not eating sandwiches made with hand-baked bread made with hand milled flour and home grown ingredients every day. Perhaps it is an artefact of people used to working in insulated environments but the ‘get stuff done!’ principle will be familiar to people who have worked in startups.
So What Does This Change Look Like On The Ground for SDEs?
It used to be that a typical team-based SDE employee’s job might look like:
Receive the problem to be solved → Do scrum ceremonies around estimating, sizing, scheduling → ‘Spike’ i.e. investigate the topic → report back → build a proof of concept (‘PoC’ by hand) → Agree some changes → Go off and build a version 1 (or productionise the PoC)
Today the situation looks more like:
Receive/identify a relatively basic problem statement → Describe/Refine the business problem (typically using AI) → Evaluate options (typically with AI) → Design/Architect a solution (usually with AI) → Build with AI → Refine/test → Done
There isn’t really a lot for a scrum master to add here- it can now be quicker to produce and deploy the feature than write and size a ticket for it. Thing is that there may not be much for handcrafted code to add either. As an example I was able to go from initial request, through specification, design, implementation across multiple repositories, testing, peer review, sign-off, integration and deployment to production in 22 minutes for a feature in October 2026. Obviously not everything can (or should be!) be that fast and this was a relatively small feature but the game has fundamentally changed. It’s understandable how people can find it jarring and feel adrift when they have been used to taking longer than this simply to initialise a git repository and install their dependencies.
N.B. I am not advocating in any of this for not including the users’ perspective in the solution. Thing is in the real world it can often be more practical, if not simply necessary, to get an initial solution out and review in place, especially for an internal tool and where there is direct communication with a relatively limited number of users, than it would be to go through a more involved consultation process. This doesn’t prevent iteration or improvement!
So What is the suggestion?
My first career wasn’t in tech. It was in healthcare management. I had 55 reports in various buildings doing largely self-directed administrative work. When my counterpart at the other site was away that number doubled. There wasn’t really any question of me stepping in to cover any one person’s job at that scale, and any impact I had had to be achieved through other people. Obviously it wasn’t all wine and roses but one part that appealed to me was problem solving- sometimes quite abstract problems with quite abstract solutions. In some respects I feel that this offers an analogy to what software development and engineering is now becoming. Traditionally this might be thought of as software architecting, and I don’t mean the kind of architect who doesn’t code.
These days when I am trying to figure out how to build something, I am unlikely to start trawling through people’s blog posts and API docs directly first. It’s become a lot more about asking questions and evaluating the answers, critical thinking, and to some extent knowing what good looks like. I would argue that there is significant skill to doing this effectively, especially in a brownfield or production environment. Yes, it will probably be harder for new entrants to the field to develop this skill now and certainly to get the opportunity to do so. What I don’t expect is that demand for it will evaporate. In any event critical analysis is a very different skill to simply performing a task. It’s been obvious for a very long time that SDE skills are moving up the stack, e.g. compiling Linux kernels is no longer a highly marketable skill and people have stopped pretending that JavaScript can’t do fullstack. Five years ago people might ask interview candidates to reverse a linked list or binary tree on a whiteboard and I’m sure some still do, but in the real world it’s a solved problem. The real skill is knowing when you should be using or reversing these and if it even matters.
What for the Future of SDE employment?
Some commentators have referred to Jevons paradox which states (based on coal consumption during the industrial revolution) that as technological improvements increase the efficiency of a resource’s use, total consumption of that resource can rise rather than fall. This take may be highlighted at the moment partly because of the recent launch of the ‘Jev’ decision model (TechCrunch). Right now it doesn’t really feel like efficiency is stimulating demand. 2026 has seen large numbers of layoffs in Big Tech, even from companies supposedly doing well. We have seen significant cuts, with Oracle (up to 30,000, ~13–18% of staff), Intel (~12–14%), Amazon (16,000–20,000) and Meta (~10%) leading, while Microsoft (~2%) and Salesforce (~1.4%) made much smaller reductions. Some of these, notably Oracle, directly pinned this on ‘AI’, as has, e.g. NatWest Bank which laid off 1,000 staff citing AI in October.
My own take is that yes we will likely need fewer SDEs working on billable hour bodyshop stuff where people work as a fungible resource to fulfil tickets defined by someone else. This is not the same as the often-heard ‘nobody is hiring juniors’ complaint but it’s still a little early to tell what the higher levels might look like. We are already at the point where e.g. a salesperson with no technical knowledge can vibecode a prototype. They won’t be able to integrate, secure or maintain it, but they can certainly get further than drawing something on the back of an envelope. In 2022 I wrote:
Yes, the people functioning merely as a mechanical interface will likely find their services less in demand in this field, just like all of those Flight Engineers who sat at the third seat in the cockpit in the early days of jet airliners but have now been eliminated from the crew. As ever, the people who are able, adaptable, ready and willing to move up the stack will be fine.
I still take this position but since I’m restating it with emphasis I decided to look into backing this up robustly. Based on the available sources, we can say (in aggregate, and for US airlines) that, whilst the third flight-deck seat all but disappeared from commercial airliners between 1990 and 2025, pilot seat-hours doubled- i.e. that the reduction in flight engineers was more than offset by the increase in pilots.
Show the figures, method and sources
US airline airborne hours (millions)
| Year | All aircraft (M hours) | Types that carried a flight engineer (M hours) | Share | Unambiguous types only (M hours) | Pilot seat-hours (M, 2 × all) |
|---|---|---|---|---|---|
| 1990 | 10.31 | 3.77 | 36.6% | 2.77 | 20.6 |
| 1995 | 12.18 | 2.26 | 18.6% | 1.60 | 24.4 |
| 2000 | 15.13 | 1.45 | 9.6% | 0.96 | 30.3 |
| 2005 | 19.35 | 0.61 | 3.2% | 0.26 | 38.7 |
| 2010 | 17.66 | 0.24 | 1.4% | 0.08 | 35.3 |
| 2015 | 17.94 | 0.09 | 0.5% | 0.01 | 35.9 |
| 2019 | 19.83 | 0.04 | 0.2% | 0.01 | 39.7 |
| 2020 | 11.96 | 0.04 | 0.3% | 0.01 | 23.9 |
| 2025 | 20.53 | 0.00 | 0.0% | 0.00 | 41.1 |
Method and caveats
- Hours: aircraft are classified by BTS type code, which does not always say how many crew flew. DC-10 codes include later two-crew MD-10 conversions, 747 classic codes include freighters, and early A300s varied, so “types that carried a flight engineer” is an upper bound after about 2000. “Unambiguous types only” counts just 707/720, 727, DC-8, L-1011, Electra and piston airliners, a lower bound. Both fall to almost nothing. Types counted in the upper bound: Boeing 707/720, 727, 747-100/200/300/SP/C, DC-8, DC-10, L-1011, Convair 880/990, Lockheed Electra and large piston airliners; early A300s were not counted.
- Pilot seat-hours are 2 x total airborne hours, which slightly overstates where single-pilot types are included.
- No figures: I could not obtain flying hours by aircraft type for the 1970s and 1980s. The BTS series starts in 1990, so this analysis cannot show how the three-crew share changed before then, and the earlier decades are not covered here.
- These are aircraft and hours, not people. They show seats on the flight deck, not who filled them. The 2020 dip is the pandemic.
Sources
- BTS TranStats, Air Carrier Statistics (Form 41 Traffic): T-100 Segment, US Carriers Only, 1990 to 2025, air time by aircraft type.
- Flight engineer, Wikipedia (elimination of the role).
I do not think that SDEs are in quite the same pickle as mathematicians, where fundamentally AI has taken their lunch, at least not yet. Referring back to our airline example, in some senses we’re basically moving up the stack. Thing is that Software engineering is such a wide field that it can include what are essentially totally different jobs. Not all of these will stick around. We’re essentially moving from needing flight engineers to needing only pilots.
In Conclusion
The grief is real, and I don’t dismiss it. As with Hannah Fry and the equations, mourning the craft of writing code by hand is a perfectly human response. But mourning is a stage, not a destination. The question the LOIPs don’t get to is what was/am I actually for, commercially?
If your identity has been essentially in the act of writing code, like translating from one language to another, then yes, I would say that it’s under pressure. If it has been in solving problems, knowing what good looks like, and being trusted to say “this is the right thing to build, and this is how we know it works”, then nothing has been taken from you in that respect. We can think of this as a continuation of the work moving up the stack, as it has before.
I would expect that there will continue to be opportunities for people who are adaptable, curious, and interested in problem solving and critical analysis. Flying grew, despite the decline in the role of the flight engineer, as did the number of pilots, and those people are still there in the front seat. My outlook and response to LOIPs would be to keep the hobby a hobby. Hand-craft things in your own garden, because it’s enjoyable, but expect to be paid for the lawn, not the digging.