I went to LDX3 as a new manager. The talks weren't about AI replacing me.

AI is not coming for my job as a manager. It's coming for the parts of it I liked least. I spent two days at LDX3 in New York with 2,000 engineering leaders, and the message from the stage was strikingly consistent. Gartner predicts that through 2026, 20% of organizations will use AI to flatten their structures, cutting more than half of middle-management roles. Nobody up there was celebrating. They were drawing a line between the management work AI takes and the leadership work it can't.

I'm new to management. I went in worried the talks would be about my job disappearing. They were about my job getting clearer.

What is AI actually taking from managers?

The administration. Reporting, scheduling, tracking, aggregating status. The work that fills a middle manager's calendar and produces nothing a model can't do faster. What's left is the part no model does: deciding what matters.

Justin Reock, Deputy CTO at DX, opened with the numbers talk, and I believed all of it because it matched what I felt in the room. His team's Q2 2026 report across 500+ engineering organizations: AI use is above 90% across the industry. Heavy users save more than 6 hours a week. AI-generated code is now 52.7% of all code, up from 24% two quarters ago. Median quarterly AI spend went from roughly $1,500 to $44,000 in a year, a 28x jump in tech. And the innovation ratio, the share of time spent on new feature work versus maintenance, sat flat at 57 to 58%.

Read that again. Spend up 28x. New products flat. The industry is paying enormously for AI and getting speed, not ideas.

Reock's close was the tell: measure for impact, set paved paths, add guardrails. The prescription wasn't smaller teams. It was governance. That's management work dying and leadership work growing, stated plainly on stage.

What can't it take?

Judgment. Kaya Thomas, engineer and founder now at PostHog, told a story I've been turning over since. New York City used to charge you twice when you took the subway and then the bus. The MTA made it one fare in 1997, and ridership rose. About half of the ridership increase over the next two years is attributed to the fare incentives. The model can write the code. Someone still has to notice you're charging people twice.

Her talk was about the engineering skills that survive AI, and her list had nothing to do with prompting. Three human skills: care about the person using it, see the whole system, shape data so tools can use it. One slide I photographed: reward careful prep, quality, and good use of the tool. Not speed, not PR count, not tokens.

That slide changed how I think about measuring my team. When half the merged code is AI-written, counting output measures the model, not the engineer. The scarce thing is knowing what to build and whether it's right.

What does the remaining work look like?

Making calls. What to build, what good looks like, who owns it after launch. Three talks gave me the same job description from different angles.

Melody Olson spent 17 years at Google leading Maps. Her talk: she thought her team knew what mattered after an all-hands. A week later, in office hours, she learned they didn't. Her fix: say the mission plainly, say why now, tie each piece of work to a person it helps. No tool closes the gap between what you think you said and what the team heard. That gap is the job.

Marcel Weekes, VP of Product Engineering at Figma, put it as: code got cheap, so the jam moved. The constraint is now what to build, whether it fits, whether customers trust it. Each feature is a promise to run it later, so name who owns it after launch. And a line I'm keeping: customers can only take so much change. Constant change wears them out. Someone has to decide the pace, and that someone is a person.

Dan Manges, CEO of RWX, gave me the most actionable line of the two days: the PRD is now a prompt, so be careful here. Review the plan, not just the code. My rule from it: I write scopes and specs from what I actually understand, then the model can help. Never flip it. Judgment before generation.

What did this change about how I manage?

I stopped trying to out-tool the model and started on the people work I'd been avoiding.

First: I caught myself trying to explain why our work mattered before I really knew the product cold. Melody's gap was comms. Mine is step one. Learn it, then say it, then check what they heard.

Second: an early-career report wanted to talk about next level every week. We agreed to monthly, with wins sent anytime in between. The trade: I treat you like a senior. You own the work and the bugs. Steady beat beats weekly worry.

Third: my default for new engineers was small bugs to learn the code. Kaya flipped me. First work should touch a real customer pain, so new people learn why the code exists, not just where the files live.

And a smaller one I'm slightly embarrassed about: I walked in with a to-do to build a frontend cloud agent in Cursor. I looked into it after the talks and killed it. The industry doesn't need another harness from me. It needs me to know what matters.

No one on stage was trying to replace frontend. The work moved from typing code to making calls: what matters, what good looks like, who owns it after. That's not a smaller job. It's the actual job, finally visible.

FAQ

Is AI going to replace engineering managers? Not the ones doing leadership work. Gartner predicts 20% of organizations will use AI to flatten structures through 2026, but the roles at risk are admin-heavy: reporting, scheduling, tracking. Trust, judgment, and coaching through change are becoming more valuable, not less.

I'm a new manager. Where do I start with AI? Learn the product cold first, write your own specs, then let the model help. Understanding before generation. The managers getting value from AI are the ones who know what good looks like before they prompt.

How should I measure my team if half the code is AI-written? Stop counting what the model inflates. Reward careful prep, quality, and good use of the tool: not speed, PR count, or tokens. When output gets cheap, the scarce thing is judgment about what to build.

What did LDX3 actually change about how you manage? Four flips: I killed a plan to build a cloud agent in Cursor, I started learning the product before preaching the mission, I changed what first work looks like for new engineers, and I stopped letting AI draft specs I didn't understand.

Should managers still review code in the age of AI? Yes, but review the plan, not just the code. AI writes the diff; your job is deciding whether the change should exist at all, and who owns it after it ships.