The middle of the org chart is dissolving

Look at a typical engineering team at any mid-to-large tech company. You’ll find something like this:

A VP of Engineering with two directors. Each director manages three engineering managers. Each EM runs a team of eight to twelve engineers (staff, senior, mid, junior) plus a QE or two. Over on the product side, a VP of Product has their own directors and product managers, each PM mapped to one or more engineering teams. A program manager tracks delivery and dependencies across both orgs. A tech lead sets cross-team architecture. Maybe a shared docs writer and a UX designer who splits time across three teams.

That’s 15 to 20 people to ship one feature area. And most of their week isn’t spent building. It’s spent coordinating. Standups, sprint planning, backlog grooming, cross-team syncs, status reports that flow up through three management layers before anyone with budget authority sees them.

This structure made sense when implementation was the bottleneck. You needed bodies to write code, and you needed managers to keep those bodies aligned.

AI agents changed the bottleneck. Implementation got cheap. Coordination didn’t.

What Meta just told us

In March 2026, Business Insider reported that Meta is reorganizing roughly 1,000 Reality Labs employees into small “AI-native pods.” They’re calling the people in these pods “AI builders.” Zuckerberg has been saying, publicly, that 2026 is the year one person can do the work of an entire team.

Meta is not a scrappy startup experimenting with org design. This is a company with tens of thousands of engineers choosing to flatten its structure around AI. The leaked memo described pod leads directing agents for implementation, testing, and review, with cross-functional roles replacing deep hierarchies.

Around the same time, Ran Aroussi published a piece arguing that software agencies should adopt the law firm partnership model. His thesis, which he also presented at DataCamp: the fundamental unit of delivery becomes the “pod,” a small group built around an Architect (the partner) who directs AI agents, a Delivery Manager who handles clients, and one or two juniors learning the trade. Multiple pods operate under a shared firm that provides brand, sales, infrastructure, and a shared profit pool.

These two things are pointing at the same structural shift, just from different angles. Meta is doing it inside a large company. Aroussi is describing it for agencies. The pattern is the same: smaller teams, flatter hierarchies, humans directing agents instead of managing other humans.

Where the people go

Here’s the part that makes people uncomfortable. If a pod has 3 to 4 humans doing what 15 to 20 did before, where do the other 12 go?

Not every role is equally exposed. The jobs closest to “coordinating other humans” or “writing code that agents can now write” are the ones that compress first.

Junior and mid-level engineers are the most exposed group. Not because they’re bad, but because the implementation layer is exactly what agents do well. Writing CRUD endpoints, building standard UI components, wiring up API integrations. This is the work that justified hiring at scale, and it’s the work agents handle today. The juniors who remain in the pod model are explicitly apprentices, not implementers. Fewer are needed, and their job description changes completely.

QE and test engineers face a similar compression. Agents generate tests faster and more thoroughly than manual test writing. When the Architect owns quality directly (which they should have all along, honestly), a dedicated QE org becomes hard to justify.

Program managers track dependencies, run status rollups, flag risks, and schedule meetings. In a 3-person pod, there’s almost nothing to coordinate. The role dissolves not because it wasn’t valuable, but because the coordination tax that created it is gone.

Engineering managers who are primarily people managers hit the same wall. Managing two or three people doesn’t need a dedicated role. Sprint ceremonies, 1:1s, performance reviews for a pod, the overhead exceeds the value. The EM’s job today is largely shielding the team from organizational noise. When the org gets flat enough, there’s less noise to shield from.

Product managers split in two. Strategic PMs who understand markets, users, and positioning survive but operate across pods, not embedded in one team. Tactical PMs, the ones writing tickets, grooming backlogs, and running standups, get absorbed into the Delivery Manager role.

Senior and staff engineers face a fork in the road. The ones who already spend 60% of their time on design and review evolve naturally into the Architect role. The ones who love writing code and take pride in their craft? That’s harder. The pure “senior IC who writes excellent code” role loses value when agents write excellent code too. The skill that matters isn’t typing, it’s judgment.

The roles that gain leverage are the ones where judgment is the whole job. Security engineers, because agents introduce new attack surfaces. Domain experts in distributed systems or ML, because deep reasoning about novel tradeoffs is the hardest thing to automate. And the Architect archetype itself, the person who thinks in systems, reviews more than they write, and makes decisions under uncertainty.

What’s human and what isn’t

The pod model draws a clear line. Humans handle judgment. Agents handle volume.

The Architect makes architecture decisions, orchestrates agent workflows, and reviews every output. They decide what to build and why. They spend 80 to 90% of their time on planning and review, maybe 10% writing code themselves. The Delivery Manager owns the client relationship, scopes work, manages expectations, and translates between business needs and technical reality. Clients need a human who takes accountability for the outcome. Juniors learn by watching the Architect make decisions under pressure, not by writing boilerplate.

