The Obituary Was Premature: Software Engineering in the Age of AI

I’ve been around the IT space for more years than I care to remember. I started contracting when I was 7 years old, doing business management systems in Visual FoxPro. This was a time when you could buy a product like FoxPro or, later, Access, and have a database and development all in one. With a little bit of effort you could build a system that supported your entire business. Some of the systems I built are still in use today, believe it or not.

In many respects the current explosion of AI tooling and the democratising of software development has many parallels, but just like back in my formative years I am not convinced we’ve found exactly where these new tools sit in the software development and the larger public domain.

The pace of change is now such that what was the best only weeks ago is already old hat. That pace of change is both exhilarating and increasingly difficult to manage, especially when we seek to incorporate those tools into our daily work.

Opening: the obituary

Like anything new, there were, and still are, some truly massive claims and counter-claims, and I freely admit that when the first version of GPT landed I wasn’t all that interested.

But very quickly the hype became impossible to ignore, and some of the claims started to hold true. Many of them matched similar claims made in the past about things like HyperCard.

In the blink of an eye, OpenAI and Anthropic are at your desk and on your phone, reverse engineering, producing slop grenades and poking at decades-old bugs.

It’s easy to see in this context that the early claims are holding true, but what does that mean for software engineering as a profession?

The productivity claims

Those early claims echoed the much-maligned, and rightly so, 10x engineer fallacy. Goldman Sachs’s CIO, Marco Argenti, projected 3-4x gains from AI agents in software engineering. This was echoed by CEO estimates of a more meagre but no less impressive 20-30% productivity increase.

I still struggle with how such a thing is truly measured, and am reminded of how measuring LOC and other similar supposed developer productivity metrics give rise to awful practice and perverse incentives. For example, if productivity is measured by the number of PRs I open, I can simply instruct my agent of choice to create 20 thousand one-line pull requests instead of the one unreviewable one.

The output surge

This is exactly where the first cracks start to form: not only in how we actually measure the “improvement”, whatever that may be, but in the sheer volume of content that’s been generated. That 20k PR in the early days ends up either merged under duress, or you spend days reviewing it only to realise a new library has been made up and suddenly HTTP/4 is a thing.

Obviously an exaggerated example, but what isn’t is that a developer, even in a small or mid-sized business, could generate so much code that it would be impossible for anyone to really keep up.

"Much of the software birthed into the world is largely throwaway. I don't mean that in a bad way, but it is simply a solution for today. It solves the problem, it's shipped, and if the problem space changes it's simply rewritten or replaced."Jack Tams

I have a theory: much of the software birthed into the world is largely throwaway. I don’t mean that in a bad way, but it is simply a solution for today. It solves the problem, it’s shipped, and if the problem space changes it’s simply rewritten or replaced. Very few software engineers have worked on projects with significant longevity, and as such they are rarely exposed to the kind of decision-making and engineering that makes such projects last. The first proper commercial project I worked on had much of its underpinning software older than me, and believe it or not, that very same stuff, over a decade later, got a rebrand with “cloud” in the name. It is still running, and can trace its lineage and code all the way back to the early 90s.

So in this environment, and with models trained on similarly short-lived projects, is it any wonder that the output is software that does the job but could be politely described as “messy”?

We are peaking in our hype cycle - the grumpy engineers have dealt with their first production incidents, caused by that small change in that massive PR.

The control gap

The genie is well and truly out of the bottle, and we are starting to see the impact of this deluge of content. There is a counter-intuitive discovery that many come across: we think we are moving faster, but in reality we are moving slower.

This harks back to my earlier point that there are very different codebases across the industry. I maintain that much of the code built today sits in the “it works, ship it” bucket, but on complex codebases the use of AI tools actually slows you down. You might predict a ~20% improvement in the time to complete a task, but when it is measured the exact opposite is true: you get slower by nearly the same amount, ~19% (METR, 2025). The reasons vary between codebases. Some are old enough to have really esoteric paradigms and bad practices (looking at you, Java 1.0 “make everything static” codebases; yes, they still exist). Others are simply down to earlier LLMs being unable to hold the context required to solve the problem. Some of this has improved from my experience on established code, but you still have to be very particular about how you use AI tooling to get its best effect.

