The question under every AI reorg
There is a question sitting underneath almost every conversation I have with other leaders right now, and most people are too polite or too nervous to say it plainly. If an agent can do the task, what is the person for? It is being asked in planning meetings, in board decks dressed up as "efficiency," and quietly, at 2 a.m., by good engineers wondering what their job becomes. It deserves a better answer than the two that dominate the discourse: that nothing really changes, or that the humans mostly go away.
Both of those are wrong, and in the same way. They assume the work stays the same shape and we simply do more or less of it. What actually happens when execution gets cheap is that the work changes shape. The bottleneck moves. And the team you need on the other side of that move looks different from the one you have, not smaller, different.
When doing gets cheap, deciding gets expensive
Here is the shift in one line. For most of the history of software, the scarce thing was doing: writing the code, producing the draft, building the thing. Judgment was cheap relative to execution because execution soaked up almost all the time. Agents invert that. When the doing becomes fast and nearly free, the scarce, expensive, value-determining work is everything around the doing. What is worth building at all. Whether the output is actually correct. Who is accountable when it reaches a customer.
None of those got cheaper. If anything they got harder, because there is now far more output to judge and far less friction slowing down a bad idea on its way to production. A team that can generate ten times the work but cannot tell good work from plausible-looking wrong work has not become ten times more productive. It has become ten times faster at shipping things nobody checked. The leverage did not disappear. It moved from the keyboard to the decision.
The roles that matter more now
Follow that shift and it tells you which capabilities appreciate in value. Three stand out, and I now weight them above raw execution speed in almost every hire.
The first is problem framing. An agent is extraordinary at answering a well-specified question and useless at deciding which question is worth asking. The person who can take a vague, political, half-formed business problem and turn it into a crisp specification, with the edge cases named and the success criteria agreed, is doing the part the agent cannot touch. That skill used to be a nice-to-have on top of coding ability. It is now the main event.
The second is verification, which I mean in the strong sense. Not clicking approve, but being the person who can look at a fluent, confident, authoritative-sounding answer and know, often quickly, that it is wrong. That is a deep skill. It requires domain mastery and a trained skepticism that most organizations have historically undervalued because, when execution was slow, bad output was rarer and easier to catch. Now the output is fast and infinite and superficially excellent, and the ability to reject it well is worth more than the ability to produce it.
The third is ownership. Someone has to put their name on the outcome. An agent cannot be accountable, it can only be used. The human who says "this is mine, I stand behind it, and I will answer for it if it breaks" is providing something no model provides, and it is the thing that lets an organization actually move fast without becoming reckless. Accountability is not a personality trait here. It is a role, and it has to be assigned.
The trap of the team of one
The seductive misreading of all this is the ten-times engineer who needs no one else, the lone operator with a swarm of agents replacing a whole department. It makes a great headline and it is a trap, because it quietly assumes the hard parts scale for free. They do not. The framing, the verification, the ownership, the judgment about trade-offs, that load grows as output grows, and one person holding all of it becomes the bottleneck and the single point of failure at the same time.
What actually scales is a team deliberately organized around the new division of labor. Agents do the execution. People do the deciding, and they do it as a team precisely because judgment benefits from more than one informed perspective, the same way code review always did. The shape changes. The count does not collapse. The teams that survive this will be the ones that stopped equating headcount with typing capacity and started equating it with judgment capacity.
What to hire for now
This changes the hiring bar in a way I have found uncomfortable but clarifying. I care less than I used to about how fast someone produces and more about whether they can specify, decide, and verify. I would rather have a person who writes less code but can tell, reliably, when the generated code is subtly wrong, than a prolific producer who cannot. I look for comfort with ambiguity, because framing lives in ambiguity. I look for the instinct to ask "but is this actually right, and how would we know," because that instinct is now load-bearing. And I look for people who want to own outcomes rather than complete tickets, because tickets are becoming the cheap part.
Experience changes meaning too. The value of a senior person was never only their output. It was their judgment, their pattern recognition for what goes wrong, their taste. That part just became the most valuable thing they bring, which is the opposite of the lazy assumption that experience is the first thing automation makes redundant.
What a leader does differently
So I organize differently. I structure teams around outcomes and ownership rather than around tasks and functions, because tasks are what agents absorb and outcomes are what humans must still hold. I make accountability explicit, a named person for every consequential thing that ships, never diffused into "the system did it." I invest in the verification layer as real work with real headcount, not an afterthought bolted on when something breaks. And I try to measure the throughput of good decisions rather than the volume of output, because output is now the cheap and misleading metric.
The uncomfortable part for a leader is that this is harder to manage, not easier. Measuring typing was simple. Measuring judgment is not. But that is the actual job now, and pretending the old metrics still capture value is how organizations convince themselves they are winning while they quietly ship more and more unchecked work.
Where this goes
I do not think AI makes human work less important. I think it makes it more concentrated, more consequential, and harder to fake. The parts of the job that were always the real job, deciding what matters, judging whether it is right, owning the result, become almost the whole job, and the parts that were incidental fall away. That is a better job, by any fair measure, for the people suited to it, and a disorienting one for anyone who built their identity on being fast at the part that just got automated.
The leaders who get the next few years right will not be the ones who used agents to shrink their teams. They will be the ones who used agents to move their best people up the stack, out of execution and into judgment, and who redesigned the team around that move. The scarce resource was never labor. It was good judgment applied to the right problem. It still is. There is just a lot more need for it now, and a lot less patience for anything else.
I am working this out in real time like everyone else, and I would genuinely like to compare notes. If execution has become cheap on your team, what has become your real bottleneck, and how are you reorganizing around it.
I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.
Top comments (0)