AI Is Removing the Middle Class of Software Engineering

You can prompt an agent for three hours and ship a 25,000-line pull request. Nobody on your team can tell you why it works - or why it breaks at 2 AM. The New Workflow It's 2026. You're the senior engineer on a mid-size product team. Your job has always been the person who catches the architecture mistakes before they compound - the one who notices that a Kafka dependency was grafted onto a read-heavy query, or that someone denormalized the database because it was faster than fixing the ORM. This morning, you open your inbox. There are seven pull requests. The first one is 24,506 lines added, 3,938 removed, with a description that reads: "Implemented user analytics pipeline with event streaming." You pull the branch. It runs. The tests pass. When you ask the author where the data flows, they send you a link to a Claude conversation. Somewhere in that 47-turn exchange, between confident architectural recommendations and polite apologies when the model changed its mind, is the design decision. You read all 47 turns. You still don't know why they chose Kafka. This is not a hypothetical. This is what the post-AI-productivity era looks like for teams that adopted coding agents without updating their engineering discipline. The speed limit has been removed. And the people who built their careers on being the speed limit are now obsolete. What Changed Before AI coding assistants, there was a natural throughput cap on software output. A senior engineer could review perhaps three meaningful pull requests per day. A team of ten could ship maybe fifteen high-quality merges per sprint. This cap wasn't arbitrary - it was enforced by the time required to actually understand what you were merging. AI changed the cost structure, not the review requirement. A developer armed with a capable agent can now produce 25,000 lines of code in a morning. The agent writes the code. The agent writes the tests. The agent writes the documentation. The agent even writes the PR description, which sounds coherent and professional. To the untrained eye - and many managers are untrained - the output looks indistinguishable from what a senior engineer would produce. But the review requirement hasn't changed. Someone still needs to understand every line in that 25,000-line PR. Someone still needs to know whether the Kafka dependency is necessary, whether the database schema makes sense, whether the error handling covers the failure modes that will kill you in production at 3 AM. The gap between production velocity and review capacity has become the defining structural problem of modern software teams. The Two Types of Engineers There are two kinds of engineers on every team, and AI has dramatically changed the value of each. The first type knows what the code does. They can trace a request from the API endpoint through the service mesh to the database and back. They understand why the retry logic uses exponential backoff instead of fixed delay. They can explain, without consulting the agent, why the authentication flow requires a token refresh every 15 minutes rather than every hour. These engineers were valuable before AI. They are exponentially more valuable after it. The second type can prompt an agent to produce working code. They don't know why the code works. They don't know what happens when the third-party API changes its response format. When asked "why did we choose this architecture?", they say "the model suggested it." These engineers were marginally productive before AI. They are dangerously unproductive after it. The tragic insight is that the second type of engineer produces output that looks correct. The code runs. The tests pass. The feature works. This is precisely what makes them dangerous: nobody can easily distinguish their output from the first type's output without deep, time-consuming review. And here's the crucial point - the first type of engineer now has less time to do that review. Because the second type produces 10x the volume, the first type must review 10x the code. The math doesn't work. The Debt Compounds Faster Now Technical debt has always been a problem. The difference in the post-AI era is that debt accumulates at a rate that exceeds the team's ability to pay it down. Consider a simple example. An engineer uses an agent to add a new database table because it's "faster than modifying the existing schema." The agent writes the migration. The agent writes the model. The agent wires it into the API. Everything works. The PR is approved - or rather, it's too large to review thoroughly, so it gets merged with a few cosmetic comments. # Before AI: This migration might take 2 days of careful planning class AddUserAnalyticsTable(Migration): def up(self): # Carefully consider: will this break existing queries? # Will the index hurt write performance? # Do we need a gradual rollout? execute("CREATE TABLE user_analytics (...)" # After AI: The agent writes this in 30 seconds class AddUserAnalyticsTable(Migration): def up(self): # Agent generated: no review needed, right? execute("CREATE TABLE user_analytics (...)") # Agent also added 12 indexes "for performance" # Agent also refactored the ORM layer "for clarity" # Nobody noticed until prod broke Six months later, you need to migrate that data. You need to update every service that touches it. You need to coordinate the rollout with zero downtime. The engineer who added the table has moved to a different team. The agent that wrote the migration is gone with it - no one on the team remembers the reasoning. Fixing bad architectural decisions is always harder than making them. Before AI, the speed differential between "making the bad decision" and "fixing it" was manageable. A team could accumulate a few bad decisions per quarter and spend a sprint paying down the debt. Now, a team can accumulate thousands of bad decisions per quarter, and the debt payment phase never comes. This is the credit-card metaphor that every senior engineer recognizes: you see the luxury car (the working feature), not the debt (the architectural complexity that will haunt you for years). AI makes it possible to buy a new car every week. What Gets Worse With Scale You might think this problem is contained to teams that adopt AI uncritically. It isn't. The dynamics scale in ways that make the problem worse at larger organizations. At a startup of ten engineers, the senior person can still review everything personally. At a company of 500, the review bottleneck becomes structural. Middle management adds layers of approval that don't actually improve code quality - they just add process. The result is a organization where code ships faster but gets worse, and nobody can point to a specific failure because everyone was following the process. The salary divergence is the economic signal. Companies that previously paid $150K-$200K for "solid mid-level engineers who can implement features" now find that those engineers are producing output that costs $20 to generate in API calls. The market corrects: those roles either disappear or drop to $60K-$80K for people who can actually evaluate and direct AI output. Meanwhile, the engineers who can read code, understand systems, and make architectural judgments command $300K+ because they're the only ones who can prevent the org from collapsing under its own accumulated debt. The middle class isn't just shrinking - it's being replaced by a bimodal distribution with a thinning waist. The Vibe Coder Career Path Several years ago, I wrote about why the "vibe coding" career path - learning to prompt AI to build apps without understanding the underlying systems - is doomed. That analysis was speculative. The evidence now overwhelming supports it. Here's what happens to a vibe coder on a real team: Month 1: Ship fast. Impressive output. Colleagues impressed. Month 3: Bugs appear they can't debug. PRs create dependencies. Month 6: Become a liability. Every touch requires senior review. Month 12: Let go, or realize they can't compete. The trajectory is predictable because the foundation is absent. AI gave these engineers the ability to produce output without the skills to evaluate it. That's not a career - it's a countdown. What Senior Engineers Should Do If you're the person who actually understands the system, the writing on the wall is clear: your value is increasing, but so is your workload. Here's how to protect yourself. Refuse large PRs. A pull request larger than 400 lines should be a red flag, regardless of who wrote it or what tools they used. Insist on small, reviewable changes. This isn't anti-AI - it's pro-quality. Any engineer, human or augmented, should be able to explain a 200-line change in a single conversation. # Good: Small, reviewable PR def update_user_balance(user_id: int, amount: float) -> bool: """Update balance with proper locking.""" with db.transaction(): balance = get_balance_for_update(user_id) new_balance = balance + amount validate_balance(new_balance) set_balance(user_id, new_balance) return True # ~15 lines. Anyone can review this in 2 minutes. # Bad: 400-line PR from an agent # The agent generated an entire microservice, # 12 classes, 3 database tables, and a message queue # in one shot. Nobody reviewed it thoroughly. # It merged. It broke in prod 3 weeks later. Demand explanations, not links. When an engineer can't explain a decision, don't accept a link to their AI conversation. That conversation contained the reasoning, yes - but if the engineer couldn't extract the relevant part from 47 turns of back-and-forth, they don't understand their own work. Ask them to explain it. If they can't, the PR doesn't merge. Build judgment, not speed. Your differentiator is no longer how fast you can produce code. It's how well you can evaluate code that anyone (or anything) can produce. Invest in your ability to read systems, spot architectural flaws, and make tradeoff decisions that balance short-term shipping against long-term maintainability. Men