The New Engineering Roles: When AI Changes the Price of Building and the Cost of Leading

In What About Teams?, I argued that teams may stop being the default unit of execution but become even more important as the unit of trust and context. This article is the uncomfortable sibling of that question: if teams change, what happens to the roles inside them — Software Engineer, Engineering Manager, Director — and the dual-ladder bargain that quietly shaped the last decade of careers in tech?

For the last decade, large tech companies operated a useful peace treaty: you could grow as an IC without becoming a manager, and you could become a manager without pretending to still be the deepest coder in the room. At comparable levels, both paths carried similar compensation and influence. A Staff Engineer and an Engineering Manager did different jobs but the company treated both as leverage roles — one through technical judgment, the other through people, execution systems, and business outcomes.

That model made sense when software production was expensive enough that role boundaries stayed stable. AI does not immediately destroy it. But it puts pressure on the assumptions underneath:

• If building gets cheaper, what exactly are companies paying engineers for?
• If output accelerates, does managing people become easier — or much harder?

The Old Bargain: Two Ladders, Similar Value

The traditional dual-ladder model was a reasonable compromise: some people create leverage through deep technical judgment; others through people, structure, prioritization, and organizational design. In mature engineering organizations the two tracks reached rough compensation parity at comparable levels — never perfectly, but well enough for the philosophical bargain to hold.

Different instruments. Same orchestra. The question is whether AI changes the orchestra.

AI Makes Building Faster, But Not Automatically Better

The obvious claim is that AI makes engineers more productive — true, but incomplete. Anthropic’s 2025 productivity analysis estimates AI accelerates individual tasks by roughly 80% on average, with the biggest gains on bounded, measurable work — generation, refactoring, documentation. The constraint: those bounded tasks are not the messy reality of long-lived software ownership.

Software engineering has never been only about producing code. It is also deciding what should exist, why, how it should behave, how it should fail, who owns it, and whether the system still makes sense six months later. The 2025 DORA report found that 90% of developers now use AI and most report productivity gains — but it also frames AI as an amplifier that magnifies a team’s existing strengths and weaknesses, with around 30% of developers expressing distrust in AI-generated code. Faster individual work does not automatically translate into healthier delivery systems.

This is the central tension. AI lowers the price of building. It does not automatically lower the cost of understanding, integrating, operating, or aligning what gets built — and sometimes it raises them. A team that produced ten things may now produce thirty. Someone still has to review, connect, test, operate, prioritize, support them, and quietly explain why half of them should never have existed. More output is not always more progress. Sometimes it is just more inventory.

The Research Pattern: Faster Individuals, Messier Systems

Harvard Business School and BCG research introduced the “jagged technological frontier”: AI improves performance on some tasks but can worsen performance on tasks that look similarly difficult to humans. The peer-reviewed write-up in Organization Science (2025) frames it as a pattern where generative AI both creates and destroys value depending on which side of the frontier the work sits.

That maps unevenly onto software work:

A useful counterweight: in METR’s 2025 randomized trial with experienced open-source developers working in mature repos they already knew, developers took 19% longer when using early-2025 AI tools. Narrow study, but that’s precisely the point — it looked at deep system knowledge, not toy tasks.

The pattern is not “AI makes engineering faster.” It is closer to: AI makes some parts faster, some parts stranger, and some parts more dangerous to evaluate. If implementation gets cheaper but evaluation gets harder, the value does not disappear. It moves.

The SWE Role: Less About Typing, More About Taste

The Software Engineer role will not disappear, but the center of gravity moves. The valuable engineer becomes less like a manual code producer and more like a technical director of a small swarm of capabilities — defining crisp intent, breaking ambiguous problems into agent-friendly work, reviewing generated code critically enough to catch plausible nonsense, owning quality and operational consequences, and — surprisingly important — knowing when not to generate more code.

In the pre-AI world, code was expensive enough that friction was a natural restraint. You had to type it, test it, wire it together, and fight with the compiler long enough to eventually ask, “Do we really need this?” In the AI world, code is cheap enough that restraint becomes a senior skill:

Junior engineer: Can I generate this?

Senior engineer: Should this exist at all?

The market may pay less for “I can implement tickets” and more for “I can turn ambiguous intent into reliable systems with minimal organizational drag.” That does not make engineering less technical — if anything, it makes technical judgment more important. The dangerous engineer in an AI-native org is not the one who writes slowly. It is the one who generates quickly without understanding deeply.

The EM Role: Less Status Reporting, More Reality Management

If AI increases throughput, does management become less necessary? At first glance, maybe — a chunk of EM work is genuinely automatable:

The weak version of engineering management gets exposed quickly. But that is not the full job — or it shouldn’t be. AI does not remove ambiguity; it often increases it. When output accelerates, more decisions arrive per unit of time, more parallel branches open, more architectural debt can be produced with a smile and a green checkmark.

