The Collapsing Middle of Software Teams

For decades, software teams grew by adding layers. Junior developers, mid-level engineers, senior engineers, leads, staff, principal. QA teams, DevOps teams, project managers, scrum masters. Each layer existed because the layer above it couldn’t scale. One architect couldn’t review all the code, so you hired leads. One lead couldn’t write all the features, so you hired mid-level devs. One PM couldn’t track all the work, so you hired project managers and bought Jira licenses.

AI coding agents removed the scaling bottleneck. A single Product Engineer with Claude Code, Cursor, and a stack of MCP servers can do what used to require a team of eight. The layers that existed to distribute work across humans are becoming unnecessary. The middle of the engineering org chart is collapsing.

Post 1 defined the Product Engineer. This post is about what happens to everyone else.

The Roles Being Absorbed

Mid-level feature developers who take a spec and turn it into working code. This used to fill most engineering orgs’ headcount. AI agents do that work now, well enough that one senior engineer reviewing AI output replaces three or four mid-level engineers writing code from scratch.

QA engineers who write test cases and run regression suites. AI generates tests faster than humans write them, and it doesn’t get bored running the same suite for the hundredth time. Companies are cutting manual QA roles for standard web and mobile apps.

DevOps specialists who configure CI/CD pipelines, manage infrastructure, and write deployment scripts. AI agents can scaffold Terraform configs, write GitHub Actions workflows, and debug container issues. The specialized DevOps role is merging back into general engineering.

Project managers and scrum masters who track tickets, run standups, and generate burndown charts. A team of two has nothing to coordinate.

Technical writers who document APIs and write internal guides. LLMs generate documentation from code faster than a dedicated writer. The Product Engineer documents as they ship.

Each of these roles solved real problems. But those problems were artifacts of team size and human throughput limits. Remove those limits, and the roles follow.

Why It Doesn’t Happen Overnight

Large organizations have immune systems. A large health-tech company needed to modernize a legacy platform. They interviewed a candidate who proposed an AI-native approach: small team, heavy use of coding agents, spec-driven development. The technical interviewers were impressed. Leadership rejected the hire. The role required managing the existing 40-person team structure, and an AI-native approach would shrink that structure to nothing. The org couldn’t adopt the approach because it would eliminate most of the team, including the people making the hiring decision.

Decision-makers reject changes that threaten existing structure, even when the change would make the company more effective. The people whose roles would be eliminated are the same people evaluating whether to adopt the new approach. They defend the org chart, and the org chart is what’s holding the company back.

The Technical Debate Tax

Debating architecture before you build is engineering. Re-litigating implementation choices after the spec is settled is a coordination tax.

I once watched a multi-week debate unfold over whether to use PostgreSQL with pgvector or a lightweight local vector database for storing around 40,000 embeddings. The engineer pushing for the local database argued that PostgreSQL was “overkill.” His real objection had nothing to do with performance or cost. He was comfortable with one tool and unfamiliar with the other.

PostgreSQL was the right call. One database handling both relational data and vector search. One connection, one backup strategy. The alternative meant copies of data spread across VMs with no consistency, no centralized updates, and a custom sync mechanism nobody wanted to maintain. The “simpler” option was more complex by every measure.

The debate itself cost more than the implementation. Two weeks of back-and-forth. Other engineers pulled into the discussion. The team scheduled meetings to “align on the approach.” The tax hits hardest when an engineer uses the review process to relitigate decisions that were already made, turning a 2-hour review into a 2-week negotiation. A Product Engineer with AI tools would have benchmarked both options in an afternoon, picked the winner based on data, and shipped it the next day.

Archetypes of the Collapsing Middle

If you’ve worked on a software team for any length of time, you’ll recognize these patterns. Engineers developed them as rational adaptations to a team-based environment that has existed for decades, optimizing for the world they worked in. The environment is what’s changing now.

The Comfort-First Engineer

