Leadership

Leading Engineering Teams Through the AI Shift

I've led engineering teams in one form or another for most of the past fifteen years — twenty-five-plus developers on SOA and messaging-based platforms at Spice Digital, project teams at Advatix, and now technology for Apollo Supply Chain, where we're mid-flight on VisionWare+, an AI-driven analytics platform for warehouse operations. Leading through the AI shift isn't a separate initiative from that work; it's changed almost every management habit I have, some in ways I expected and several I didn't.

Velocity Without Understanding Is a New Risk

The most immediate change is also the most deceptive: my team's output volume went up meaningfully, and for the first few months I mistook that for progress across the board. It wasn't, uniformly. What I found on closer inspection was that some engineers were producing more code they deeply understood, and others were producing more code they had accepted from an assistant without fully internalizing. Both look identical in a pull request count. They are not identical in what happens when that code breaks in production and the engineer who "wrote" it has to debug something they never really reasoned through in the first place. That gap is now something I actively watch for, not something I assume away.

Rethinking What I Measure

Lines of code and PR counts were already weak proxies for engineering value before AI assistants; now they're close to meaningless, and treating them otherwise actively rewards the wrong behavior. What I've shifted toward instead: how well an engineer can explain the reasoning behind a change in review, how often their AI-assisted work needs correction after the fact, and whether they're building the kind of system understanding that lets them debug confidently under pressure. None of that shows up in a dashboard as cleanly as commit counts did, which means it takes more deliberate 1:1 and review time than the old metrics did — a real cost, and one I've had to budget for explicitly.

If your team's dashboards still reward speed of output, you're optimizing for exactly the behavior that gets someone paged at 2 a.m.

Hiring Has Changed More Than I Expected

I screen differently than I did three years ago. Raw coding-speed signal, timed exercises, algorithm trivia, has become a weaker predictor of who succeeds on my teams, because that specific skill is exactly what tooling now compresses. What predicts success better: how a candidate reasons about a system they don't fully understand yet, how they respond when I tell them a piece of code (real or AI-generated) has a subtle bug and ask them to find it, and whether they ask sharp clarifying questions instead of guessing. I've started explicitly including "review and critique this code" exercises in interviews, which was rare when I was hiring in 2019 and is close to standard on my panels now.

Governance Matters More, Not Less

There's a tempting narrative that AI tooling means you need less process, because the tool handles more of the work. My experience running technology for a company with real operational stakes — warehouse systems where a bug has physical, not just financial, consequences — is closer to the opposite. Higher code volume without a proportional increase in review rigor is how quality debt accumulates quietly until it's expensive. I've tightened, not loosened, architecture review for anything touching data integrity or external integrations, and I've made "explain what this AI-assisted change does and why" a standard, non-optional part of code review on my teams, not a courtesy.

Protecting Psychological Safety

One change I didn't anticipate: I now explicitly tell my team it's fine, expected even, to say "I don't fully understand this AI-generated suggestion" out loud in a review, rather than nodding along because it looks plausible and everyone else seems fine with it. Early on, I noticed a quiet reluctance to admit not understanding something a tool produced, in a way people didn't feel about a human colleague's code. That's a culture problem worth naming directly, because the alternative is a team that ships code nobody actually understands, which is a slower-motion version of the same risk AI was supposed to help with.

What This Adds Up To

The job of an engineering manager was always to build a team whose collective judgment you could trust more than any individual's, including your own. AI tooling didn't change that job. It changed the shape of what judgment needs to cover, shifted where the risk concentrates, and raised the cost of getting hiring, review, and culture wrong. Leading through that well has looked less like adopting a tool and more like consciously deciding what not to let the tool erode.

← Back to all posts