Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge

Emad Mokhtar · article · 2026-05-07 source ↗ Reader 🖥️

Agentic Engineering Coordination Cost Multi-Agent Orchestration Prompting as Communication Technical Leadership Track (IC / Staff-Plus Ladder)

The Staff Engineer skillset of defining outcomes, reducing ambiguity, creating guardrails, and reviewing work — originally built for leading human teams — transfers directly to leading AI coding agents, and is becoming more valuable, not less, as agents take over more implementation.

practical · argumentative — A first-person career-advice essay: the author argues engineers should adopt a specific stance (lead agents like a team) and defends it with a personal case study, not a theoretical account of AI capability.

Structure

Part	Role
Personal origin story: becoming an official Staff Engineer with vague role expectations, and defining the role himself by asking teammates 'how can I help you?'	context
The paradigm shift from 'maker' to 'enabler/multiplier' for human teams	premise-building
'The Same Shift, Applied to Agents' — the central analogical move: the enabler skillset built for humans turns out to be exactly what leading AI agents requires	core argument
The Aha Moment narrative: building a six-role custom-agent team dispatched by an orchestrator agent	evidence/narrative
'The Minority' — contrasting himself against skeptical peers who still see AI as POC-only	evidence
'Who Will Survive?' — widening from Staff Engineers specifically to all engineers who move closer to the business	generalization
Practical recommendations: improve writing, improve reviewing, get closer to the business	prescription

Key terms

Leading agents
Treating AI coding agents as team members to be assigned roles, given context, reviewed, and corrected — the same posture as leading human reports — rather than as an autocomplete tool.
Enabler / multiplier
A leadership identity in which value comes from creating opportunities and clarity for others (human or agent) to do the work, rather than doing the work oneself.
Direction
The combination of defining outcomes, reducing ambiguity, setting boundaries, and deciding when output is good enough — explicitly distinguished from 'prompting,' which the author treats as too narrow a description of the skill.

Propositions

explicit⚡ disputed & corroboratedThe Staff Engineer leadership skillset — defining outcomes, reducing ambiguity, creating guardrails, reviewing work — is becoming more valuable, not less, in the AI era; engineers who already made the shift from coder to enabler for human teams are early, not late, to AI.conf: high
supportsDeveloping Your Leadership Skills toward Principal Engineering · p1 — Both argue staff/principal-level engineering is defined by influence, communication, and direction-setting, not technical skill alone — Mokhtar extends this claim specifically to leading AI agents.
contradicts ←Alex Ewerlöf's Post · p3 — Ewerlöf insists architecture must not be abstracted away from hands-on coding and warns against the Ivory-Tower-Architect drift toward 'defining outcomes' over doing the work; the AI-era piece argues the opposite directional bet — that the shift from coder to outcome-defining enabler is exactly what positions a Staff Engineer well for leading AI agents. Same role, same vocabulary (outcomes, guardrails, review), opposite verdict on whether drifting away from hands-on execution is a trap or an advantage — a tension worth reading together rather than resolving by assertion.
supports ←Update on Software Engineering Career Ladder · p7 — Mokhtar's claim that the Staff Engineer leadership skillset (defining outcomes, reducing ambiguity, reviewing work) is becoming more valuable, not less, in the AI era validates Shore's decision -- made for non-AI, culture-change reasons -- to formalize exactly that cross-team, player-coach skillset as a distinct title.
explicitcorroboratedThe mental shift required to lead AI agents is the identical shift required to lead human teams — from being the sole maker to being the multiplier: assigning roles, reviewing output, correcting course, guarding quality — with the only difference being that agents iterate faster than humans.conf: high
supportsThe Conductor Developer · p7 — Both insist the shift is engineering expertise redirected, not engineers becoming managers or being replaced.
supportsAddy Osmani’s Post · p4 — Independent convergence on 'direct agents the way you'd delegate to a person' as the core behavioral shift.
supports ←We don't write code anymore · p7 — An engineering manager's independent field report corroborates the Staff Engineer's claim that leading agents uses the identical managerial loop (direction, context, review, correction) as leading people.
explicitA Staff-Engineer-style team of six role-specific custom agents (Lead Engineer, Senior Engineer Implementer, Senior Engineer Reviewer, QA Engineer, Security Engineer, Technical Writer), dispatched by a single orchestrator agent, can execute a feature end-to-end from a one-line instruction.conf: high
explicitMost peer engineers still believe AI code is reliable only at proof-of-concept level and must be thrown away and rewritten by a human; the author's own four months building and maintaining production software with AI contradicts that majority view.conf: high
explicitImplementation is only one part of software engineering — understanding the problem, trade-offs, system design, stakeholder communication, quality review, risk management, documentation, and maintenance are the rest — so as AI absorbs more implementation, direction (not prompting skill per se) becomes the engineering advantage.conf: high
implicitPrompt quality functions for an agent the way ticket quality functions for a human engineer: a vague prompt, like a vague ticket with only a title filled in, produces a frustrated agent that fills gaps with assumptions — so writing clearly is becoming a core engineering skill, not a side skill.conf: medium
explicitAs agents build more, reviewing becomes more important, not less: the future engineer is defined by the ability to judge whether generated code is safe, maintainable, and fits the business goal — which requires, rather than removes the need for, strong fundamentals in architecture, testing, security, and performance.conf: high
supportsWhen AI Writes Almost All Code, What Happens To Software Engineering? · p9 — Both claim being a solid engineer (judgment, fundamentals) becomes more sought-after, not less, as AI absorbs implementation.
explicitEngineers who survive the AI-driven market shift are those who move closer to the business — understanding users, domain, and constraints — because that context is what lets them direct agents effectively, rather than waiting to be handed a PRD and picking up tickets.conf: high
extendsAddy Osmani’s Post · p2 — Mokhtar's 'move closer to the business' is a concrete instance of the scarce complementary skill of selecting and framing problems.
implicitThe piece assumes the Staff Engineer leadership skillset is something any individual engineer can acquire unilaterally through personal initiative, the way the author did informally before being titled — it has no account of how an organization deliberately trains, structures, or rewards this transition across its wider engineering population, nor what happens to engineers who haven't yet built the human-leadership reps the author leaned on.conf: medium

