Watch a good Fleet Lead work for an hour. Six agents in flight at once. Two are drafting against different halves of the spec, one is writing harness checks from the criteria, one is grinding through a migration, and two are parked, waiting on a judgment call their operator will make between other judgment calls. Work merges, checks run, something lands. A refactor that would have been a two-week argument goes in quietly before lunch. It looks less like programming than like conducting, and the throughput coming off one desk is, frankly, a little absurd. The six is a soft count, too. Agents spawn agents when the work splits, the pattern production orchestrator systems already run [1], and the formation swells and thins by the hour. In the work we run, the spikes reach scores of agents under one orchestrator when the day calls for it.
Now ask the fleet, tomorrow morning, why it made any of yesterday's choices. It cannot tell you. Not because it is being evasive, but because there is no it to ask. As of this writing, every session starts new. The instances that built yesterday's increment have no memory of building it, no memory of the system they built into, and no stake in what happens to either. Vendors are working on continuity, and some of it will arrive. A longer log is still a log. The most productive builders ever pointed at enterprise software arrive every morning as strangers to their own work, and even the versions that remember more will remember the way a filing cabinet remembers. And if that someday changes too, human accountability still has to be along for the ride, because no enterprise gets to tell a regulator, a customer, or a court that the machine was the one who understood.
That is the strange shape of machine production. Infinite diligence, zero tenure. And when the builders cannot hold what they build, holding it becomes someone's whole job.
Naur's warning
In 1985 the Danish computer scientist Peter Naur wrote a short paper called "Programming as Theory Building," and I think it is the most important thing ever written about what programmers actually do [2]. Naur argued that a program is not its source text. The program is a theory, held in the minds of the people who built it, about how the code and the world it serves fit together. The text is a projection of the theory, and a lossy one. Hand the text to a new team without the theory and they can modify it, but their changes fight the design in ways they cannot see. When the original team disperses, Naur said, the program dies, even though the text survives perfectly.
He was writing about people. Forty years later his paper reads as a diagnosis of the fleet, because agent production is theory-free by construction. The fleet emits text at machine speed while the theory accumulates in no one. Left alone, that produces a system where every day's work is locally reasonable and globally incoherent, each increment correct against its spec and slightly wrong against the whole, the way a city looks when every building got a permit and nobody held the map.
This flips an old sentimentality, too. We used to treasure the text and let the understanding walk out the door in resignations and reorgs. Now the text is the cheap part, the cheapest it has ever been. The fleet will refactor anything you point it at, tomorrow, for close to nothing. What cannot be regenerated at any price is the understanding underneath it, and holding understanding is the thing humans still do best. Machines store, and storage is not holding. A stored decision cannot notice the moment it becomes relevant. A held one can. Naur's point was always that the holding is the work. It took forty years and a fleet before the industry could afford to agree with him.
The industry has met smaller versions of this problem before, and it is worth noticing that every era solved it the same way, by putting scarce technical judgment inside a deliberate structure. The chief programmer teams of the early seventies organized a whole team around one person who held the design intact [3]. Fagan's inspections showed that defects fall when qualified eyes review work at the right level, rather than every level [4]. Parnas taught the field to decompose systems along the lines that minds can actually hold [5]. And Lehman's laws established that software in use never stops changing, and grows more complex unless someone continually spends effort against the drift [6]. Different decades, one lesson. The text was never enough. Somebody has to hold the theory, and the holding has to be organized.
The Fleet Lead
In the AI-native operating model, the people who hold it are the Fleet Leads. One to three in a crew, the human component of the fleet itself. And let me be clear about what kind of role this is, because the memory framing can make it sound like a librarian. These are fleet drivers. Knowledge-holding dispatchers of agentic coders. It is a delivery role, maybe the purest delivery role left. A Fleet Lead ships, daily, inside the one-day cycle, and their instrument is a fleet of model instances run in parallel, a thing that requires real human skill to do well. The visible craft is orchestration. Splitting the spec so agents do not collide, Parnas's old module lines now deciding what can build in parallel. Matching which model to which task. Knowing what has to wait on a decision and what does not. Keeping enough work in flight that machine time is never idle, and never unwatched either. People who are good at this develop a rhythm you can recognize from across the room, and in the work we are running with pioneering enterprises, the good ones out-deliver the departments they came from.
And they do not work from a blank page. The Fleet Lead operates inside a system where context is managed as seriously as source code. Context packs hold the codebase's conventions, its prior decisions, its constraints, the edge cases that used to live in nobody's documentation, the mirror of the business context the Decision Owner brings, maintained to standards the whole organization is held to and refreshed as the work teaches. The craft is not assembling that library every morning. It is working within it, pulling forward exactly what today's increment needs and leaving out everything that would dilute the fleet's attention. Agents rarely fail when the work is hard. They fail when something was not stated, and they drown when everything is.
The Fleet Lead reviews at altitude. When the fleet produces several times more implementation in a day than a person can read, line-by-line review stops being possible, and pretending otherwise is how defects get waved through behind a ritual. So the Fleet Lead reviews contracts, interfaces, data handling, failure paths, and anything that touches policy, and reads lines only where risk concentrates, and the lines they do read, they read hard. The skill is knowing where to look. A lead who reviews everything equally reviews nothing well.
Then there is the craft Naur predicted. The Fleet Lead carries the architecture, the accumulated why of the system. Why this service uses this pattern. Why that field is nullable when the business rule says it should not be. Those answers are human decisions made for human reasons, invisible in the code, and the Fleet Lead injects them into the fleet's context at the moments they matter. This is the part that cannot be delegated to the fleet at any capability level, because it is knowledge about intent rather than about code.
The last judgment is when to step in. A fleet that is looping rather than progressing burns compute and hours, and looping has a look once you have seen it, the same diff coming back wearing different comments, confidence rising while progress stalls. A lead who grabs the keyboard because it would be faster to do it themselves has quietly become a solo developer with expensive tools. Between those two mistakes sits a judgment call made a few times every day, and the pattern of those calls is one of the best health signals the team has.
One review inside all of this outranks the rest. The fleet separates its own concerns, spec agents drafting the contract, build agents implementing against it, test agents writing the harness coverage from the spec's criteria. That last separation is load-bearing. An agent that writes tests against its own implementation converges on tests that pass, which is not the same as tests that prove the spec. A green harness that proves nothing is worse than a red one, and confirming that the checks trace to the criteria is the single most important thing a Fleet Lead reviews.
Fleets and crews
The team changes shape around all of this, and the industry has noticed. The names in circulation are breathless, one-person unicorns, tiny teams, the ten-person company that looks like a thousand. Under the breathlessness sits a real observation. Teams as we have known them were sized to production. It took eight or ten people to type an increment into existence, so eight or ten people is what a team was, and a generation of research documented the cost. Hackman showed that coordination load climbs with every added member, the links between people multiplying far faster than the hands [7]. A ten-person team is forty-five conversations wide, and the scaling frameworks existed largely to manage that arithmetic at portfolio size, the story told in The Scaling Frameworks Had It Right. The World Changed. We paid the tax because we needed the typing.
We use plainer names for what replaces it. The unit of production is the fleet, and every fleet has a human lead. The humans wrapped around a fleet, the owner, the lead, sometimes a second specialist, are a crew. A crew of three is three conversations. The parallelism that used to demand headcount now runs on machines, and machine parallelism creates no coordination channels between humans at all. The crew is small so the scarce thing, aligned human judgment, stays undiluted.
So what happens to the arithmetic on the machine side? Agents are not silent. They coordinate constantly, and a fleet in flight is thick with channels. The difference is what a channel is. When two humans coordinate, each carries away an interpretation, and interpretations drift, which is why shared understanding needs meetings and meetings need calendars. When two agents coordinate, they pass artifacts, the spec, the diff, the failing check, and the copy received is identical to the copy sent. Better still, most agent coordination is not pairwise at all. The fleet converges on shared artifacts the way a road crew converges on the drawings, every agent aligning to the same spec and the same harness without ever addressing another agent directly. That topology is a hub, not a mesh. It scales linearly, it never tires, and it keeps no calendar, which is why Hackman's curve does not bind machines.
What replaces the old law is a sharper one. A lossless network propagates everything losslessly, including mistakes. One wrong assumption, injected at the hub, reaches the whole formation with perfect fidelity and none of the immune response a human team's friction used to provide. The communication bottleneck is gone. The judgment bottleneck it was hiding is now the whole game, and it sits exactly where this model puts its people, at the spec, at the context pack, at the harness, at the hub.
Small does not mean junior, and this is where the skillset gets serious. Everyone on a crew works through the fleet rather than beside it, and that takes a fluency the industry has not had to teach before. It means writing intent precisely enough for machines to act on. It means curating context packs, the assembled sets of systems, vocabulary, edge cases, and history the fleet works from, and knowing what belongs in one and what is noise. It means reading machine output with a nose for plausible and wrong, and knowing what a green harness run does and does not prove. None of it is prompt tricks. It is the working style of a person whose leverage is a fleet, and it is learnable in weeks by people who spent careers building the judgment underneath it.
And the fluency is not left to osmosis. Teaching it, holding the standard for what a good spec and a good context pack look like, is the work of the Intent Architect, the discipline described in Intent Architecture. Crews are not stranded alone with a new skillset. There is a role whose whole job is raising the bar they work against. The judgment is the hard part. The crew is the shape that concentrates it.
The working pair
The role does not stand alone, and was never meant to. In Decision Ownership I described the business half of judgment at machine speed, the owner who says what is needed and accepts what arrives. The Fleet Lead is the technical half, the one who says how it will be built and whether the criteria are checkable. They function as a working pair, not a handoff. Three to six questions between them on a build day is healthy. Zero means someone is guessing. And the parked lanes in the picture above are not benign. A fleet stalled on an unanswered question burns a build day, the cost of waiting drawn small. The daily traffic compounds, too. Within weeks a working pair has a shorthand, and the shorthand is itself an asset, the human bandwidth of the crew.
And the pairing scales, because fleet capacity is a real capacity question rather than an unlimited one. A fleet is not even a fixed headcount. Agents spawn agents when the work splits, delegating downward the way the cascade delegates, so a sizable fleet can emerge from one morning's spec and be gone by night. That makes the capacity discipline more necessary, not less. The binding constraint is not agent availability. It is how much output one person can meaningfully review at altitude, and the honest way to find that number is to start conservative and measure where review quality degrades. An organization that treats the fleet as infinite gets cost surprises and a review bottleneck. One that treats it as metered can actually plan.
The instinct the role retires
The best senior engineers earned their standing at the keyboard, and that history produced a deep instinct. When it matters, do it yourself. Fleet Leadership asks those exact people to retire that instinct. Something real is given up when the hands come off the work. There was a particular satisfaction in typing the fix yourself at midnight, and no honest account of the role pretends otherwise.
But the alternative ditches are both visible now. On one side is the hero, still personally writing the critical path while a fleet idles, a keyboard placed back in the middle of the throughput. On the other side is the failure that got a name in 2025, when Andrej Karpathy coined vibe coding for the practice of accepting whatever the model produces and forgetting the code even exists [8]. He was describing weekend projects, and as a description of weekend projects it is charming. Run an enterprise system that way and you have done something worse than under-review the text. You have delegated the theory itself, and Naur already told us what a system without a theory is. Dead, with the text surviving perfectly.
The Fleet Lead is the seat between those ditches, and it is not a hands-off seat. The hands move up a level, from the code to the choreography.
Where the theory meets the text
One question hangs under all of this. If the fleet writes all the code, does anyone still need to read it? Fast-forward to the world where nobody can. The fleet emits systems no human is able to audit, the checks say green, and the organization takes the machines' word for it, because taking their word is the only option left. Review at altitude is gone, since altitude review still lands on lines where risk concentrates, and now nobody can land. The harness still runs, but a harness only proves what someone once knew to ask, and the someones are gone. The theory, wherever it survives, has come unmoored from the text it is supposed to explain. Naur's dead program, except this time nobody can even attempt the revival, because revival means reading.
Every version of that scenario ends the same way. The organization becomes a passenger in its own systems, polite, hopeful, and unable to check. Which is why fluency in the language of code does not retire with the typing. Aviation learned this decades ago. The autopilot flies most of every flight, and we still put certified pilots in the seat, not to work the controls all day but because the person responsible must be able to take them. The Fleet Lead is that requirement, standing precisely at the junction Naur pointed to, where the theory meets the source text. Fluent upward in intent, fluent downward in code, able to descend into the text on the day it matters and know what they are looking at. Production no longer needs human hands. Accountability still needs human reading. The equation does not balance without a person at that junction, and the model does not pretend otherwise.
The way in
That junction is also where tomorrow's junior developers enter the workforce. The worry about them is everywhere, and it is not silly. The tasks juniors used to learn on, the small tickets, the starter bugs, the well-bounded features, are exactly the tasks fleets absorbed first, and an industry that eats its own entry path eventually starves. If the bottom rung is gone, where do Fleet Leads come from?
They come from the seat beside one. The old ladder taught by repetition, years of small tickets that were mostly typing with a little judgment attached. The new one teaches by proximity, and it is the better teacher, because the thing a junior needed to absorb was never really the typing. They arrive with a computer science background, code fluency, and orchestration instincts their elders had to learn late, and they spend their first years reading at altitude next to someone who carries a theory, absorbing it the only way theories transfer, by working under one. Naur again. A theory cannot be handed over in a document, which means apprenticeship is not a nicety in this model. It is the only transmission mechanism there is.
The dynamics change. The rungs change. The need for a human in the loop does not go away, and neither does the ladder. If anything the climb is faster, because a junior who spends two years beside a fleet driver watches more decisions get made, and unmade, than the old ladder showed anyone in five.
The one who remembers
Back to the morning. The fleet wakes as strangers to yesterday's work, six of them or sixty, spinning up with perfect competence and no past. And it turns out not to matter, because the memory was never supposed to live in the fleet. It lives in a person, deliberately staffed, carrying the theory of the system across the days the way the machines cannot.
Think about who that person is. They spent twenty years earning the right to be the one at the keyboard, and then gave the keyboard away because the work asked them to. What they kept is the part that was always theirs. The incident that shaped the design. The reason the field is nullable. The name of the constraint nobody wrote down and everybody builds around. On the day something breaks at the worst possible hour, when the harness is red and the fleet is offering three plausible wrong explanations, they are the one who says, quietly, I know what this is. No log produces that sentence. Twenty years produce it.
There is a version of this era's story in which people like that are told they are obsolete, and some organizations will act on that version. They will run fleets with no one who remembers, and for a while it will even look like it is working. The text will accumulate beautifully. Then one day they will need to change something that matters. An agent will pick up the thread, and it will do it startlingly well. Hand one the repo and it will produce a history of the system, coherent, detailed, and delivered with total confidence. That is the part that should worry you, because it will be exactly that good on the days it is wrong. The why that fits the world, the incident that never made the commit message, the promise from a meeting, the constraint that lives in a regulator's letter and not in the repo, was never in the text to be found, and the agent will fill that hole so smoothly that nobody sees there was a hole. The skill cuts both ways at full strength. A resumption that stumbles gets checked. A resumption this fluent gets believed. The organization needed the real history, got a beautiful one instead, and the last person who could tell the difference left in the restructuring.
The organizations that get this right will do something almost old-fashioned. They will find the people who hold the theory, name them, pay them like the fleet depends on them, because it does, and put a junior beside each one so the theory outlives its holder. The text belongs to the fleet now, and the fleet is welcome to it. The theory belongs to someone. It always did. It was never really about the code.
References
- Anthropic (2025). How We Built Our Multi-Agent Research System. Anthropic Engineering, June 2025. An orchestrator agent spawning parallel subagents in production.
- Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5).
- Baker, F. T. (1972). Chief Programmer Team Management of Production Programming. IBM Systems Journal, 11(1).
- Fagan, M. E. (1976). Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15(3).
- Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12).
- Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68(9).
- Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
- Karpathy, A. (2025). On "vibe coding." X (formerly Twitter), February 2025.
Alex Petty is the founder of Singularics. He has spent 20 years leading enterprise transformations and now helps organizations redesign how work is defined and coordinated when AI changes the operating model.
Ready to see the role in practice? The Fleet Lead, its four crafts, fleet composition, and the capacity model, is specified in The AI-Native Operating Model™. Take the free Readiness Assessment to see where you stand, or book a call to talk about what the shift looks like for your organization.