AI coding tools have made it possible for engineering leaders to be deeper "in the code" than at any point in the last decade. That sounds like a win, and in many ways it is. But there's a trap hiding inside the dopamine hit of shipping features yourself: the more time you spend building, the less time you spend leading. And the parts of your job you're neglecting are often the ones your organisation needs most.
The nerd snipe is real
If you've spent any time with tools like Claude Code, Cursor, or Copilot, you know the feeling. You sit down to prototype a quick idea and three hours later you've built half a feature. The feedback loop is intoxicating. Prompt, generate, iterate, ship. It feels like the most productive afternoon you've had in months.
For engineering leaders who've missed being hands-on, this is irresistible. We got into this industry because we love building things, and for years we traded that joy for calendars full of one-on-ones and strategy sessions. Now the tools have lowered the barrier so dramatically that we can be builders again. Why wouldn't we jump at that?
The problem is that vibe coding dulls the part of your brain that's been trained to minimise scope and ensure you're working on the right things. When everything feels achievable, the instinct to ruthlessly prioritise fades. Why cut that feature when you could just build it this afternoon? Why say no when saying yes costs so little?
Your leadership job didn't disappear
While you were heads down building, the work that only you can do was piling up. The hard conversation with the underperforming team lead. The strategic alignment with your product counterpart about what not to build next quarter. The organisational design work that will determine whether your team can scale. The career development conversation that's three weeks overdue.
None of that work gives you a dopamine hit. None of it has a tight feedback loop. You can't prompt your way through a difficult performance conversation or generate a reorg plan in fifteen minutes. These things require slow, deliberate thought. They require you to sit with ambiguity and make judgment calls that won't be validated for months.
That's exactly why they're the first things to slip when something more immediately rewarding appears. It's not that leaders are lazy. It's that our brains are wired to chase the reward signal, and shipping code is a much stronger signal than "had a productive but uncomfortable conversation about team structure".
Depth is a feature, not a destination
I want to be clear: the ability for leaders to be closer to the work is genuinely valuable. Understanding your systems at a deeper level makes you a better decision maker. Being able to prototype and validate ideas quickly is a superpower. The era of the "PowerPoint VP" who couldn't read a pull request was not a golden age.
But depth is a tool in your kit, not the whole kit. Mario Zechner wrote a great post recently about the importance of slowing down with AI coding tools, arguing that discipline and human judgment are what prevent agent-generated code from compounding into an unmaintainable mess. His advice applies doubly to leaders. We need to slow down not just in how we write code, but in how we allocate our own time and attention.
The question isn't whether you should be coding. It's whether the time you're spending coding is coming at the expense of the strategic and people work that compounds over quarters and years. A feature you ship today has value. But a team you've built well, aligned properly, and given clear direction to will ship hundreds of features without you touching a keyboard.
Finding the balance
The leaders who will thrive in this new era are the ones who treat their own time with the same ruthless prioritisation they apply to their team's roadmap. Use the new tools to go deeper when depth serves the organisation. Prototype to validate strategy. Build to understand your systems. Stay close enough to the work that your technical judgment stays sharp.
But don't let the dopamine hit of building trick you into thinking you're doing your most important work. The hardest parts of leadership have always been the least immediately rewarding, and no amount of AI tooling changes that. Your team needs you to do the boring, ambiguous, uncomfortable work that doesn't compile and doesn't ship. That's still the job.
Comments