The developer who refuses to use Docker because the local filesystem is “simpler,” rejects databases because JSON files “work fine,” and won’t learn new stacks because the existing tool is “good enough.” Expertise becomes a problem when an engineer uses it as a reason to stop learning. In a team, this person finds a niche and stays in it. In an AI-native world, AI has no comfort zone. The Product Engineer who directs the AI needs to be comfortable across the entire stack, or willing to learn on the fly. Specialization paid off in team environments that routed work to the right specialist. A Product Engineer owns the whole product, so breadth matters more than depth in any single tool.

The Coordinator

Spends most of their time in meetings, syncing teams, updating tickets, and ensuring alignment across workstreams. Valuable when 15 engineers need to ship a cohesive product. Unnecessary when two people build the whole thing. The team drops its coordinator because there is nobody left to coordinate. Coordination was a rational response to team scale. Without the scale, the role has no work to do.

The Process Guardian

Optimizes sprint ceremonies, enforces code review checklists, maintains CI/CD pipelines, and ensures the team follows established workflows. These processes exist to manage the complexity of multiple humans working on the same codebase. Process management was essential when eight people touched the same repo. One person with agents needs a build pipeline. The sprint retro has no audience.

The One-Trick Specialist

Knows one technology and applies it to every problem. In a team environment, this person thrives because the team routes appropriate work to them and benefits from their depth. In an AI-native environment, AI tools are fluent in every technology. The Product Engineer picks the tool that fits the problem instead of the one they happen to know. Depth in one tool becomes less valuable than judgment across many.

If you recognize yourself in these descriptions, treat it as a signal to move. Each pattern served you in the old structure and will hurt you in the new one. The time to broaden your skills and develop product-level thinking is now, while these roles still exist.

The Uncomfortable Math

Consider a common scenario: two engineers disagree on an architectural approach. In a traditional team, this becomes a multi-day or multi-week discussion involving design docs, meetings, and a decision that may or may not be the right one. If the two engineers make a combined $25,000 per month and the debate takes two weeks, that debate alone cost about $12,500 in salary, not counting the opportunity cost of delayed shipping.

A Product Engineer facing the same decision prototypes both approaches with AI assistance in a few hours, benchmarks them, and ships the better one. The total cost is a fraction of a day’s salary, and the benchmark settles the question instead of the loudest voice in the room.

Scale that up. A team of eight engineers at an average total cost of $50,000 per month each (salary, benefits, overhead, tooling) runs about $400,000 per month. One Product Engineer at $25,000 per month delivers comparable output for many categories of work. That is a 16x cost difference, and the smaller setup ships faster because there is zero coordination overhead.

Teams still make sense for safety-critical software and massive distributed platforms. Regulated industries require human separation of duties today. SOX, HIPAA, and safety-critical systems mandate review chains that one person cannot satisfy alone. As AI audit trails and formal verification improve, that wall will thin. Today’s Product Engineer works alongside a compliance officer who reviews the AI output, and by 2030 the Product Engineer will carry the liability themselves. The middle still collapses in these environments. The auditor cares about the review chain, and one Product Engineer plus a compliance officer can satisfy it.

For the vast majority of SaaS products, internal tools, and customer-facing applications, the math no longer justifies the headcount.

Twelve-person teams will not become one-person teams by next quarter. They will become three-person teams. The remaining three are Product Engineers who review each other’s specs and architecture instead of acting as mid-level implementers managing handoffs. Coordination cost drops 80% because their time goes to validating design decisions instead of running standups.

The Shortening Ladder

The engineering ladder used to have eight rungs. It is compressing to three tiers.

Foundation. AI-augmented juniors learning the craft. They write code with AI assistance and build toward full-stack product ownership under Product Engineer review. They skip the years of repetitive implementation work that used to define the early career. They jump from “learning to code with AI” to “owning a product surface” with no mid-level terrace in between.

The Collapsing Middle. The coordinate-and-implement layer. Mid-level feature developers, QA engineers, DevOps specialists, project managers. These roles distribute and manage work across humans. AI removes the distribution bottleneck. Companies are cutting these roles as AI tools improve, and the trend accelerates every quarter.

Apex. Product Engineers who ship end-to-end and deep specialists who work close to the metal. Product Engineers talk to customers, define requirements, build with AI agents, and deliver. They don’t need a PM to tell them what to build or a project manager to track their progress. Deep specialists in security, embedded systems, ML research, and compliance survive because they require domain expertise that AI augments but cannot replace.

