Leadership musings and hackery from the Perl generation...
The best engineers have always been generalists with spikes of deep expertise. AI hasn't changed that. What it has changed is the timeline. You used to have years to broaden your skills across the stack. Now you have months, and the engineers who treat breadth as someone else's problem are finding out what happens when the market stops rewarding narrow specialism.
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.
For years, engineering managers could hide behind the inherent complexity of software development. "This work is hard to estimate." "Coding takes time." "You can't rush quality." These weren't lies exactly, but they were convenient shields against accountability.
The phrase "vibe coding" has entered the lexicon to describe a workflow where developers prompt an AI, accept the output, and hope for the best. It sounds efficient. It feels modern. And for production systems, it's genuinely dangerous. The distinction between developers who vibe and those who control their AI tools is quickly becoming the most important skill gap in our industry.
The code review, that sacred ritual of software engineering, is dying. Not because we've abandoned quality or stopped caring about our craft, but because the ground beneath it has fundamentally shifted. In the age of agentic AI, the pull request as we know it has become a bottleneck masquerading as a best practice.