For the better part of two decades my job has been to make other people's work possible. Setting direction, protecting focus, clearing obstacles, holding the shape of a programme steady while a hundred smaller decisions were made by people much closer to the detail than I was. That is the trade you accept when you move into leadership. You stop making the thing and you start making the conditions in which the thing gets made.
I do not regret the trade. It is real work, and it is harder than it looks from the outside. But something is quietly lost in it, and most delivery leaders I know can feel the loss even when they do not name it. You gradually stop knowing what the work feels like in the hands. You begin managing an abstraction of the work rather than the work itself, and you do not notice the drift because the reports keep arriving and the meetings keep filling the calendar. The cost shows up later, on the day you can no longer tell the difference between a genuine constraint and a habit nobody has thought to question.
Over the past year that has reversed for me. I am building again. Not in a nostalgic way, and not because anyone asked me to. I build because the cost of trying an idea has fallen so far that not trying now feels like a decision rather than a constraint.
The tax on curiosity has gone
Every idea used to carry a tax. Before you could see whether a thought was any good, you had to pay for a development environment, a data model, some scaffolding, a stack of decisions about frameworks, and a weekend you probably did not have. The tax was high enough that most ideas never got tested. They were argued about instead. They went into slides and business cases and became the subject of opinion rather than evidence.
That tax is close to zero now. The distance between "I wonder whether this would work" and "here it is, running, click it" is measured in an evening. Sometimes it is measured in an hour. I have lost count of the small tools I have built for my own practice at Company31 simply because it was faster to build the thing than to write a specification describing it.
Vibe coding is a slightly ridiculous name for this, and I suspect the name will not survive. What it describes is real though. You hold the intent, you describe the shape of what you want, you read what comes back, you correct it, and you keep going. The machine handles the syntax. You handle the judgement about whether the result is any good. It is closer to sketching than to engineering, and sketching is exactly what most ideas need before anyone commits real money to them.
What actually comes back
The part I did not expect is what returns along with the ability to build.
The first is contact with the material. There is a kind of understanding that only arrives through friction, through watching your own assumption break against something concrete. A model that will not load on the machine in front of you teaches you more about constraints in ten minutes than a vendor briefing teaches you in a week. Leaders who have been away from the tools for a long time tend to describe technology in terms of promises. Leaders who are still touching it describe it in terms of limits, and limits are where good decisions actually live.
The second is speed of argument. A working prototype ends debates that a document cannot. A slide invites opinion, and all opinions in a room are priced the same, so the loudest position tends to win. A working thing changes the physics. When someone insists a process is simple and then watches four people fail to complete it on screen, the discussion moves somewhere better and nobody has to lose face to get there. The conversation stops being about whether the idea is viable and starts being about whether it is the right idea.
The third is humility, which arrives on its own schedule. Building again has shown me how much of what I believed about effort and complexity was calibrated to a world that no longer exists. Estimates I would have defended firmly two years ago now look absurd. I have had to revise my own instincts in public more than once, and I expect to keep doing it.
A prototype is an argument you can run. It is not yet a product, and confusing the two is the oldest mistake in delivery.
Leading while building
There is an obvious risk in all of this, and it deserves saying plainly. A leader who starts building can become the bottleneck I spent years teaching others to avoid. The pleasure of making is genuine, and pleasure distorts priorities. If I am writing code at midnight because it is satisfying rather than because it is the highest value thing I could be doing, that is not leadership. That is avoidance dressed up as initiative.
The other risk is that a fast prototype gets mistaken for a finished system. Generated code is confident, and confidence reads as quality. The last mile has not become easier. Security, data handling, integration, support, the slow accumulation of edge cases that make software actually usable in an organisation: none of that has been compressed the way the first draft has. If anything, the gap between a convincing demonstration and a dependable product is now wider, because the demonstration is so much cheaper to produce.
So I hold both. I build to think, and I lead to deliver. The building sharpens the leading, because I am no longer reasoning about the technology from a distance. The leading disciplines the building, because I know what it costs to take something from an evening's work to something a business can rely on at eight o'clock on a Monday morning.
What strikes me most is the timing. I spent two decades learning how organisations absorb change, how teams recover trust, how governance can create movement instead of theatre. That knowledge was, for most of that period, applied to technology I could only direct from outside. Now the same knowledge sits alongside the ability to make things directly, at a moment when the way products get imagined and built is being rearranged more thoroughly than at any point in my career.
I do not think the revolution is that anyone can build. Plenty of people could always build. The revolution is that the distance between understanding a problem properly and shaping a response to it has almost vanished, which means understanding the problem properly is now the scarce skill. That was always true. It is simply harder to hide from now.
I am back on the tools, later than I expected and for reasons I did not predict. Mostly what it has given me is a clearer view of the work. And a clearer view of the work has been the only thing worth chasing all along.