We Are All Managers Now
10 May 2026
Recently, I’ve been reflecting on the past few years of my career, and how quickly things have changed. So quickly, in fact, that you could be forgiven for blinking and missing it. AI-driven development is here, and it’s here to stay forever.
This time four years ago, I was a lead engineer at Intellum. I was busy building a brand-new component based architecture on top of our legacy Rails application, and every line of code of that framework was written by me or a handful of my colleagues. Three and a half years ago, I made the transition to software engineering manager, still at Intellum, where my role became more focused on process, people and projects and less so on individual contributions to software (but I could never stop - once a developer, always a developer). About two years ago we all got a subscription to Copilot, which was a neat little speed boost; it would complete your lines of code as you typed - how could it know what you were thinking?! But AI felt like an enhancement instead of a fundamental shift; like going from a manual to an automatic gearbox in a car. At that point in time, ChatGPT was spitting out scripts that were hit and miss, and us developers looked on in pity at those who attempted vibe coding, sniggering at the inevitable outcome.
It was a simpler time.
Today, the landscape is very different. When properly guided, large-language models (LLMs) that are tailor-made for coding, such as Opus, Codex and Composer, can build and maintain real software; they can fix complex bugs, review code with startling depth, grow your test suite and, of course, implement new features, all in a fraction of the time it would take for a human to do so. The key phrase being “properly guided”. The quality of the output from LLMs directly correlates to the quality of the prompt given by the user; rubbish in, rubbish out.
Software engineering is not dead
For this reason, I’m not willing to declare software engineering as a profession to be dead or even dying. LLMs are not yet at the point where they can take engineers’ jobs, and I don’t believe they ever will. At their core, they remain probability calculators. The end-goal of this AI race is not to make better and better LLMs, it’s to reach AGI: Artificial General Intelligence. But that would take a fundamental shift in the underlying technology, not incremental improvement. And, if AGI lands, no job is safe, let alone software development.
Until such a time comes, experienced software engineers that can adapt to this new world are arguably more valuable than ever (though I am genuinely concerned about the implications for those who are early-on in their software career, or looking to get started in it - more on that in a future post). The engineers bring the guardrails that are essential to the development process. They are the orchestrators, keeping the development on track. And they are the quality gate, ensuring that the result meets the level of standard that they have spent their career honing. LLMs can build deep context at lightning speed, but their context will always be narrow, only being able to consume what’s given to them directly and fundamentally limited by hardware and the laws of mathematics. Humans can see the broad picture, jumping from domain to domain and task to task without fear of their context window blowing up, or tokens maxing out.
The difficult truth
I have to admit, this has been an uncomfortable transition for me. There is immense satisfaction in the process of writing code, which is why most of us got into it in the first place, and I’m still grieving slightly that this has been taken away from me.
Recently, I’ve had the pleasure of working with Isak Bosman, who recently came to Intellum bringing his wealth of experience in fine-tuning AI-driven software development processes. He said something that resonated with me, which I’ll paraphrase:
Broadly speaking, there are two types of developer: process-driven and outcomes-driven. Those who are process-driven generally find it harder to adopt AI-centric software development practices.
This helped me to realise why I was finding the transition difficult: I’m process-driven. I used to find enjoyment in the development lifecycle, but that’s now been delegated away. Now, my joy can only truly be found in the outcomes.
The mindset shift
As difficult as I found it, I know that there are those who are struggling much more. I attribute this to the fact that I’d already started to make this mindset shift three years ago, when I accepted the role of engineering manager. I went from spending near 100% of my time on development to about 10%, with the majority of my time focused on leading my team, breaking down projects and organising work, keeping a close eye on quality and bringing things back on track when needed. I was no longer the individual contributor, I was the multiplier. I couldn’t find my satisfaction in the development process anymore, since I was doing so little of it. I needed to find it in the outcomes; when my team succeeded in a project, I too had succeeded, even if I hadn’t written a line of code.
I’m sure you see where I’m going with this. This is the same mindset that needs to be adopted by every software engineer who is using an AI-centric development process. You are the manager, guiding your “team” of agents towards success.
Our jobs were never to write code, they were to deliver outcomes. I found it somewhat releasing when I came to terms with this fact, and I hope that others reading this will too.
We are no longer individual contributors, we are all managers now. Sorry about that.