Agents handle implementation, scaffolding, migrations, bug fixes, test generation, documentation, and first-pass code review. The Architect directs them the way Aroussi says a law firm partner directs associates: with clear specs, quality standards, and review checkpoints.

The firm’s shared services, design, DevOps, marketing, legal, sit somewhere in between. The creative direction is human. The execution is increasingly automated. A designer sets the design system; agents generate the components. A DevOps engineer architects the platform; agents write the Terraform.

The boundary is judgment. Anywhere a decision requires taste, context, empathy, or accountability, you need a human. Anywhere the work is applying known patterns to known problems at speed, agents are better.

The talent cliff nobody’s planning for

Here’s the thing that bothers me about this model. It has a hole in the middle, and it’s the same hole the entire industry is ignoring.

If juniors aren’t writing code, how do they develop the judgment that makes a great Architect?

Aroussi’s answer is apprenticeship. Juniors learn by watching the Architect, reviewing agent output, understanding why decisions get made. He compares it to law firm associates learning from partners.

But law firm associates do real legal work from day one. They draft motions, research case law, sit in on depositions. They learn by doing, not just by watching. A junior in the pod model reviews agent output, which is more like grading papers than practicing law.

The traditional pipeline was slow but functional: you wrote bad code, shipped it, watched it break in production, learned why, and eventually developed the instincts to smell a bad architecture before it got built. That loop took 3 to 5 years. It was expensive and inefficient, but it produced engineers who understood systems from the ground up because they’d built (and broken) them.

If we cut that pipeline at the bottom, we create a talent cliff. In five to ten years, who becomes the next generation of Architects? Where does the judgment come from if nobody learned by getting burned?

I don’t have a clean answer for this. I think the apprenticeship model is better than nothing, and the learning loop might compress because agents can simulate failure scenarios faster than production can. But “might” is doing a lot of work in that sentence. The industry is moving fast on the productivity side and not thinking much about the pipeline side. Somebody should be.

The transition is already happening

This isn’t a future prediction. The sequence is already visible:

The first phase happened over the past two years. Agents augmented individuals. Same org structure, everyone got Copilot or Claude Code, productivity went up, teams stayed the same size. Companies absorbed the gains as “do more with the same headcount.”

The second phase is happening now. Agents are replacing tasks, not people, on paper, but the effect is the same. QE and docs teams shrink first because they’re easiest to justify cutting. New hires slow down. Attrition doesn’t get backfilled. Meanwhile, software dev job postings are up 15% since mid-2025, which suggests companies aren’t cutting engineering, they’re reshaping what engineers do. An AI agency operator named @a_protsyuk, who’s done 200+ projects, says his clients now request “2 engineers plus agents” instead of 10-person teams. The ask changed.

The third phase is starting. Meta’s pod reorg is the signal. Agents are replacing roles, not just tasks. Companies are explicitly restructuring around smaller, flatter units designed for human-plus-agent delivery. Karpathy says he hasn’t written a line of code since December 2025, spending 16 hours a day directing agents instead. When one of the most respected ML engineers in the world stops coding, the role definition has changed.

The fourth phase, full organizational redesign, is probably 2 to 4 years out. Career ladders rewritten around the Architect track. The junior pipeline question becoming urgent. Partnership and revenue-share models replacing salary-for-seat employment. This is where Aroussi’s law firm thesis lives, and it might be directionally right even if the details take time to work out.

What to actually do with this

If you’re a senior or staff engineer, the move is clear: shift toward the Architect role. Spend more time on design and review, less on implementation. Learn to direct agents effectively. The skill is knowing what to build, not typing it.

If you’re earlier in your career, the path is less obvious. The traditional “write code for five years” ladder is getting shorter. Focus on judgment-building activities: debugging complex systems, reading other people’s code, understanding why architectures fail. Get close to the decision-making, not the implementation.

If you’re running a team, look at your org chart and ask what would change if every engineer on your team became 3x more productive tomorrow. Not “what would they ship.” What would happen to the structure? Which coordination roles exist because implementation is slow? Which management layers exist because teams are big? That’s what’s dissolving.

And if you’re hiring, think carefully about what you’re hiring for. The best investment right now is senior architects who can direct agents and ship with a tiny team. The worst investment is hiring 10 engineers for a job that will need 3 in eighteen months.

The org chart isn’t getting rearranged. The middle is evaporating. The top (judgment, architecture, client relationships) stays. The bottom (implementation, testing, documentation) gets automated. The middle, the coordination layer we built to manage scale, loses its reason to exist.

“Every developer with an AI subscription and a GitHub account is now a one-person agency. They can ship in a weekend what used to take a team of four a month. And yet, most of them are broke.” - Ran Aroussi

The question isn’t whether this happens. It’s whether your org adapts deliberately or wakes up one day wondering why half the team is doing coordination work that nobody needs anymore.