Arguments

The Staff Engineer skillset is becoming more valuable, not less, in the AI era.

Explicit premises:

Leading AI agents well requires the same skills as leading human teams: defining outcomes, reducing ambiguity, creating guardrails, reviewing work
Agents, like people given a bare ticket, produce worse output when given vague direction and fill the gaps with assumptions
Implementation is becoming automatable while direction, review, and business-context work are not

Implicit premises:

Organizations will continue to need someone accountable for distinguishing 'impressive-looking code' from useful, maintainable software even as implementation volume grows
An individual engineer's personally-acquired human-leadership skill transfers cleanly to agent-leadership without additional training or organizational support

Inferences:

If direction is the scarce skill, engineering organizations should weight hiring and promotion criteria toward judgment and context-gathering over raw implementation speed — a conclusion the author gestures at for individuals but never states as an organizational policy

Narratives

The author built six role-specific custom GitHub Copilot agents (Lead Engineer, Implementer, Reviewer, QA, Security, Technical Writer) plus an orchestrator agent, and dispatched a one-line instruction ('Build endpoint for user management') to the whole team — producing a result that left him both 'shocked' and unsure whether to feel proud or threatened.
→ Makes concrete the abstract claim that agents should be led 'like a team' rather than used as autocomplete, and dramatizes the ambivalence (opportunity vs. job-loss fear) that recurs through the piece.

Questions addressed

✅ What should a newly-titled Staff Engineer actually do, given vague and inconsistent role expectations?
He defined the role himself through direct conversations with teammates ('How can I help you?') and an external course, landing on an enabler/multiplier self-definition.
✅ Does AI's growing coding capability threaten the Staff Engineer's (or any engineer's) job?
No — because the enabler/multiplier skillset built for leading humans is exactly what's needed to lead agents, so the role's value increases rather than disappears.
⭕ How does an engineering organization, rather than one self-motivated individual, scale this leadership shift across its whole workforce and keep quality consistent when many engineers are each directing their own agent teams?

Gaps

incompleteThe piece is written entirely from the perspective of one self-motivated individual's personal transition; it never addresses the team or organizational dimension — how review capacity, coordination, and quality standards hold up when many engineers in the same org are each independently 'leading' their own agent swarms, or how an organization trains and rewards this shift systematically rather than relying on individuals to discover it the way the author did.
Read next: extract-engineering-manager-role-splitting-in-two and extract-software-teaming-age-of-ai-zuill-herr, which address the team- and org-level coordination costs this piece elides.
incompleteNo discussion of durable, large-scale, or legacy codebases; every example (CLI tool, personal dashboard, browser extension, a user-management endpoint) is small, disposable, or greenfield. The claim that the Staff Engineer skillset transfers to leading agents is untested against the harder case of agents operating inside a decade-old, high-stakes production system.
Read next: extract-orosz-when-ai-writes-almost-all-code (production-quality regressions already observed) and extract-whats-an-orchestrator-why-software-needs-one (accountability scaling with agent-driven productivity).
illogicalThe author frames 'reviewing becomes more important' as sufficient reassurance without reconciling it with his own admission that agents 'make mistakes... sometimes create bugs that look very convincing.' If agent output is specifically liable to look convincing while being wrong, review itself becomes harder exactly as it becomes more necessary — a tension the piece raises but doesn't resolve.