The unit of software production just collapsed. It used to be a team. It is now one experienced person and a fleet of agents.
I spent twenty-five years climbing to the point where I no longer had to write code, twenty of them with a CTO title and a calendar full of meetings to match. Recently, and deliberately, I went back to being a builder. So have some of the most experienced people I know. This is not nostalgia. It is the most rational move available right now.
I will be honest about how it started: I resisted. I assumed I would be rusty, that the muscle had wasted, that I would spend a weekend fighting tooling and remembering nothing. The opposite happened, and it is the reason I am writing this.
What actually changed
A single experienced person, directing agentic AI tools, can now do the work that used to take a team. Not as a figure of speech. The actual work. One person sets the direction, and a fleet of agents writes the code, runs the tests, and wires it together.
Here is what that looked like in practice. A few weeks ago I rebuilt an internal tool over a weekend, the kind of thing that, a couple of years ago, would have been a fortnight of work for two or three people. The agents stood up the auth flow, the data layer, and a clean set of tests in an afternoon. They also, with complete confidence, handed me a token-refresh path with a race condition in it. It would have passed a casual glance. Two requests landing in the same window and one of them silently gets a dead session. I have shipped that bug before, years ago, and paid for it, so I recognised the shape of it on sight. I said no, that is wrong, here is why, do it again. It came back correct in minutes.
That is the whole story in miniature. The agents did in an afternoon the mechanical work that used to be the week. The thing that mattered, the thing that stopped a quietly broken system from shipping, was a judgement call that came from having been burned. The team did not get bigger. It collapsed into one person who knows what good looks like.
For now, in the window where agents are powerful enough to do the work but not yet reliable enough to coordinate each other without a human holding the plan, that experienced person is the most productive single unit in software.
The barrier to building has almost vanished
The second change is quieter, and in the long run it matters more. The barrier to doing this has nearly disappeared.
Good-enough models now run on a laptop. Not a data centre, not a rented cluster you have to justify to finance, a machine on a train. I want to be careful here, because this is a moving target and people overclaim it. Today's locally-runnable open-weight models are still behind the largest frontier models on the hardest reasoning. But for the bulk of real build work they no longer need to win that race. The intelligence required to build serious software has stopped being a scarce, metered, centrally rationed resource and started being something you simply have, the way you have a compiler.
There is a common assumption that you need the largest, most expensive model for everything. You do not. The biggest models will matter enormously for a small set of genuinely hard problems, the kind where the difficulty is the reasoning itself. But most real work is not that. Most real work is competent, well-understood work done at volume: building the screen, writing the endpoint, covering the edge cases, fixing the failing test. For that, fast, local, and private is more than enough to build things that matter. The model is becoming the commodity. What you wrap around it is where the value sits, and I have argued before that your AI strategy is not the same thing as the model.
So the two old gates are both falling at once. You no longer need a team. And you no longer need anyone's permission, budget, or infrastructure to get hold of the intelligence. That combination is why experienced people are quietly going back to building, and why it would be a mistake to read it as a step down.
What it has done to the skill itself
The part I keep turning over, though, is none of the above. It is what this has done to the craft itself. Because the skill of building has not just got easier. It has changed shape. The core skill of software engineering has shifted from recall, memorising libraries, SDKs, and function signatures, to judgement, knowing what to build and whether the result is right.
For my whole career, a large part of being good was that recall. I had to remember every library and what it was for, every SDK and its quirks, the exact signature of the function I wanted, which configuration flag turned the thing on. That knowledge took years to accumulate and it decayed the moment a framework changed under you. It was also, if we are honest, a large part of what made the work slow, and a large part of what gatekept it. The person who had memorised the most could move the fastest, and everyone else waited.
I do not need most of that any more. I describe what is needed, the agents produce it, I read what comes back, and I decide whether it is right. The recall has been lifted off me. The value has moved up the stack, to planning, design, review, judgement, and taste.
I should be precise, because it is easy to overstate this. Building is now dominated by judgement, but it has not become only judgement. Someone still has to wire up the environment, understand the runtime when it breaks, and read the code well enough to verify it. You cannot judge code you could not, in principle, read. That race-condition bug is the proof: catching it required reading what the agent wrote and understanding what would happen at runtime. Judgement sits on top of enough hands-on understanding to verify the answer. It does not float free of it.
Recall was rented. Judgement is owned
There is a deeper reason this shift favours the experienced, and it is about where each kind of knowledge lives.
Recall was always rented. It lived in the specific versions, the current frameworks, the tooling of the moment, and it expired. Every senior engineer has felt the quiet anxiety of watching hard-won knowledge of one stack become irrelevant when the industry moved to the next. You were forever re-buying the same expertise in a new currency.
Judgement does not expire like that. Knowing what makes an architecture sound, how to decompose a problem, where complexity hides and what it costs you later, why the elegant solution is sometimes the wrong one: none of that is tied to a framework version. It compounds. The twenty-five years were not wasted on syntax I no longer need. They were spent building the exact faculty the machine cannot yet supply, and now depends on me to provide.
So where do the next seniors come from
This is the strongest objection to everything above, and I want to meet it head-on rather than wave at it.
If judgement comes from having been burned, and the recall-heavy grind that historically did the burning is now done by agents, where do the next seniors get their scars? My whole argument quietly favours people who happened to train before AI. That is a real problem, and pretending otherwise would be exactly the kind of unfalsifiable optimism I have no time for. I have written about how the training ladder is breaking, and this makes the question sharper, not softer.
But it is a training and organisational problem, not a fault in the technology, and that means it is fixable. The fix is to manufacture the burns deliberately, because they no longer arrive for free. Make juniors critique and repair what the agents produce rather than just accept it. Run post-mortems on the designs that rotted. Give them supervised ownership of real consequences early, so the lesson lands when the stakes are small. We used to teach people to read code before they wrote it. The new version is teaching them to judge code before they ship it, and to recognise the race condition before it bites. Withholding the tools does not build judgement. Pointing the tools at the right kind of practice does.
Why senior people are going back to the keyboard
Put all of it together and you arrive at something that inverts one of the oldest assumptions in this industry: that senior people graduate away from building. That coding is for juniors and leadership is for grown-ups. That the career arc points away from the keyboard, towards the meeting room.
I lived that assumption. I climbed exactly that ladder, and I have written about what I learned at the top of it, that the engineering was the easy part and leadership was the hard one. I still believe that. But the ground has shifted under the idea that the two are separate stations on a one-way line.
The more judgement you have earned, the more powerful a builder you now are, precisely because building is now dominated by judgement. The senior person who stepped back from the code because it was slow and fiddly now finds that the slow, fiddly part has been automated away, and what remains is the part they are best at. This is not the 10x engineer of the old myth, the lone hero who out-typed everyone. It is the experienced orchestrator who out-judges everyone, directing work rather than performing it.
And it is, genuinely, the most fun I have had with this work in years. The grind is gone. The thinking is left. For the first time in a long time, the distance between an idea and a working system is short enough to cross in an afternoon, and the thing standing in the way is no longer what I can remember. It is what I can decide.
A transitional moment, and what comes after
None of this is a permanent state. The window I have been describing, agents powerful enough to do the work but not yet reliable enough to coordinate each other, will close. Agents will get better at delegating to, checking, and correcting one another. When they do, the shape will change again, and some of what a team used to provide will have to be rebuilt: the review, the redundancy, the second pair of eyes that catches the thing the one expert is blind to. A solo builder supplies that by hand today, deliberately. Agents will supply more of it over time, and that is a real limit of this moment, not a footnote.
But the underlying move does not reverse. Whatever the agents end up coordinating among themselves, someone still has to decide what is worth building, judge whether it was built well, and own the consequences when it ships. That is judgement, and it is the one part of this that is not being automated. If anything, the next phase will demand more of it, not less, because the volume of work a single person can set in motion keeps rising, and so does the cost of pointing it at the wrong thing. This same shift is already reshaping who, and what, your software is built for, which is why I think agents are about to become your biggest user.
So I am not treating this as a clever trick for the moment. I am treating it as the new centre of gravity for the craft. Build, but build by judging. The recall was never the point. It just felt like it, because for so long it was the toll you paid at the gate.
If you are senior enough that you stopped building, here is an honest question: when did you last actually try it again? Not the version you remember, the version that exists now. You might be surprised what you can do in an afternoon. I would love to hear what you build, and if you are a leader working out what this means for your team, I am happy to talk it through. Let's talk.
Related: The orchestrator, not the 10x engineer · The training ladder is broken, and AI did not break it · Engineering was the easy part · Going headless for agents · How I help engineering teams make this transition
