Agents have made writing software quick and enjoyable again, and plenty of technical executives have quietly returned to the codebase. Some of that is the best thing a CTO can do right now. Some of it is a way of avoiding the job that happens to look a lot like work. The hard part is telling which one you’re doing.
This year, the CTO coding again stopped being an exception. Nobody put it in a board deck, but a lot of technical executives are back in the codebase, and many of them are enjoying it more than anything else on their calendar.
Nobody asked them to. Agents made building cheap and fast, and for many of us, genuinely fun again. LeadDev’s Engineering Leadership Report 2026 found that 44% of CTOs increased the time they put into coding and code review compared with the year before. Among engineering managers, the share doing hands-on technical work rose from 20% to 35% in a single year.
The popular story around this is flattering. The player-coach is back, and the leader who builds is being held up as the model for an AI-native organization.
There’s real truth in that. But the CTO coding again also raises a question that very few people are asking out loud:
Is this leverage, or is it hiding?
The question isn’t whether CTOs should write code. It’s whether writing code is making them better CTOs or helping them avoid being CTOs.
I’m Back in the Code Too
I’ll start with my own version, because I’m not writing this from the sidelines.
Most of my career has been in software development and later hardware development. My passion has always been audio. I started at Digidesign/Avid (the Pro Tools company), and went on to decades of product and engineering leadership across many companies, from startups to established enterprises. For various stretches of my career, my relationship to signal-processing code, or any type of code for that matter, was as the person responsible for the teams writing it. When you’re running a large organization, that’s not uncommon.
Over the past couple of years, that has changed. I’ve been building audio applications again, mostly in Python, much of it around things I enjoy building: spectrum analysis, spectrograms, goniometers, and the kind of tools I used to specify rather than write. I’ve also been spending time building MIR (music information retrieval) and machine learning applications that interpret audio and control devices around my home, like lighting. I like being a geek.
Working alongside agents has grown my Python skills more than I expected, partly because an agent will happily explain why a piece of code works instead of just handing it over.
What Audio Taught Me About Agents
It has also made me a better coach. Audio is a demanding place to test what agents can actually do because you can check the output against physics. Feed the system a known audio tone, and the result either lands where the math says it should or it doesn’t. More than once, an agent handed me code that ran cleanly, drew a convincing display, and was still wrong in ways I only caught by measuring it against a reference signal and my own years of experience.
That’s one of the things I like about building with agents:
AI lowers the cost of building. It doesn’t eliminate the need for judgment.
I’ve noticed something else, though. Building is the part of my week with the cleanest feedback loop. When something harder is waiting, such as a difficult conversation or a decision without a clear answer, it’s also the easiest place to go.
Why Coding Feels So Good
The executive job offers very little of what building provides.
Coding gives you fast feedback, a tangible artifact, a clear sense of progress, and at least some objective way to tell whether you got something right. Executive work is usually the opposite. Decisions are ambiguous. Outcomes arrive months later. The answer is rarely obvious. And the people you would normally think out loud with are often the people your decision affects.
That last part is more common than most leaders admit. Gallup’s 2026 State of the Global Workplace report found that, compared with individual contributors, leaders were more likely to say they had experienced loneliness the previous day. For a CTO coding again, the codebase can quietly become the place that fills that gap.
That doesn’t make the pull unhealthy. It explains why it is so strong.
It also creates an important distinction:
Are you coding because you want to understand the technology, or because you want to control the outcome?
A CTO who builds to understand what agents can actually do, test a technical assumption, or explore a new capability can bring that knowledge back to the organization.
A CTO who builds because it’s easier to make the thing themselves than to navigate the people, decisions, and ambiguity required to get it built is doing something else.
Why CTOs Should Code
The upside deserves an honest look.
Hands-on time keeps technical judgment current when the tools change month to month. Engineers can tell quickly whether a leader understands what they’re being asked to do, and time in the code earns credibility.
It also lets a CTO evaluate agent claims directly rather than through a demo, which matters a great deal when the CEO has seen the same demo and drawn bigger conclusions from it.
So yes, CTOs should be getting their hands dirty.
The trouble is that the CTO’s job isn’t mostly technical.
The Job Only the CTO Can Do
Where you sit matters here. At a five-person startup, the CTO is often the strongest engineer in the building, and shipping code is the job. At a 5,000-person company, a CTO who is still on the critical path is usually a bottleneck. James Stanier makes the same point in LeadDev, describing a spectrum that runs from the founder-CTO still writing most of the code to the enterprise CTO who rarely touches it.
Most CTOs I work with are somewhere in between or trying to figure out their altitude, which is exactly why this gets hard. The job changes underneath you gradually, and the habits that made you effective at 50 people can quietly work against you at 500.
As Camille Fournier put it years ago in her post on the role of the CTO, “The CTO is an executive first, a technologist second.”
In practice, that means the CTO is accountable for how technology turns into business results, and the CEO and board hold them to it. For a CTO coding again, that accountability doesn’t shrink just because the commit history grows.
What the Codebase Can’t Do
Most of that work is ambiguous and slow to pay off. It looks like a reorg that needs thinking through, a budget negotiation with the CFO, a performance conversation that has been postponed twice, or a hiring decision for a leader two levels down.
The codebase can’t negotiate your budget.
It can’t tell an underperforming VP that the role isn’t working.
It can’t resolve the disagreement between you and the CEO.
And it can’t decide whether the organization needs another engineering leader.
None of that work goes away when the CTO steps back from it. Someone else ends up absorbing it, or it simply stays undone.
There’s also less slack to catch it than there used to be. The same Gallup report found manager engagement fell to 22% in 2025, down from 31% in 2022, and points to organizational flattening and larger teams as part of the story. In a flatter organization, the leadership work a CTO sets aside leaves a bigger gap, and fewer people are positioned to fill it.
Five Signs the CTO Coding Again Has Become Hiding
In the CTOs I advise, and honestly in myself, a few patterns tend to show up when building has quietly shifted from leverage to avoidance.
None of these means “stop coding.” They’re warning signs that tell you to look at what the coding is replacing.
The common thread is simple: none of these patterns comes from the coding itself. They come from what the coding is replacing.
A Self-Test
If you’re a CTO coding again, these questions are worth an honest answer.
- Looking back at this week, what got pushed aside so I could build?
- If I asked my team, would they say my code helps them or competes with them?
- Is anything the team depends on waiting on me, or am I working at the edges where nothing is blocked?
- When did someone last reject or substantially rework one of my pull requests?
- If my CEO laid my calendar next to my commit history, would I be comfortable with what they saw?
What Healthy Building Looks Like
The CTOs who handle this well aren’t necessarily coding less. They’re clear about what the building is for.
The Underlying Principle
For a CTO coding again, every one of these practices comes back to the same test: does the building feed the leadership work, or compete with it?
Building that sharpens your judgment, informs a decision, or helps you understand what your teams are working through is leverage.
Building that quietly replaces a decision you should be making is something else, even when it produces a working prototype.
Building is the one part of the executive week that reliably tells you when you got it right. That’s exactly what makes it so easy to hide in.
A Final Thought
I’m not going to stop building, and I don’t think most CTOs should either. Time with the tools has made me a better advisor, and my Python keeps getting better.
What I try to do is keep it honest, which mostly means noticing when the keyboard has become the place I go to avoid something harder.
The CTO coding again can be one of the most useful things happening in an engineering organization right now.
It just has to stay in service of the job rather than take its place.
If this one landed close to home, you’ll find more on the leadership side of the role in our CTO Coaching articles. We also talk through many of these topics with peers in our CTO Roundtables.
Ready to talk about CTO coaching with Leigh?
Book a 30-minute introductory call to explore whether coaching is right for you.
