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.
Mentor the evaluation skill. Help your junior engineers develop the judgment to evaluate AI output. The next generation of software engineers shouldn't be judged on how many lines they can generate — they should be judged on how well they can decide which lines are worth generating.
What Teams Should Change
Individual advice only goes so far. The structural incentives that reward volume over quality need organizational change.
Tie compensation to maintainability, not velocity. If you measure engineers by lines shipped or PRs merged, you will get exactly what you measure: lots of lines and lots of PRs, most of which nobody fully understands. Start measuring bug rates, mean time to recovery, and the age of code that hasn't been touched in six months.
# Wrong metric: Lines of code per sprint
metrics = {
"prs_merged": 47,
"lines_added": 12500,
"lines_removed": 3200,
# These numbers look great. They're also meaningless.
}
# Right metrics:
metrics = {
"bug_rate_per_1000_lines": 2.3,
"mttr_hours": 4.2,
"code_age_no_review_months": 8.5, # Alert: > 3
"architectural_debt_score": 0.7, # Scale 0-1
}
Require architectural documentation for non-trivial changes. A PR that introduces a new service, changes the data model, or modifies a shared library should come with a one-paragraph design rationale. Not a 47-turn AI conversation — a single paragraph that explains what the change is, why it was needed, and what the tradeoffs were. If the engineer can't write that paragraph, they don't understand the change.
Keep the human in the loop. This is obvious advice that teams repeatedly forget. AI should augment engineers, not replace them. The engineer who writes the prompt should also understand the output. If they don't, they shouldn't be the one shipping it.
Invest in the middle class. Paradoxically, the best way to save the middle class of software engineering is to stop treating "writing code" as the primary skill and start treating "evaluating code" as the primary skill. Mid-level engineers who learn to critically assess AI output — who can spot a subtle concurrency bug or a security vulnerability that the agent introduced — will be more valuable than ever. The question is whether organizations will recognize and reward that skill, or whether they'll continue optimizing for the wrong metric.
The Long View
This isn't the first time technology has disrupted the middle class of a profession. The printing press disrupted scribes. The spreadsheet disrupted accountants who calculated by hand. The compiler disrupted assembly programmers. Each time, the middle layer shrank, and the people at the top became more valuable while the people at the bottom either adapted or were displaced.
Software engineering is no different. AI is removing the middle class of coding — the engineers who can produce working code but don't deeply understand the systems they're building. What remains are two tiers: the engineers who understand systems and can direct AI, and the engineers who can't and are being replaced.
The question isn't whether this is happening. It's whether you're on the right side of the split.
The engineers who survive this transition won't be the ones who can prompt the most effectively. They'll be the ones who can look at a 25,000-line PR and say, "I don't understand three of these modules, and I'm not signing off on this until I do."
That's not anti-AI. That's just good engineering. And it's the skill that AI can't replicate — because it requires judgment, not pattern matching.
What's your team doing about AI-augmented code quality? Have you seen the middle-class squeeze firsthand? Share your experience in the comments.
Originally published on Dispatch.
Top comments (0)