There is an unwritten rule in professional football about what happens to players who have aged out of their prime. When the legs slow and the reflexes dull, the club finds them a new role: assistant coach, scout, or if they are lucky and sufficiently respected, manager. The transition is rarely chosen. It is imposed by biology, negotiated in brief conversations with higher-ups, and announced as though it were an honour. The player becomes the manager not because they wanted to, or because they were trained for it, but because the system needed somewhere to put them.

For decades, software development had its own version of this arc. The talented programmer would write excellent code for some years, and then, as if by gravitational pull, the organisation would begin nudging them toward management. It did not matter whether they had the temperament for it, whether they wanted it, or whether they had ever shown any aptitude for the messy work of coordinating people. The system simply ran out of track for individual contributors to travel on. You either moved sideways into architecture or upward into management. The alternative was to stay where you were, accumulating irrelevance, watching younger engineers be promoted past you.

Now the arc has been disrupted, but not in the way anyone expected. Developers have not been freed from the gravitational pull of management. They have been promoted into it whether they are ready or not, by a different force entirely.

AI agents have made every developer a manager.

The responsibilities are not metaphorical. A developer working in an agentic workflow must define objectives clearly enough that a non-human executor can act on them without constant correction. They must decompose problems into tasks with well-scoped boundaries. They must decide how much autonomy to grant, when to review, when to intervene, and when to let the work run. They must build the infrastructure of trust: the instructions that shape behaviour, the constraints that prevent overreach, the signals that indicate when something has gone wrong. These are management skills. They have always been management skills. We just did not need developers to have them before.

The analogy does not stop at team lead. The agentic developer is also, in a very practical sense, a product owner. The fabled one-shot completion – the ability to describe a task once, clearly, and have an agent return working output – depends on a kind of requirement specification that most developers were never taught to write and always assumed was someone else’s job. The disciplines that programmers once delegated upward – gathering requirements, anticipating edge cases, translating ambiguous business intent into unambiguous executable instruction – have now collapsed back onto the person closest to the keyboard. A vague prompt produces vague output. A poorly structured AGENT.md produces poorly structured behaviour. The agent will not ask clarifying questions the way a junior colleague might. It will simply do what it understood, and you will spend longer reviewing the result than you would have spent writing the code yourself.

What has emerged is a new kind of skill gap that mirrors the one that always existed between good individual contributors and good managers. A developer can be highly effective at solving well-defined technical problems and entirely ineffective at directing an agent through an ill-defined one. The intellectual habits that make someone a strong programmer – close reading of code, comfort with detail, a preference for precision over approximation – do not automatically translate into the ability to specify systems at a higher level of abstraction. Writing instructions for an agent requires the same kind of thinking that writing good requirements has always required: clarity about intent, anticipation of misinterpretation, awareness of what is left unsaid.

The tools that support agentic work have tried to structure this. Skills and MCPs encode repeatable capabilities that can be composed. AGENT.md files serve as something between a team charter and a job description, setting out the norms, constraints, and expectations that govern how an agent should behave within a given context. These are governance artifacts, and writing them well is a form of institutional design. The developer who builds a clean, well-considered agentic configuration is doing something closer to organisational architecture than to programming. The developer who skips this step and wonders why the agents keep making the same mistakes has discovered, at some cost, why management exists.

There is an irony in all this that is worth sitting with. The corporate push for AI-first development was sold, in part, as a way to make developers more productive, to amplify individual output and reduce dependency on coordination and headcount. And it has done that, in some domains, for some tasks. But it has also moved a set of costs that were previously distributed across product managers, business analysts, and engineering managers directly onto the developer. The developer who once only needed to be good at writing code now needs to be good at scoping work, writing instructions, orchestrating execution, reviewing output for correctness, and adapting the system when it misbehaves. The leverage is real. So is the overhead.

The footballer who becomes a manager discovers that their years of playing experience, while valuable, are not sufficient preparation for the role. They knew how to execute; now they must direct. They knew how to respond; now they must plan. When things go wrong in the field, they cannot simply jump in and help out; that work must have been done in advance. Some make the transition well. Others find that the skills they spent a career building translate poorly into the new context, and that what they were good at is no longer quite what the job requires.

Developers are in that moment now. The question is not whether to accept the promotion – the agentic workflow has already given it to them. The question is whether they will develop the skills that make a manager effective: clarity of intent, rigour in specification, and the judgment to know when to trust the agent and when to take back the keyboard.

Some developers will find that they were already thinking this way, and that the new tools simply give them more leverage to express it. Others will find that they have been handed a role they do not yet know how to play, with a team that never complains but also never pushes back.

In a sense, this is a useful pressure for software engineering as a discipline. It forces the deeply specialised programmer – the one who was always excellent at code and indifferent to everything else – to become a more complete engineer. The work is still technical, but the scope has widened to include the things that were once considered peripheral: requirements, communication, design at the system level.

The demise of software engineering as a profession has been widely and loudly reported. Perhaps the prediction is correct in a narrower sense than its authors intended. It may not be all software engineers who find themselves obsolete, but those who never quite grasped that writing code was only ever one decreasingly important aspect of a much wider discipline.