Staff Engineering in the Age of AI: What Actually Changes

There's a narrative that AI is coming for software engineering jobs. I think that's wrong - or at least, it's missing the nuance. AI is coming for tasks, not roles. And the staff engineer role is one where this distinction matters enormously.

What Staff Engineers Actually Do

If you ask a junior developer what a staff engineer does, they might say "write really complex code." That's part of it, but it's the least important part. The real work of a staff engineer is:

• System design - deciding how components fit together, where boundaries should be, what trade-offs to make
• Technical strategy - choosing which technologies to adopt, when to migrate, what to deprecate
• Mentoring - helping other engineers grow, reviewing their architectural decisions, not just their code
• Cross-team influence - aligning multiple teams on shared standards, APIs, and practices
• De-risking - identifying what could go wrong before it does, building guardrails

Notice that none of these are "write a for loop" or "implement a REST endpoint." Those are tasks. The staff engineer role is about judgement - and judgement is exactly what AI struggles with most.

What AI Changes

Here's what I've seen change in my own work over the past six months of AI-first development:

Less time on implementation, more time on design

I used to spend maybe 30% of my time on architecture and 70% on implementation. That ratio has flipped. AI agents handle most of the implementation, which means I spend the majority of my time thinking about what to build and how it should work, rather than typing it out.

This is a massive upgrade. The design phase is where the most impactful decisions happen. Spending more time here means better systems.

Review becomes more important, not less

When AI writes code, someone still needs to review it. And that someone needs deep technical judgement. Can you spot a subtle race condition in AI-generated async code? Do you notice when the AI chose the wrong abstraction? Can you tell when a test passes but doesn't actually verify the right thing?

This is quintessential staff engineer work. AI makes it more needed, not less.

Mentoring takes a new form

Instead of teaching someone how to write a React component, I'm teaching them how to prompt for a React component, how to review AI output, how to decompose a feature into parallelisable tasks. The mentoring is higher-level, but it's still mentoring.

Cross-team influence scales

This is perhaps the most exciting change. As a staff engineer, I'm responsible for consistency across teams. With AI, I can encode that consistency into configurations, hooks, and conventions that AI agents follow automatically. My architectural decisions don't just influence through code reviews and documents - they're embedded in the AI's behaviour.

The Skills That Matter More

If you're a staff engineer (or aspiring to be one), here's what I'd invest in:

• System thinking. Understanding how components interact, where failures cascade, what coupling costs you. AI can write code but it doesn't understand your system's topology.
• Communication. You're now communicating with both humans and AI. Being precise about requirements, constraints, and context is more important than ever.
• Taste. Knowing when code is "good enough" vs "needs to be better." AI will happily over-engineer or under-engineer if you let it. Your taste is the calibration.
• Risk assessment. AI agents can do things fast. That includes doing the wrong thing fast. Knowing where to put guardrails and verification is critical.

The Skills That Matter Less

I'll be honest about what's becoming less important:

• Memorising API surfaces. I don't need to remember every React hook signature or every CSS property. AI knows these perfectly.
• Typing speed. Sounds trivial, but "how fast can you type code" used to be a real factor in productivity. It's now irrelevant.
• Boilerplate tolerance. The willingness to grind through repetitive setup code used to be a virtue. Now it's a waste of human attention.

What I Tell My Team

When engineers on my team ask if they should be worried about AI, I tell them this: The engineers who will thrive are the ones who can think clearly about systems, communicate precisely, and make good judgement calls under uncertainty. Those have always been the most valuable engineering skills. AI just makes them more obviously valuable by removing everything else.

If your value as an engineer is primarily in writing code fast, you're right to be concerned. But if your value is in knowing what code to write - and more importantly, what not to write - then AI is the most powerful lever you've ever had.

The staff engineer role isn't disappearing. It's becoming the template for what all senior engineering looks like in an AI-augmented world.