The Re-Soloing
One engineer with AI agents is outproducing entire teams. Not because the engineer is special — because the coordination overhead is gone.
Kent Beck recently used the term re-soloing to describe what's happening in software development right now. Engineers are going back to working alone — not because collaboration failed, but because AI agents made the solo engineer disproportionately powerful.
I've been living this shift. And it's more nuanced than it sounds.
What Teams Actually Were
Think about what happens when five engineers work on a feature together. On paper, it's collaboration. In practice, most of the time goes to coordination.
Alignment meetings to make sure everyone's heading in the same direction. PR reviews where you wait hours or days for someone to look at your code. Slack threads to resolve ambiguity in a ticket someone else wrote. Sprint planning to negotiate what goes into the next two weeks. Retros to discuss how the last two weeks went. Standups to report what everyone already knows.
The actual building — the part where fingers hit keyboard and problems get solved — happens in the gaps between all of that. And those gaps keep shrinking.
This isn't a criticism of any specific team. It's structural. The more people involved in a piece of work, the more coordination it requires. Brooks knew this in 1975. We just kept pretending we'd solved it with better processes.
What Changed
AI agents don't need alignment meetings. They don't have timezones, opinions about naming conventions, or a strong preference for tabs over spaces. They don't go on vacation, get pulled into another project, or spend 40 minutes in a standup inventing something to say.
When I work with agents now, the workflow looks like this: I define the problem, set the constraints, and let the agent execute. If the output isn't right, I refine the prompt and iterate. There's no waiting. No negotiating. No context-switching because someone pinged me about an unrelated PR.
The result is that the coordination overhead — which used to consume 40-60% of an engineering team's time — drops to nearly zero. What's left is pure problem-solving.
One person with agents can now move through work at a pace that used to require a small team. Not because the person is exceptional, but because the friction is gone.
You're Not Managing a Team
There's a tempting narrative: "I have six agents, so I'm managing a team." Kent Beck pushed back on this, and he's right. Running multiple agents isn't management. It's using powerful tools in parallel.
Management implies bidirectional communication, growth, mentorship, disagreement, surprise. An agent doesn't push back on your architecture decision because it saw something similar fail at a previous company. It doesn't suggest an approach you'd never considered because it has a completely different mental model than yours.
This distinction matters. When you mistake tool usage for leadership, you lose sight of what's actually happening — and what you're actually giving up.
What's Lost
Here's where I refuse to be triumphalist about this. Something real is disappearing.
The unexpected idea. A teammate who sees the problem from a different angle. Who says "wait, why are we even building this?" in a way that redirects the entire project. Agents are powerful executors. They are not good contrarians.
The mentorship loop. Junior engineers learn by sitting next to senior ones, by having their PRs reviewed with real context, by absorbing patterns through osmosis. If senior engineers are all re-soloing with agents, where does the next generation learn? This isn't a hypothetical — it's happening now.
The human challenge. Working with people is hard. Navigating egos, aligning perspectives, building trust — it's exhausting, but it's also where growth happens. The messy social process of building software together makes you a better engineer and a better person. Agents make you faster but they don't make you grow.
Beck and Fowler built Extreme Programming specifically to create safe, productive social environments for engineers. Pair programming, mob programming, constant communication. That produced remarkable results. Re-soloing trades all of that for speed. Whether that trade is worth it depends entirely on what you're optimizing for.
Nowhere to Hide
There's a harder truth embedded in the re-soloing trend. On a team of ten, it was possible to coast. Not maliciously — just by blending into the coordination work. Attending meetings, writing status updates, reviewing PRs at a leisurely pace, participating in discussions without driving outcomes.
AI strips that camouflage away. When one person with agents can do what five people did before, the question becomes unavoidable: what is each person actually producing?
Kent Beck calls this the "mid pack" — engineers who got into programming as a career rather than a craft. During the Agile era, they had to adapt or leave. With AI, the adaptation required is steeper and the timeline is shorter.
This isn't about talent. It's about engagement. Engineers who are curious, who invest in understanding their domain deeply, who treat agents as amplifiers for their craft — they'll thrive. Engineers who were relying on team dynamics to carry them will find that the team is getting very, very small.
The Amplifier, Not the Replacement
Martin Fowler frames AI as an amplifier, and that's the most honest description I've heard. Good engineers become great. Fast learners become faster. Curious people explore more. The tool doesn't replace the person — it reveals how much of "the work" was always overhead.
When you remove the coordination tax, what remains is your actual contribution: your taste, your judgment, your ability to define the right problem, your domain knowledge, your standards. Those things were always what mattered. They were just buried under process.
The re-soloing isn't about isolation. It's about clarity. One person, clear intent, powerful tools, no friction. That's the new baseline.
What Now
I don't think teams are dead. Fowler's bet — that two-pizza teams become more effective rather than smaller — might be right for many organizations. Complex systems still need multiple human perspectives. Large-scale projects still need coordination that agents can't provide.
But for a growing number of engineers, the math has changed. The overhead of collaboration now exceeds its value for many types of work. And when that happens, the rational move is to re-solo — not out of antisocial preference, but out of respect for your own time.
Time is the finite resource. Every hour spent in coordination that agents could eliminate is an hour not spent building. Every meeting that could have been a prompt is an hour of shipping you don't get back.
The re-soloing is here. The question isn't whether it's happening — it's whether you're using the quiet to build something worth building.
Related Reading
Your Meeting Could Have Been a Prompt
Your Code Has Bugs That AI Will Find Before You Do