"Surprisingly, we find that allowing AI actually increases completion time by 19%—AI tooling slowed developers down."METR, 2025

The evidence on who benefits most is mixed. Westpac’s internal experiment found a 46% gain, larger for less experienced staff (Westpac, 2023). Goldman Sachs Research’s March 2026 analysis put the median gain on big tasks at around 30%, with almost no macroeconomic impact (Goldman Sachs Research, 2026). Stanford’s Software Engineering Productivity Research Group has studied more than 100,000 engineers (Denisov-Blanch, 2025). Bain’s 2024 survey of financial services found productivity gains across the board (Bain, 2024).

There is a flip side for teams too: your colleagues have been on the same journey as you, and where you might once have seen a few concentrated PRs a day, they now 5x or 10x that. I think this aspect of AI-driven development cycles is far too often overlooked, and it contributes to the fatigue many of us feel: the context switching required to keep up with decisions about what is important has increased massively, and this new cost remains poorly accounted for in many of the earlier predictions.

Governance returns to people

We are now moving through the hype cycle at pace. We’ve made mistakes but are starting to get a better handle on how to use some of the emerging tooling. While some are blazing right at the bleeding edge and doing things that have never been good practice (such as running OpenClaw with its default configuration, which China’s CERT has called “extremely weak”), there is much wider adoption of AI tooling inside engineering teams and across companies in general, with varying degrees of success.

There are two trends I see right now. The first is a misguided assumption that, with AI, the need for junior engineers is so reduced that you no longer need to hire them (Anthropic’s own workforce report). The second is restricting access to tooling to more specific areas of operations. It’s clearly not sustainable to let every member of staff produce their own bit of software for a specific job; it’s a governance and maintenance nightmare (Bloomberg reports Goldman restricts traders and bankers from some AI tools).

The job of software engineering was never about code slinging. I do pretty much agree that code slinging as a paid job is dead, given LLMs can produce code faster, and even if it’s poor quality the iteration cycles are much shorter too. The job of determining what’s important, what the priority is, and where time needs investing is now even more important. Your favourite AI pal is never going to actively seek out the burning parts of the platform to prioritise fixing them. It will certainly help you fix them, but you need to know that’s where the time needs placing.

I have been unbelievably impressed with debugging live production incidents using /superpowers:systematic-debugging, but you also get a list of every side quest you might want to take, and the temptation is to try and complete them all.

Close: the job has changed, not ended

"Ah, it's like I said. The more things change, the more they stay the same."Quark, Star Trek: Deep Space Nine, "What You Leave Behind" (1999)

So what does that all mean? Firstly, let’s call out the elephant in the room: using AI productivity as a justification for significant job cuts (Microsoft offers buyouts to around 60,000 staff as its profits soar) is the wrong end of the zero-sum game. The money side of this is a subject for an entire lifetime.

Boris Cherny, creator of Claude Code, suggests that new archetypes of software engineering are emerging. I’d argue these aren’t new: they’ve always existed in some form, but we only really come to appreciate them when we reach a more senior position, i.e. Principal Engineer. See the excellent book Staff Engineer by Will Larson.

Prototyper Builder Sweeper Grower Maintainer

Source: Boris Cherny's post on X, June 2026.

Which neatly brings us back to the fallacy of not hiring junior engineers. The need for these roles doesn’t change. In fact, we likely need more engineers aligned to these sorts of philosophies earlier in their careers. If we cut off hiring, how do we get experienced people into the industry before cognitive atrophy robs us?

In my 29 years in the industry, nothing has moved as quickly or changed so rapidly as the current AI “evolution”, and I think that presents significant opportunity for better and worse. We still have many problems to solve. The pull request paradigm that has defined how we operate for over a decade is clearly not scalable. Nor do I think the role of the software engineer is sidelined by these changes. If anything, the problems have grown in scope and impact.

I also think there’s the inevitable move from large hosted models to specific models and tooling that can run at a usable pace locally, on small devices such as iPhones (Gartner expects open-weight models to run 90% of enterprise agentic workflow steps by 2030). In that respect, I do think Apple gets unfairly dunked on for its AI strategy.

Is the software engineer dead? Certainly not.