The manager’s job shifts from “how do I get the team to produce?” to “how do I keep accelerated production connected to human judgment, business priority, team health, and long-term system integrity?” That is harder, not easier.

Yes, People Management Probably Gets More Complex

The honest answer to the uncomfortable question: yes, managing people probably becomes more complex in AI-native engineering orgs. Not because managers are morally superior to builders (they are not), and not because IC work becomes simple (it does not) — but because AI makes the human system less stable.

Before AI, two engineers might both look busy and the difference could be hidden behind complexity, meetings, vague scope, or the universal fog machine known as Jira. With AI, the gap between people who use the tools well and people who do not may widen. Some engineers use AI to clarify thinking, accelerate implementation, and explore alternatives. Others use it to produce more surface area without deeper understanding. Both groups look productive. Only one is improving the system.

Now the manager has to evaluate not just output, but the quality of AI-amplified output — much harder than counting tickets. And as I argued in The Pace, this comparison problem rapidly becomes a pace problem: when the ceiling on output keeps moving, the manager has to decide what “enough” even means.

Career Development Gets Weird

The old ladder was imperfect but had familiar signals: juniors needed support, mid-levels delivered scoped work independently, seniors handled ambiguity and influenced others, staff engineers shaped direction across teams. AI muddies those signals.

What does it mean to grow from L3 to L4 when an L3 can produce code that looks like L5 work? What does “senior” mean when implementation skill is partially externalized? What does mentorship mean when the first answer comes from an AI assistant instead of a teammate? What does code review mean when the author may not fully understand the generated code? What does ownership mean when implementation was delegated to a tool, but the incident still wakes up a human at 2:17 a.m.?

The engineering ladder will need to shift away from visible implementation artifacts and toward judgment, ownership, system understanding, and consequence management. Easy to say. Much harder to operationalize. And that work lands heavily on engineering leadership.

Psychological Safety Gets More Fragile

AI creates comparison pressure. If one engineer does five times more with agents, what does that mean for everyone else — are they behind, obsolete, lazy, careful, protecting quality, resisting change, or wisely refusing to generate garbage? These are not theoretical questions. They show up in performance reviews, promotion discussions, hiring bars, compensation debates, and private anxiety at 11 p.m. on a Wednesday.

Microsoft’s 2025 Work Trend Index reports 75% of global knowledge workers using generative AI, usage roughly doubling over six months — and a persistent gap where many employees bring their own tools while leaders struggle to convert individual use into business impact. AI adoption is not arriving as a perfectly governed executive rollout; it is also arriving through individual experimentation.

One engineer quietly becomes much faster. Another uses the wrong tool for the wrong task. A third refuses to use AI because the quality bar matters. A fourth uses it constantly but cannot explain the generated code. The manager has to make sense of all of that without turning the team into a productivity surveillance lab. AI adds a productivity mirror that may or may not reflect reality, and the manager has to distinguish between healthy acceleration and organizational panic. That is people leadership, not project management.

Coordination Cost Does Not Disappear

One tempting idea is that if everyone has better tools, coordination becomes less important — fewer meetings, fewer dependencies, fewer handoffs, fewer teams. Some of that may happen. But coordination cost does not disappear; it changes shape. More generated work means more review. More review means more prioritization. More parallel experiments mean more integration decisions. More autonomy means more risk of divergence. More speed means more chances to make inconsistent decisions, faster.

A team was never only a group of people producing code. It was a compression mechanism for context, trust, norms, ownership, and shared judgment. If AI loosens the boundaries of teams, someone still has to maintain coherence. That work does not vanish — it moves upward.

The Engineering Director Role May Become More Important

The EM role changes, but the Director role may change even more. A pre-AI Director managed managers, owned a portfolio, translated strategy into execution, and managed organizational health. In an AI-native model, the Director becomes responsible for the operating system of engineering itself.

Questions that used to be local team decisions become organizational design questions:

• What work should be done by humans, what by agents, and what reviewed by humans at what depth?
• How do we measure productivity without creating metric gaming?
• How do we prevent AI-generated technical debt?
• How do we train engineers when the tools change every month?
• How do we preserve team identity when execution becomes more fluid?
• How do we avoid a two-class engineering culture: AI-native accelerators and everyone else?

This is not people management. It is socio-technical systems design. The Director becomes less a manager of managers and more the designer of an adaptive engineering organization. That role becomes more valuable — but only if the person can actually operate at that level. The title alone will not save anyone.

The New SWE and the New EM, Side by Side

Both roles become hybrids. They take on more, not less.

This may sound inflated, but it is the natural consequence of moving implementation down the stack. When compilers improved, engineers moved up the abstraction ladder. When cloud platforms matured, engineers changed what infrastructure judgment meant. AI is another abstraction jump — the new SWE writes less code by hand but owns more decisions around code. That is still engineering. Maybe more, not less.

