I’m all in on AI. I use it every day and have no plans to go back. The productivity gains are real, the tooling is getting better fast, and honestly, coding has never felt more fluid. I’m also excited about where AI agents are headed and what they are doing for developer workflows. But, in the middle of all this enthusiasm, there’s one question the industry keeps conveniently dodging: What is the actual end goal?
Not the marketing answer. Not the quarterly roadmap answer. The real one. Because how you answer that question determines everything: how you hire, how you train, what skills you invest in, and what kind of engineering culture you’re quietly building toward.
If the answer is “replace traditional developers with AI orchestrators,” that’s a legitimate vision. Commit to it. Be transparent about it. Build toward it deliberately. But if you still believe humans need to step in when AI misbehaves to debug it, steer it, and fix it, then you cannot simultaneously strip developers of the skills that make them capable of doing exactly that. You can’t have both. Trying to is how you end up with the worst of each world.
The Zombie Problem
When teams offload requirements, design, and implementation entirely to AI, or use Agentic AI workflows for production issues, taking the human completely out of the equation, the short-term numbers look great. Velocity goes up. Headcount stays flat. Leadership sees the dashboard they wanted. But underneath, you’re quietly hollowing out the cognitive muscle that makes a developer valuable in the first place.
Push this long enough, and you end up with engineers who can prompt fluently or use advanced skills that the tools provide, but can’t reason through a system failure. They don’t know why the architecture was designed the way it was. They can’t trace a bug through layers they didn’t write and don’t understand. When the AI breaks down, and it will, nobody in the room knows how to fix it. You haven’t replaced developers with AI. You’ve replaced skilled developers with babysitters who don’t know how to babysit.
And beyond the practical risk, there’s something worth protecting here. The joy of being a developer has always come from the value you bring to the table, the excitement of shaping an idea into something that actually works, the critical thinking that gets you there, and the ownership of the craft. It’s not just a job. It’s a discipline that rewards curiosity and punishes shortcuts. Take that away, and you haven’t just created a skills gap. You’ve taken the fun out of the job. And when the job stops being interesting, the best people leave.
The Middle Path
There’s a better model, and it doesn’t require pulling back on AI at all. In fact, it leans harder into what AI is genuinely good at. Let developers become idea people, not in some vague aspirational sense, but concretely, on a day-to-day basis.
It doesn’t mean every developer needs to be inventing new frameworks or rethinking distributed systems from scratch. It can be as simple as this: read a ticket, expand the requirements with context the product team didn’t think to include, sketch out a design, use AI to brainstorm edge cases and pressure-test your assumptions, instruct the AI on how to approach the implementation, then use AI agents to augment your debugging when something goes sideways. At every step, the developer is thinking. AI is the amplifier. Critical judgment stays in the loop.
This is the model that keeps developers sharp, keeps the work meaningful, and keeps the output trustworthy. Every tool we build, and every process we design, should reinforce this focus, not erode it. The moment we start designing workflows that route around human judgment entirely, we’re not optimizing for productivity. We’re optimizing for fragility.
Set Realistic Expectations
A big part of what drives teams toward the zombie outcome is unrealistic expectations set at the top. When leadership announces they want 100% or 200% productivity gains from AI adoption, the pressure that creates doesn’t leave room for developers to stay thoughtfully in the loop. It leaves room for shortcuts. It leaves room for humans to get quietly pushed out of the process in ways that look efficient until something goes wrong.
Target 30–50% improvement instead, and the math changes. You still get meaningful speed gains. You still have a real story to tell about AI-driven productivity. But you also have room to keep intelligent, opinionated, curious developers in the driver’s seat. The business side may not care how software gets built as long as it gets built; that’s not a criticism, it’s just not their lane, but it should absolutely be the lane of tech executives and engineering leaders to hold this line and set expectations that don’t accidentally incentivize the wrong outcome.
The Stakes Are Bigger Than This Quarter
Get this wrong, and we’re not just deskilling today’s engineers. Every junior developer entering the field right now is watching how their senior colleagues work and building their mental model of what the job actually is. If the answer they absorb is “prompt, review, deploy, repeat” with no deeper understanding of systems, tradeoffs, or failure modes, we’re not just risking our current teams. We’re shaping the next generation.
The goal should be to have developers who are more capable because of AI. Developers who use it to think bigger, move faster, and build things they couldn’t have tackled alone, but who still fundamentally understand what they’re building and why. That combination is where the real leverage is.
That’s a problem we won’t be able to AI our way out of.