There's a debate in software engineering that refuses to die: Should engineering managers still write code? Every few years, the question resurfaces, usually accompanied by familiar arguments about technical credibility, staying close to the work, and maintaining the respect of the engineers they lead. Some believe a manager who stops coding eventually loses touch with the realities of software development. Others argue that the best engineering leaders are those who can still roll up their sleeves, open an IDE, and contribute alongside their teams.
I've never particularly agreed with that premise. We have software engineers to write code. We have technical leads to establish technical direction, guide architectural decisions, and help engineers navigate difficult implementation challenges. Engineering managers have a different responsibility, one that is neither less technical nor less important. Their job is to build and lead the organization that produces the software. They are responsible for developing talent, establishing accountability, removing organizational friction, aligning priorities, and creating an environment where good engineering can happen consistently. Those responsibilities require technical understanding, but they don't require personally implementing features.
For most of the industry's history, there was at least a practical limit to how much coding a manager could do. Writing meaningful software required time, concentration, and sustained involvement. A manager who spent two days implementing a feature was spending two days not managing. The tradeoff was obvious, even if some managers refused to acknowledge it. Eventually, the demands of leadership made it difficult to maintain the illusion that someone could be both a full-time engineering manager and a meaningful individual contributor.
Artificial intelligence is removing that constraint. A manager who hasn't written production code in five years can now open Claude Code, describe an application, and have something functional running before lunch. Bugs that once required hours of investigation can be explored through a conversation. Internal tools can be assembled in an afternoon. Prototypes that once required the attention of several engineers can emerge from a series of prompts. And increasingly, we're celebrating this development as evidence that engineering managers can finally become hands-on again.
But I'm not convinced that's progress. In fact, I think it may be creating an entirely new leadership problem.
AI may be turning vibe coding into the newest form of micromanagement.
Leadership Is Delegation
One of the most difficult transitions in any professional career is moving from being responsible for your own work to being responsible for the work of others. In engineering, that transition can be particularly uncomfortable because the skills that earned someone recognition are often the very skills they need to stop exercising every day. A successful engineer develops an identity around solving problems. They understand complex systems, recognize patterns others miss, and take pride in producing elegant solutions. Then one day they're promoted into management, where their success depends less on their ability to solve those problems and more on their ability to help other people solve them.
This is where many new managers struggle. When an engineer encounters a difficult technical problem, the instinct is to investigate and resolve it. When an engineering manager encounters that same problem, the instinct should be different. They need to understand whether the right people are involved, whether the team has the necessary context, whether competing priorities are creating obstacles, and whether someone needs coaching or support. Sometimes the appropriate response is to ask a difficult question. Sometimes it's to remove an impediment. And sometimes it's to do nothing at all, allowing the team to work through a challenge and develop the judgment that comes from solving it themselves.
Delegation is frequently misunderstood as a practical response to limited time. Managers have too many responsibilities, so they distribute work to others. But that's a remarkably shallow understanding of what delegation accomplishes. When a manager delegates meaningful responsibility, they aren't simply transferring a task. They're transferring ownership, creating an opportunity for someone to exercise judgment, and building the organization's capacity to operate without their direct involvement. The immediate result matters, of course, but so does the capability developed along the way.
Consider an engineering manager who discovers that a team is struggling with a complicated integration. The manager may have enough technical experience to identify the problem and suggest a solution. They might even be able to implement the fix faster than the engineers currently investigating it. But doing so deprives the technical lead of an opportunity to exercise leadership and the engineers of an opportunity to develop expertise. The integration might be repaired more quickly, but the organization hasn't necessarily become more capable of handling the next one.
Delegation isn't what leaders do when they're too busy to do the work. Delegation is the work.
When Productivity Becomes Micromanagement
Every experienced leader has encountered the manager who struggles to let go. They rewrite presentations their employees have already prepared. They personally resolve customer escalations rather than coaching the people responsible for them. They insert themselves into decisions that should belong to their teams, often with the perfectly reasonable explanation that they can handle the situation faster. Sometimes they're even correct. Their experience allows them to reach a better immediate answer with less effort.
The problem is that leadership isn't a competition to see who can complete an individual task most efficiently. A manager who continually substitutes their own judgment for that of their team creates an organization dependent on their involvement. Employees become accustomed to waiting for direction. Emerging leaders stop exercising authority because they know their decisions may be overridden. The manager becomes increasingly indispensable, which can feel like evidence of their importance even as it reveals a fundamental failure to develop the people around them.
AI is dramatically reducing the friction that once limited this behavior. The manager no longer needs to spend a weekend relearning a framework or navigating an unfamiliar codebase. They can describe what they want, iterate on the result, and produce something that appears to solve the problem. The justification practically writes itself: Why wait for the team to prioritize an internal application when I can build it tonight? Why ask the tech lead to investigate an issue when I can have an AI agent explore it in twenty minutes? Why spend an hour explaining what I want when I can generate the solution myself?
We've spent decades teaching managers to resist precisely that reasoning. The fact that AI makes it more convenient doesn't make it better leadership.
And there's an additional complication. Unlike traditional micromanagement, which is often obvious to everyone involved, AI-assisted micromanagement can look remarkably productive. The manager isn't hovering over an engineer's shoulder or demanding constant status updates. They're independently producing working software, demonstrating initiative, and seemingly removing work from the team's backlog. The organizational consequences may not become apparent until later, when engineers are asked to maintain something they didn't design, technical leads discover decisions made without their involvement, or employees begin to question who actually owns the technical direction of their systems.
The manager has produced more software. Whether they've produced a stronger engineering organization is another question entirely.
The Irony: AI Might Actually Be Teaching Delegation
But there's a contradiction here that deserves more attention. While AI may be making it easier for managers to return to implementation, it may simultaneously be teaching individual contributors some of the skills they'll eventually need to become effective leaders.
Think about what separates an effective AI-assisted engineer from someone who simply asks a chatbot to write code. The effective engineer understands the objective, provides relevant context, establishes constraints, identifies potential risks, and defines what success should look like. They know when to provide detailed instructions and when to allow the system latitude in determining an implementation. They evaluate the result against the original intent rather than assuming that a functioning application necessarily represents a successful outcome.
Now consider what effective delegation requires from a manager. They need to communicate the objective, explain the broader context, establish boundaries, clarify expectations, and determine how success will be evaluated. They need to resist the temptation to prescribe every implementation detail while remaining accountable for the result. The similarities are difficult to ignore.
For much of software engineering's history, individual contributors were rewarded primarily for their ability to personally execute. They received a problem, developed a solution, and implemented it. As they progressed, they might begin coordinating technical work across a team, but the underlying expectation often remained that their expertise would be demonstrated through their direct involvement in the solution.
AI is changing that relationship. Engineers increasingly find themselves directing work rather than personally performing every implementation step. Their effectiveness depends on how clearly they communicate intent, how well they establish constraints, and how accurately they evaluate outcomes. Those are not exclusively leadership skills, but they are important components of leadership. It's entirely possible that engineers who become exceptionally effective at working with AI are developing some of the mechanics of delegation before anyone gives them responsibility for another person.
Of course, delegating to an AI agent isn't the same as delegating to a human being. AI doesn't have career aspirations, professional insecurities, competing motivations, or a desire to develop its own judgment. It doesn't need encouragement after a difficult project or an explanation of why a particular assignment matters to its future. It doesn't experience frustration when someone repeatedly overrides its decisions. Human delegation involves an investment in people that cannot be replicated through prompting.
But that doesn't erase the transferable skills involved in defining outcomes, communicating expectations, and resisting the urge to control every detail of execution. And it creates a fascinating contradiction. AI may be teaching engineers to accomplish more by doing less of the implementation themselves, while simultaneously encouraging their managers to accomplish more by returning to implementation.
We're potentially developing better instincts for delegation in the people who haven't yet become managers, while making it easier for existing managers to abandon those instincts.
The Organization Is the Product
None of this means engineering managers should become technically disconnected from their organizations. Engineering leaders need to understand the technologies their teams use, the architectural challenges they face, and the implications of the decisions being made. They need enough technical fluency to ask intelligent questions, challenge assumptions, recognize risk, and understand when a proposed solution doesn't align with the organization's broader objectives. Experimenting with AI tools can be an excellent way to maintain that understanding. But there's a meaningful difference between using technology to understand how the work is changing and assuming responsibility for performing that work.
The manager's real opportunity with AI may be considerably more valuable than personally generating additional software. AI can help engineering leaders improve communication, analyze organizational challenges, explore staffing decisions, identify opportunities for coaching, and reduce administrative overhead. It can create more time for the responsibilities that distinguish leadership from individual contribution. Using AI to become a more effective manager should be the objective, not using AI to become an individual contributor again.
Perhaps the most persistent misconception about engineering management is that managers remain engineers whose primary responsibility happens to include supervising other engineers. That framing makes coding seem like the natural center of the role, with leadership responsibilities layered on top. But it fundamentally misunderstands what happens when someone accepts responsibility for an engineering organization.
The manager's product is no longer the software. It's the organization capable of producing that software.
That organization requires investment, maintenance, and deliberate evolution. People need opportunities to develop expertise. Technical leaders need meaningful authority. Teams need clarity about their responsibilities and enough independence to exercise judgment. And the entire organization needs to function effectively without every important decision passing through a single individual.
A manager who personally resolves every difficult technical problem may appear indispensable, but indispensability isn't necessarily evidence of good leadership. Sometimes it's evidence that the organization has been designed around the wrong dependency. If the team cannot function without the manager's direct technical contribution, the manager has a problem that writing more code will not solve.
For decades, we've struggled to teach great engineers that becoming a leader means learning to succeed through the work of others. AI may finally be teaching engineers some of those skills before they ever receive a management title. The irony is that we're now using the same technology to encourage their managers to do the work themselves.
The best engineering manager was never the person who could write the most code. It was the person who built a team that didn't need them to.
AI hasn't changed that. It's just made it easier to forget.