I do not like saying this, but I say it because it is true: where we used to need twenty developers, five very good people with several agents will soon be enough. Smaller, faster, and the cost per feature drops massively.
Let's be honest first
Fact is: this is not a vision. We see it in our projects today. A coding agent delivers in minutes what took a developer hours or days. And we are really only at the beginning.
You can find that terrible. You can ignore it. Or you can ask yourself how to rebuild a team so that in the end there are five people who really carry the system, and not five who happened to be left over.
How it goes wrong
The wrong way is the one I see a lot right now. A company buys coding agents for everyone. A few people get fast, most do not. After a year, costs get cut, and the ones who leave are those who cost the least or stand out the least.
What remains is a team put together by accident. Maybe the right people are in it. Probably not. And the knowledge of why the system is built the way it is has left with the wrong people.
Who stays, and why
The five who stay are not the five fastest programmers. Programming is becoming a commodity.
They are the ones who understand the system. Who know why an interface is the way it is. Who can decide which pattern applies where. Who have domain knowledge: banking, telecommunications, medicine, whatever the company does. And who can handle the fact that agents write most of the code and they "only" decide, check and lead.
That is often not the person who delivered the most lines so far. Sometimes it is the one who always asked the uncomfortable questions in review.
The transition
How do you do this without the team falling apart? I have no formula for it, but a few things that have worked.
Say openly what is happening. People know anyway. Whoever pretends nothing is happening loses the good people first, because they are the first to notice they are being lied to.
Rules before tools. Before an agent writes code, the team has to write down its architecture. That is work everyone does together, and it shows very quickly who understands the system.
Let roles change. Whoever writes code today can write contracts tomorrow, define QA rules, lead agents. Not everyone wants that. But everyone should get the chance to find out.
Save the knowledge before the people leave. Whoever leaves first puts their reasoning into a form agents can work with. Not as a farewell document, but as a rule in the system.
And the other fifteen?
That is the question nobody asks, and one I do not want to dodge.
Some of them will do elsewhere what they did here, just at companies that are not that far yet. That lasts a few years.
Some will learn something new. Not programming, but what programming was needed for: understanding problems, leading systems, building domain knowledge. That is possible, and I have seen it. But it does not happen by itself.
And some will change careers. That is the truth, and anyone who says otherwise is selling something.
What I can do as a founder is shape the transition so that as many people as possible get a chance at the second path. Not by going easy on them, but through clarity and through time.
Teams are getting smaller. That happens either way. Whether the right five are there in the end is the only decision you can still influence. And it has to be made now, not when costs get cut.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.