Should managers become hands-on again? - by João Alves

AI-assisted development is fundamentally changing the economics of building software, and the adaptation window is much smaller than previous technology shifts. The real question isn't whether it's the best use of a CTO's time to ship code - it's whether they can afford not to when the productivity gains could be massive even if only partially true. Leaders who aren't investigating this hands-on are accumulating a dangerous opportunity cost.

The investigation needs two parallel tracks: building greenfield projects using tools like Replit, Lovable, or Claude Code to see what's possible without constraints, and building within your actual enterprise constraints - your cloud environment, security policies, legacy systems. The delta between these two perspectives becomes your vector for action. Even a 5% productivity gain at scale would be massive, and early reports from leaders who've gone hands-on suggest the gains are far higher.

The speed of this shift creates a structural problem in organizations. In a 200-person org with four to six layers between the CTO and individual teams, change that trickles down organically will arrive too late. The window is closing faster than the Internet revolution because the Internet itself accelerates adoption. When your CEO is shipping code between meetings and reporting fantastic results, that act sends a signal that cascades differently than any mandate or initiative could.

This isn't about abandoning leadership responsibilities for coding full-time. It's about spending the time you might use reading articles instead feeding prompts and watching things move at unprecedented speed. You're supposed to know how to parallelize, delegate, and evaluate decisions - those skills make you uniquely positioned to understand the real impact. The competitive gap widens every day you're not inside the technology, and unlike previous shifts, you can't delegate this learning to consultants or internal champions alone.