Product Engineers must maintain architectural decision records and agent instruction documentation. Documentation isn’t optional when you’re the bus factor for the whole product.

You Probably Don’t Think This Applies to You

If you work at Atlassian, Salesforce, or any large enterprise software company, you’re looking at job boards right now and seeing hundreds of open roles. Your team is hiring. Your org is growing. You read a post like this and think: this is a startup thing. It doesn’t apply here.

That reaction is natural. It is also how every slow-moving disruption works. The shift doesn’t announce itself with a layoff round. It shows up as a hiring freeze that lasts a little longer than expected. A team that used to be twelve people gets backfilled to eight. A new project launches with three engineers instead of six, and nobody questions it because the three are shipping faster than the six ever did.

At startups right now, single engineers own entire products. One person handles the frontend, backend, infrastructure, and deployment. They use AI agents to move at a speed that would have required a full squad two years ago. The large companies will follow. They always do. It takes longer because the org chart has more inertia, but the economics are the same.

The other common pushback: “AI doesn’t make developers more productive.” People say this because they’ve seen developers paste ChatGPT output into a codebase and create a mess. They’re right that it happened. The conclusion they draw from it is wrong.

AI amplifies whatever you already are. A strong engineer with good architectural judgment uses AI to ship in days what a team used to deliver in weeks. A mediocre engineer uses AI to generate more mediocre code, faster. A bad engineer uses AI to produce spectacular messes at unprecedented scale, thousands of lines of hallucinated logic that compile but don’t work, spread across files nobody will read. AI works on developers the way a power saw works on carpenters: skilled hands move faster, dangerous hands cause more damage.

The amplification effect is why the collapsing middle accelerates. Companies don’t need five average engineers when one great engineer with AI tools produces more, and produces it better. The five average engineers aren’t standing still either. They’re using the same AI tools to generate more code that needs more review, more debugging, and more maintenance. The gap between the best and the rest is widening, and the economics of that gap determine who gets hired next.

The compression plays out over 5-10 years. Hybrid teams will keep existing for now, and they will shrink as agents improve. The threat to your career is the engineer who got a six-month head start on AI tools.

What to Do About It

For twenty years, the software industry paid engineers to convert tickets to code. The new structure pays engineers to understand what to build, because coding is the cheap part now and product thinking is what’s scarce.

If you’re reading this and feeling uncomfortable, good. Make changes now rather than waiting for the market to force them on you.

Ship a product where AI writes the code and you review it. Build the whole thing end-to-end. Deploy it. Get it in front of users. The gap between “I can write code” and “I can ship a product” is the gap that matters.

Learn AI tools until they change how you work. Get fluent in Claude Code, Cursor, or Windsurf. Learn how to write specs that agents can follow. Learn when AI output is good and when it is garbage. The engineers who survive this transition treat AI as a power tool that demands respect.

Develop product sense. Read customer support tickets. Sit in on user interviews. Understand why features get built. The engineer who can say “we should build X because customers are churning at this step” is worth more than the one who says “I can build whatever you spec.”

Kill a feature you built. Look at your analytics. Find something nobody uses. Delete it. Practice the product ruthlessness that separates a feature developer from a Product Engineer.

Get uncomfortable. If you’ve been working in one language or one framework for years, branch out. Build something in a stack you’ve never touched. The Product Engineer doesn’t have the luxury of a comfort zone, and the AI tools make learning new technology faster than it has ever been.

The transition is painful and a lot of talented people are caught in it through no fault of their own. The team structures that rewarded specialization, coordination, and process mastery were real and legitimate, and the skills they rewarded mattered. The environment is what’s changing. The software industry built those team structures to distribute coding work across humans because coding was slow, and coding isn’t slow anymore. The engineers who adapt earliest will hold the strongest positions when the compression hits their org.

---

This is Post 2 of the AI-Native Engineering Revolution series. Post 1: The Product Engineer defines the role. Post 3 will explore why large organizations struggle to adopt AI-native development.