The new EM ends up answering questions like: Is this person underperforming, or being careful in a reckless system? Is this team slow, or is the rest of the org generating too much noise? Is this AI output actually valuable, or just impressive? Are we growing engineers, or turning them into reviewers of machine output? That work is not easier than writing code. It is just harder to measure. Which may be the real problem.

The Measurement Trap

The tempting answer is to measure everything: lines changed, PRs merged, review latency, incident rates, cycle time, escaped defects, revenue contribution. Some of it helps. But if the measurement system is naive, people will optimize for it. The old organization had politics. The AI-native organization may have metric gaming at machine speed — I explored a related version of this in If We Can Measure Everything, Do We Still Need Politics? Measurement does not eliminate politics. It just moves it.

This is especially dangerous when comparing ICs and managers. The IC has artifacts (code, specs, reviews, incidents). The EM has second-order effects (better decisions, less churn, clearer ownership, healthier pacing). Both are real. Both are measurable. But not equally directly:

Neither bias is automatically fair. A good AI-native company needs a richer model of value — not “who produced the most stuff?” but “who improved the company’s ability to produce the right stuff, safely and repeatedly?” That question applies to both tracks.

Will Pay Parity Stay?

The hardest question. My honest guess: pay parity stays at the top, but gets less stable in the middle.

So the future may not be “EMs become more valuable than SWEs” or vice versa. It may be:

AI increases the value of exceptional leverage and decreases the value of role-shaped mediocrity.

Unpleasant, but probably closer to reality. The pay question becomes less about IC vs. manager and more about leverage type: can you multiply high-quality outcomes, reduce ambiguity, create judgment at scale, make humans and AI systems more effective together, and prevent the organization from confusing motion with progress? Those questions apply to both ladders.

The research direction supports this. The Harvard/BCG “jagged frontier” work does not suggest a clean flattening of skill — it suggests AI creates uneven performance effects depending on the task and the person’s ability to use the tool appropriately. DORA similarly suggests individual-level benefits can coexist with system-level tradeoffs. That makes compensation harder, not easier. The company will not simply pay people for using AI. It may pay more for knowing where AI belongs, where it does not, and how to absorb the consequences.

The Broader Work Shift

This is not only an engineering story. Microsoft’s New Future of Work 2025 report frames generative AI as a broad change in knowledge work — pivoting from individual to collective productivity, AI-team integration, and worker-centered deployment patterns as organizations move from narrow experiments to real-world deployments.

PMs, designers, support, data, and executives all change. The boundaries between functions get more fluid: a PM prototypes, a designer generates frontend code, a support engineer builds diagnostic agents, a software engineer writes product specs, and an EM becomes the person responsible for whether any of this actually coheres. The company role map gets blurrier. And when the map gets blurrier, judgment gets more valuable.

Nobody Has Fully Done This Yet

There is no established playbook for these new roles. Not really. There are early signals, research reports, vendor case studies, productivity experiments, and plenty of confident conference talks. But nobody has spent twenty years operating a mature AI-native engineering organization at scale, because such an organization has not existed for twenty years.

That means the first generation of AI-native engineering leaders and ICs will be building the practices while living inside the consequences:

• Redesigning career ladders while people are asking for promotions.
• Changing performance expectations while people are anxious about replacement.
• Introducing agents while still debugging flaky CI.
• Measuring productivity while trying not to create a surveillance culture.
• Asking teams to move faster while also asking them not to drown in generated complexity.

This is not a clean transformation. It is messy organizational surgery while the patient is still replying in Slack.

A Working Hypothesis

If the analysis above is roughly right, the IC and EM ladders probably do not collapse into one another — but both become more demanding.

Pay parity could hold at comparable senior levels, but the justification likely shifts. A senior IC may no longer be paid highly because they personally type rare code — more plausibly, because they can turn ambiguous problems into reliable systems with AI-amplified leverage. An engineering leader may no longer be paid highly for managing people in the old administrative sense — more plausibly, because they can turn accelerated, chaotic, uneven human-plus-AI capacity into coherent business outcomes. A higher bar than today, on both sides — assuming the market eventually prices these things accurately, which is itself a generous assumption.

The Uncomfortable Ending

The old career question was: do you want to stay technical, or manage people? The new question may be: what kind of complexity are you best at absorbing?

Some people absorb technical complexity. Some absorb human complexity. Some absorb organizational complexity. Some rare people absorb all three — which is why they become very expensive and very tired.

AI does not remove complexity from engineering organizations. It moves it around. It lowers the cost of building, but it raises the cost of deciding, aligning, reviewing, integrating, trusting, and sustaining the people doing the building.

So yes, engineering leadership becomes more complex. Not because building becomes trivial — because building becomes faster than our old organizations were designed to handle. And when production accelerates faster than judgment, the most valuable role is not automatically the person who produces the most.

It is the person who helps the system stay sane.