A manager I spoke with recently said something that stuck with me. He'd shifted his thinking about team organization — smaller, focused pods of engineers — but not because AI coding agents were making each engineer faster (or obsolete). It was because, done right, those agents could give engineers something back: time to actually think, to collaborate, to care about the business problem and not just the ticket.
It's a compelling vision. But what we're seeing across the industry tells a different story. The risk isn't that the tools aren't capable — it's that the moment a team frees up time, the organizational vacuum fills it. Another urgent fire, the next feature, a backlog that never seems to shrink. A lot of teams have just traded a manual treadmill for an automated one. Moving faster, but still not finding the space for the thinking that actually scales.
And I think that's where the conversation about AI coding agents gets stuck. It defaults to velocity. Ship more. Ship faster. Get more done per engineer. It's the easy pitch because it maps to the metrics everyone already loves and understands.
But optimizing for velocity without changing anything else is a trap. You automate away the rote work and just replace it with more rote work. You haven't changed the culture. You've made the treadmill faster.
If you're not sure whether anything actually changed, burnout could be a signal worth watching. Teams where AI agents are in use but engineers are still burning out — or burning out faster — haven't changed the culture.
This is especially true when the structure isn't right to begin with. When AI tools help a team move faster on code, that freed-up time doesn't automatically become collaboration time. Something else fills it (and that something else can look different across teams).
So what do we actually want engineers doing with the time AI gives back?
I believe the teams that get this right won't be the ones with the fastest deploy cycles. They'll be the ones that used this moment to build a different kind of culture — one where engineers are closer to the problem, where ideation is collaborative rather than competitive, where "what are we building and why" isn't a question that only lives in a PRD.
That's not a threat to product ownership. I believe it's actually what makes product ownership work better. Engineers who understand the customer problem build differently than engineers who just work from specs. Better upstream alignment means fewer downstream rewrites.
The KPIs will always be there. But "time saved by AI" doesn't have to automatically become "more features shipped." That's one choice. Another choice is using that leverage to finally have the conversations we never had time for.
AI agents are a lever. What you do with the leverage is still yours to decide.