Picture a colleague in a technical team a couple of years ago. They sat at a keyboard and did the work themselves. If you gave them a job, the speed of that job was simply how fast that one person could think and type. To go faster, you hired another person.
That picture is now out of date. The same person is still there, but more and more they are not the one doing the work. They are directing a small group of AI workers who do pieces of it at the same time, while the person plans, assigns, and checks. The keyboard is no longer the bottleneck. The thinking is.
This is the single most useful thing to understand about how technical work happens now, and you do not need to know anything about computers to grasp it. It is a story about how a team is organised. We have all seen a one-person shop turn into a managed team. That is exactly the shift, just faster, and with workers that happen to be software.
Here is the part most people get backwards. The exciting version, where you set a clever machine loose and it does everything on its own, is not the version that works best. The reliable version is almost boring: break the job into small, clear pieces, hand them out, and have a human check the results. The teams who do this well are not the ones who removed themselves from the work. They are the ones who moved to the right seat.
Let us walk up the ladder, one rung at a time. Each step is a different way of organising the work. Each diagram shows who is doing what, and where the work flows.
The soloist
You and one helper, taking turns. You ask, it answers, you read it, you ask again. Simple and easy to follow. The catch: nothing happens unless you are in the loop. You are the ceiling.
This is a manager who refuses to delegate. Capable, in control, and completely capped by their own hours in the day. Fine for small jobs. A wall for big ones.
Handing out the work
Now you stop doing the tasks yourself. You break the job into clear briefs and give each one to a focused worker. Some can run at the same time. Some have to wait their turn, because one task needs another to finish first. This is the move every growing team makes: an org chart appears.
A team lead assigning tasks on a Monday. Two people start straight away on independent pieces. The person writing the summary has to wait for both of them to report back. Nothing exotic, just delegation.
This already breaks the soloist's ceiling. Three pieces of work move while you watch. But notice what the lead is doing: holding the whole plan in their head, remembering who is blocked on what, stitching the pieces together. When the job gets big, that juggling becomes the new bottleneck.
The team that talks to itself
The next step is the big one. The workers no longer just take orders and report back. They share a task list, pick up jobs themselves, and message each other directly. When one finishes a piece another was waiting on, the waiting one unblocks on its own. The lead is freed from being a switchboard.
A well-run team with a kanban board. People grab the next card, talk to each other when they need to hand something over, and the manager spends their time on direction and review rather than relaying every message.
How much does this actually help? The clearest published number comes from the company Anthropic, which built a research system on exactly this shape. A team of AI workers, a lead plus several specialists working in parallel, beat a single AI worker on the same job by a wide margin on their own internal test.
Hold both of those numbers at once. The team is dramatically better and dramatically more expensive. Anthropic was blunt about why it works at all: mostly because more workers means more total effort spent on the problem. On one benchmark, the sheer amount of work thrown at a task explained about 80% of how well it went. Power, quite literally, has a price. That is why you do not reach for a team when one worker will do.
The revision loop
Good work is rarely right first time. So one of the most useful patterns is a loop: make an attempt, check it, fix what is wrong, try again. The important detail is a hard stop, so it cannot spin forever on the same mistake. After a few tries, it gives up and asks for help instead of grinding away.
A draft sent for review, marked up, redrafted. We do this instinctively. The only new idea is writing down the rule "after three rounds, escalate" so the loop cannot quietly eat a whole afternoon.
The quality gate
As the team grows, you add a dedicated checker. Nothing counts as finished until it passes review. The benefit is simple: the person in charge only ever sees work that has already been checked. Bad work gets caught and sent back before it lands on their desk.
Quality control on a production line, or an editor before a piece is published. The reviewer is not a luxury. It is the thing that lets you trust output you did not personally inspect.
The whole thing as a production line
Put it all together and the job is no longer "do the work." It is "run the line that does the work." Plan it, hand it out, keep an eye on it, check what comes back, fit the pieces together, and write down what you learned for next time.
This is the whole shift in one picture. You climbed from doing the work, to handing it out, to running a self-organising team, to overseeing a line. At no point did the human disappear. The human moved.
The one rule worth remembering
Every stage above sits on a single line, from "you control every step" to "the workers decide for themselves." Further right is more powerful and less predictable, and it costs more. Further left is cheaper, calmer, and easier to trust.
The mistake everyone makes is reaching for the right-hand end because it sounds impressive. The rule the best teams actually follow is the opposite: use the simplest setup that does the job, and only move right when you have a real reason. A team of workers that costs fifteen times as much is the right call for a hard, sprawling problem. It is the wrong call for something one worker could finish in a minute.
What stays human
If the workers do the doing, what is left for the person? The valuable part, as it turns out. The bottleneck has moved from making the work to making sure the work is right, and that second job is harder, not easier.
Hand to the workers
- The repetitive, well-defined tasks
- Anything with a clear right answer to check against
- Trying several approaches at once
- The groundwork and the scaffolding
Keep for yourself
- Deciding what to build, and what not to
- The clear brief: vague instructions multiply into vague results
- Judging whether the result is actually good
- Understanding the whole, which no single worker ever sees
There is a neat piece of evidence for keeping the brief human. Researchers at ETH Zurich looked at the written instructions teams give these AI workers. Instructions written by a person gave a small but real improvement. Instructions written by the AI itself gave no benefit, sometimes made things slightly worse, and cost more to run. The human judgment about what matters is not a formality. It is the part that pays.
The deeper reason to stay involved is uncomfortable. When a person does the work slowly, small mistakes hurt early and you fix them as you go. When a fleet of workers does it fast, small mistakes pile up faster than anyone notices, until one day the whole thing is tangled and no one understands it well enough to fix it. The checking is not red tape. It is the brake that stops a fast car from driving into a wall.
Trying to make sense of this in your own organisation?
Fractional CTO and transformation leadership for teams figuring out how to work with AI sensibly. Bring a problem — thirty minutes, no obligation.
Bring a problem → or read more first →Sources: Anthropic, "How we built our multi-agent research system" (June 2025). Addy Osmani, "The Code Agent Orchestra" (O'Reilly AI CodeCon, March 2026). AGENTS.md finding: Gloaguen et al., ETH Zurich. Pattern taxonomy from Antonio Gulli, "Agentic Design Patterns" (Springer, 2025). All examples are original implementations from the ticketyboo.dev platform.