Leading in an Agentic World
When your engineers work differently, how should you lead?
An engineer ships a feature on a Tuesday afternoon that would have taken most of a sprint a year ago. She didn’t work harder. Instead, she described the problem to an agent, reviewed three iterations, caught the one edge case that mattered, and merged. You’re thrilled, and rightfully so. Then you sit down to prep for your one-on-one with her and realize you have no idea what to coach.
The work of building software is changing shape, and the instincts leaders have built over the last decades are calibrated to a process that no longer applies. The standup questions, the way you read a sprint board, the things you praise in a review, the rubric you use to tell a strong engineer from a struggling one: all of it was tuned to a world where writing the code was the hard, slow, expensive part. When that stops being true, not only are the engineers on your team struggling to understand their role in this new world, but you are struggling to understand your role in helping them navigate it.
I’ve written before about what AI does to the system, but your role as an engineering leader is to work on the system, not in it. Historically that meant helping to coordinate the work of multiple engineers towards a shared outcome. Now each person on your team has their own team of agents and their role has shifted from writing the code to coordinating the work. What, then, does that mean for your role?
The Irony of Automation
In 1983, a researcher named Lisanne Bainbridge published a short paper called “Ironies of Automation.” She was writing about industrial control systems, not software teams, but the central observation has aged unnervingly well. When you automate the routine parts of a job, you don’t eliminate the human. You leave the human with everything the automation couldn’t handle, which is to say the hardest, least routine, most judgment-heavy parts. And because the routine work was where people built and maintained their skills, the automation quietly erodes the very expertise it now depends on more than ever.
It’s not much of a stretch to apply this principle to the new world of software engineering. Agents are now absorbing the boilerplate, the scaffolding, and the systems integration work. What’s left for the engineer is the part the agent can’t do well: deciding what to build, judging whether the output actually holds up, and catching the partial-failure case nobody thought to specify. The floor on producing code dropped, but this has forced the premium on judgment to go up.
Agentic workflows accelerate the code writing stage so dramatically that the long pole in the tent is no longer typing at all. It’s human judgment and coordination: the scoping meeting, the design review, and the business rules that need to be codified into working software.
Cultivating Judgment
There are three primary ways that engineering leaders can help their teams build the skills necessary to be successful in this new world. The first is what you actually coach. I wrote in GenAI Made Me Love Coding Again that my agentic coding experiment worked because of my engineering background, not despite it. I knew to ask the agent to record partial successes and failures separately because I’d been burned by distributed systems before. That instinct is more “the job” now than ever before. So your coaching shifts from “is this engineer writing good code, and is it getting better” to “is this engineer’s judgment sound, and is it getting better.” Throughput tells you almost nothing now; an engineer can generate a week’s worth of functional code in an hour, but functional doesn’t mean correct.
The second is what I’ll call the “engineering pipeline problem,” and this is something I’m not sure we’ll fully understand as an industry for another several years. Judgment comes from reps. From writing the boilerplate, getting it wrong, debugging the thing for hours, and internalizing why it broke. If agents do all the reps, where does the next generation build the judgment we now depend on more than ever? It’s Bainbridge’s irony, exactly: we are automating away the training ground for the skill that has become most valuable. Leaders who treat early-career engineers as simply “slower agents” will wake up in three years with a team that can prompt but cannot evaluate.
The mechanism for building judgment hasn’t actually changed; we just have to be deliberate about protecting it. Keep pairing junior engineers with experienced ones, but aim the pairing at a new target. The point is no longer to watch someone write a loop. It’s to watch how they decide that a loop is or isn’t the right approach: where they distrust the agent’s confident output, which edge case makes them pause, why “it passes the tests” isn’t the same as “it’s correct.” Judgment is experienced more than it’s taught, and it’s experienced by working next to someone who already has it.
The third is what you measure and protect. If the constraint is review and judgment, then review capacity, system understanding, and the conditions for deep work are the things worth investing in. The team that ships well in an agentic world is not the one with the best tools or the biggest token budget (though both help); it’s the one whose engineers can look at a confident, well-formatted, fully-tested pull request and tell whether it actually solves the problem, not just whether it compiles.
The playbook isn’t fully written; we’re early, and anyone claiming certainty here is selling something. But one move is durable and concrete: in your one-on-ones, stop asking what shipped and start asking engineers to walk you through a decision the agent got wrong and how they caught it. That conversation tells you more about whether your team is getting better than any chart of pull requests opened or tokens consumed, metrics that have never been easier to inflate or less correlated with impact.
What Only You Can Do
We’ve covered the judgment your engineers need to build. But if they are the ones now directing agents and judging the output, what is left that is distinctly yours? There are several high-leverage areas that don’t transfer well to agents.
Your team is still comprised of humans, and while the agents they are using don’t care much for recognition or career advancement, it’s likely the humans still do. Your role shifts towards focusing more on career development and the kind of feedback and coaching that compounds over time. You are still best positioned to understand the intrinsic motivators for each person on your team and to help direct their work in a way that aligns with those motivators and helps to draw out their best work.
You also shape how your team spends the hours that used to disappear into typing, and the skill worth building there is experimentation. When writing a solution cost weeks or months, you committed to the first reasonable design and lived with it, often trading functionality for time. When it costs minutes or days, an engineer can build two or three approaches, watch how each behaves, and apply judgment to choose. Make that the expectation. The scarcity of coding time used to force premature commitment; that constraint is gone, and the teams that exploit it will produce more options, then exercise the judgment to throw away anything but the best solutions.
Most importantly, you must continue to act as a bridge between technology and the business. AI helps teams build, but it doesn’t provide the context necessary to ensure what’s being built is the right solution to the problem, nor does it have the ability to decide on the trade-offs between technology constraints and business requirements. Technology and the business cannot live in isolation, and the strongest leaders help their teams balance the two so that delivery and long-term sustainability are both maintained.
You can’t be the only bridge, though. Complex work still requires humans aligned on what they’re building, and that alignment doesn’t happen for free. Help your engineers build the same skill: push them to take a thorny technical constraint or tradeoff and explain it to a non-technical audience, their product partner, the compliance team, or the executive sponsor. The engineer who can do that is the one who avoids very efficiently building the wrong thing, because cheap code raises the cost of misalignment: you can now ship the wrong thing faster than ever. Communication was always undervalued in engineering; help your team treat it like it sits at the center of the role, because it now does.
The Job That’s Left
Automation always promises to make the human’s job smaller. In practice it makes the job harder and more important, because what’s left is the part that resisted automation in the first place. Leading engineers in an agentic world is no different. The typing is getting handled. The judgment, the taste, and the responsibility for whether the thing is actually right are not going anywhere. That was always the job. Now it’s the whole job.