The traditional software engineering team is dead. Not dying. Dead. And if you’re still staffing projects with six to eight engineers because „that’s how we’ve always done it,“ you’re burning money and you don’t even realize it yet.
Let me explain.
The Old Playbook
For decades, we’ve had this comfortable formula. You get a staff engineer or a strong senior to set the technical direction. You pair them with a couple of mid-level engineers who can carry their own weight. Then you fill in the rest with four to six juniors who do the bulk of the implementation work. It fits the two-pizza rule. It gives you a nice mentorship pipeline where juniors learn from seniors and eventually level up. Organizational growth happens naturally. Everyone’s happy.
And honestly, it worked. It worked really well for a really long time.
But the environment those teams operated in no longer exists.
Enter the Centaur
I recently came across the concept of the „Centaur,“ a new team model that’s starting to gain traction in forward-thinking engineering orgs. The idea is brutally simple. You start a project with one senior architect, two AI reliability engineers, and a fleet of AI agents doing the actual implementation work.
That’s it. Three humans. A bunch of agents. Ship it.
The senior architect handles all the strategic thinking. System design, boundary definitions, component interfaces, the high-level stuff that requires years of experience and judgment. They write the design docs. They set up the testing harnesses. They make sure the architecture can actually scale. All the things a great senior engineer has always done.
The two AI reliability engineers? They’re the humans in the loop. They oversee the agents, review what they produce, and make sure nothing catastrophic ships. Think of them as quality gatekeepers with a very different job description than what we used to call „junior engineer.“
So effectively, you’ve cut your team in half. Maybe more.
This Isn’t Actually New
Here’s the thing nobody wants to hear: the senior engineer was already doing most of this work. A great senior engineer sets up the right testing infrastructure. Unit tests, integration tests, end-to-end tests. The whole harness that lets less experienced engineers move fast without breaking things. They design the architecture and validate it with performance tests. They write the documentation that onboards new team members and gives strategic guidance to the existing ones.
The junior engineers? They followed the system design guide. They complied with the structure. They worked within the harnesses. And they learned from that process, which is how they leveled up into mid-level and eventually senior engineers.
But now all of that documentation, all of those design guides, all of those architectural constraints? They’re going straight into the context window of an AI agent. And the agent is doing the work of a junior engineer. Faster. More consistently. At 50 tokens per second.
Let’s do the math. That’s roughly 20 words per second. A human developer can’t even read that fast, let alone write code at that pace. The execution speed alone makes the case for smaller teams, because you need fewer people to produce the same output. And smaller teams mean less communication overhead, fewer standups, fewer Slack threads, fewer „quick syncs“ that eat your entire afternoon.
You actually gain effectiveness by cutting headcount. That’s the uncomfortable truth.
The Junior Engineer Problem
Now here’s where it gets genuinely tricky. If juniors aren’t writing code anymore, they’re not learning the fundamentals. They don’t know how to structure a codebase from scratch. They don’t build the muscle memory of writing unit tests. They never struggle through designing the right interface between two components. All that foundational work that used to be their training ground? It’s gone.
But does it need to exist?
I think the answer is more nuanced than most people want it to be. The junior engineer’s focus is shifting upward. Instead of implementing a function that follows a design doc, they’re now thinking about system design itself. How do components interact? What are the right boundaries? Should we communicate over the network or through a shared library? Monolith or microservices? These are the questions they’re engaging with now, and honestly, these are more valuable questions than „how do I write a for loop.“
The junior is still leveling up. Just differently. They’re learning architecture and system thinking earlier in their career. They’re reviewing AI-generated code, which, while it sounds sketchy, is actually a decent learning experience. When you read well-structured code and ask yourself „why did it do it this way?“, you’re learning. Maybe not the way we learned, but learning nonetheless.
The Uncomfortable Question
But let’s not sugarcoat it. Is it really a good idea to have someone review code when they might not fully understand what the agent produced? If you’ve never written a database migration by hand, can you really catch a subtle bug in one that an AI generated?
This is the talent pipeline problem. We can’t just staff teams entirely with senior architects who do all the thinking and reviewing. We’ll run out of seniors. And if juniors never get deep technical experience because agents handle all the implementation, where do the next generation of seniors come from?
Uncle Bob had a point when he said you’re responsible for learning the skills yourself. The company isn’t going to train you. And honestly, it’s never been easier to level up on your own. You have access to the entirety of human knowledge through tools that can explain things at exactly your level and pace. You can ask an AI to teach you system design, give you exercises, drill you on fundamentals. The resources are infinite.
But you still have to do the work. Reading about unit testing doesn’t make you good at it. You need to get your hands dirty. The question is whether companies will give juniors space to do that, or whether the economic pressure to ship faster will squeeze that learning time out entirely.
The Bigger Picture
If you zoom out, the trend is undeniable. We need less and less human effort to ship products. The percentage of solo founders jumped from 20% to 30% over the last year alone. One person can now build and ship what used to require an entire team. That’s not a blip. That’s a structural shift.
So what do you do with the engineers you’ve freed up by shrinking teams? You’ve got two options. You fire them, which is what a lot of companies will do because short-term cost savings are irresistible to CFOs who don’t understand engineering. Or you redeploy them into new projects and new products, which is what smart companies will do because the bottleneck was never talent. It was always coordination cost.
Smaller teams, more teams, more products, faster iteration. That’s the play.
The engineers who thrive in this world won’t be the ones who can write the most code. They’ll be the ones who can think clearly about systems, design good boundaries, and manage a fleet of AI agents that do the heavy lifting. Whether you’re a senior architect setting the vision or a junior AI reliability engineer overseeing the execution, the game has changed.
The only question is whether you’re going to adapt or pretend it’s still 2020.
Peace, nerds.