Why Your CTO Might Start Coding Again

The Skills They Developed While Not Coding Are Now Coding Skills

A friend of mine runs a mid-sized software shop that went agentic-only six months ago. His current recruiting pitch would have seemed fairly odd two years ago: he’s actively seeking former development managers who haven’t written production code in years to be software developers again.

“I’ve been running engineering teams for 25 years,” he told me, “and I’ve started focusing my hiring on managers instead of developers. Managers adapt immediately — they’re already used to orchestrating work without doing it themselves, so there are no habits to unlearn [with agentic AI]. They come back within a week saying ‘this is completely different from anything I’ve done before.’”

This sounds kinda crazy. The conventional wisdom is clear: development management is a fine livelihood, but development itself requires continuous improvement to keep abreast of a changing technology landscape, and anyone who stopped coding “fell behind.” The further you got from the codebase, the more your skills atrophied. Technical leadership meant staying technical, and if you let that slip, you were just another guy who used to know things.

The conventional wisdom is wrong. Or rather, it was right for an era that ended about five months ago. Do try to keep up.

The World That Was

The brutal economics of $150/hour shaped everything about how we built software. Only developers could create code, there weren’t enough of them, and they couldn’t do it very fast. Every process, every tool, every org structure optimized around that constraint.

Development managers existed because coordinating expensive humans was itself expensive. Someone had to translate business needs into specifications developers could execute. Someone had to review work product and maintain quality. Someone had to make the build-versus-buy decisions, the this-quarter-versus-next decisions, the what-not-to-build decisions. Someone had to make the organization the sort of place where expensive developers would enjoy hanging their hats. That coordination overhead was worth it because developer time was so precious.

Managers who had once been developers made a rational trade: they gave up the craft of coding for the leverage of orchestration. One good manager could make ten developers more effective. One good CTO could make a hundred or a thousand developers more effective. The math penciled out, even if it meant watching your syntax knowledge slowly decay and your muscle memory fade. You weren’t falling behind. You were moving up (and ideally cashing in).

Then agentic AI made code production nearly free, and a funny thing happened: all that “overhead” turned out to be the actual work.

When the World Changed

I’ve written before about how agentic AI shattered the iron economics of software development. Code went from $150/hour to $200/month. The bottleneck shifted from “writing code” to “knowing what to build.” The skills that justify a developer’s salary are no longer the skills of production but the skills of judgment.

Here’s what nobody seems to have noticed yet: development managers have been accumulating judgment skills for years. That was the job description. Meanwhile, developers have been accumulating production skills that are rapidly becoming commodity.

The conventional path was: developer → senior developer → tech lead → manager. Each step moved you further from code and closer to decisions. We’ve been assuming that path represented a tradeoff — you gained organizational leverage but lost technical currency. What if it wasn’t a tradeoff at all? What if it was just training for a job that didn’t exist yet?

The Skills They Developed While Not Coding

Here’s what development managers were actually doing while they weren’t writing code:

Writing specifications for humans. Humans are ambiguous, forgetful, and need context repeatedly. Humans get distracted and miss requirements. Humans require diplomatic phrasing and emotional management. If you’ve spent years writing specs that humans execute correctly, you’ve been playing the game on hard mode. Prompting an AI agent is way easier than prompting a junior developer with imposter syndrome, student loans, and a hangover.

Reviewing work product effectively. Every PR approval, every sprint review, every “looks good but what about edge case X” — that’s the skill that now matters most. The bottleneck in agentic development isn’t generation, it’s verification. Agents can produce code faster than anyone can review it. Your review bandwidth determines your throughput. Managers have been building that muscle for years. Developers who delegated review to senior ICs never developed it.

My friend put it bluntly: “I’ve never looked at every line of code my developers wrote. I’ve never validated every test case. I trusted the process — PRs, code review, QA, test coverage. That’s how I knew the work was good. Cool, do that with bots. Managers already know how to evaluate output without doing the work themselves. They’re already comfortable delegating and reviewing. And you don’t have people problems with bots.”

Maintaining architectural coherence across multiple contributors. When ten people touch a codebase, someone has to ensure it doesn’t become eleven different codebases. That someone was you. You maintained the conventions, enforced the patterns, caught the drift before it became rot. When ten agents touch a codebase, the problem is identical. You’ve been solving multi-agent coordination problems this whole time. You just called them “team management.” I’ve written about this dynamic using the metaphor of Rembrandt’s workshop — the master maintaining artistic vision while apprentices execute. Development managers have been running workshops for years.

Understanding the business deeply. Here’s one that rarely made the job description but always made the difference: the best development managers understood the actual business. Not just the technical requirements but why those requirements existed. What customers needed. What the market demanded. Where the company made money, where it lost money, and how it spent money. This knowledge was always valuable, but in the pre-agentic world a developer could survive without it, and frankly most developers did. As long as you could convert tickets to code, maybe you didn’t need to understand why the tickets existed. That’s no longer true. When anyone can build anything, the only question that matters is what’s worth building. Business knowledge went from “nice to have” to “the whole game.”

Knowing what not to build. This is the skill that matters most and transfers best. Developers are trained to solve the problem in front of them. Hand them a ticket, they’ll close it. Managers are trained to ask whether the problem should be solved at all. Whether this feature is worth the complexity it adds. Whether the customer actually wants the faster horse that they’re asking for. Whether the elegant technical solution serves the business or just scratches an engineering itch.

“Developers love to gold-plate things,” my friend observed. “Managers ask ‘does this move the needle?’ That’s exactly the mindset you need when you’re orchestrating AI to build software.”

That question — “should we build this at all?” — is now the key to success or failure. Agents will build whatever you ask. The skill is knowing what to ask for.

Who This Threatens

Not everyone wins when the rules change. Let’s name some folks who should be worried.

The “senior” developer who’s really a fast junior. Ten years of experience, but it’s the same year repeated ten times. They ship code quickly. They can’t explain their architectural choices beyond “it’s how I’ve always done it.” They couldn’t pitch an technical recommendation to save themselves. They’ve optimized for velocity in a world where velocity is now nearly free. They’re a very expensive apprentice about to compete with apprentices who cost pennies per hour. The math is brutal and it doesn’t care about their tenure.

My friend shared a story that still hasn’t left me: “I had senior engineers estimate a task at seven days. I sat down and did it in seven hours — and I’m an empty suit who hasn’t had code in production in 15 years. So either they’re wrong about the toy, or I’m some kind of accidental genius. I’m pretty sure I’m not a genius.”

The specialist without breadth. The React virtuoso. The Kubernetes whisperer. The person whose entire value proposition was knowing one thing more deeply than anyone else. When Claude knows everything at the 80th percentile, being 95th percentile in one technology is less valuable than being 70th percentile across the board plus having the judgment to know what matters. Deep specialization was a rational career strategy when learning curves were expensive to climb. Now Claude climbs them in seconds. Specialists are becoming commodities, and commodities compete on price.

The “I just want to code” developer. They actively avoided understanding the business. They didn’t want to know about customers or markets or revenue. Product requirements arrived, code departed, and everything else necessary to ship was someone else’s problem. Headphones on, tickets converted to PRs, optimized for the old game where coding skill was the constraint. That constraint is gone. The tickets are going straight to Claude now, and Claude doesn’t need a human intermediary to convert them. These developers didn’t just miss the new skills — they actively refused to develop them.

The senior engineers in denial. What’s puzzling is the people who should see this clearest often don’t. My friend has watched it happen: “Maybe they’re scared. Maybe they’re stubborn. Maybe it’s an identity crisis — they’ve spent decades believing their job was to code, and now that’s not the valuable part anymore. I’ve heard every excuse: it’s a toy, it hallucinates, it writes bad code, it can’t do anything real, you still need a human to fix everything.” He paused. “I don’t have time to help everyone cross the chasm. I have an engineering team to revolutionize.”

And lest this seem like a triumphalist victory lap for managers: the process manager without technical taste is just as doomed. The ones who managed calendars and Jira boards and “facilitated” meetings but never developed architectural judgment. They can coordinate and massage prickly and expensive humans but they can’t evaluate whether an agent’s output is any good. They don’t know what quality looks like. They can’t distinguish a clean solution from a brittle hack. The management skills that transfer to the agentic world are the technical management skills — the taste, the judgment, the architectural intuition. The administrative skills transfer to nothing. Some managers are going to discover they were overhead after all.

The Convergence

Zoom out for a moment and notice what’s happening to the org chart.

Development managers had deep technical judgment and organizational authority, but outsourced the actual coding.

Product managers had deep business knowledge and customer insight, but outsourced the technical implementation.

Senior architects had deep system design expertise, but often lacked organizational authority to see their visions realized.

These three roles are collapsing into one. When implementation is cheap, the role that remains is: the person who knows what to build, why to build it, and whether it was built well. That’s not three jobs anymore. That’s one job, and it looks more like “orchestrator with coding capability” than “coder with management capability.”

My friend offered one more prediction I haven’t been able to shake: “Technical product managers might be the real winners here. The ones who can talk to customers AND understand architecture. If that pans out, they’re going to rule this new world.”

The question every organization should be asking: what does your structure look like when the ratio of Rembrandts to apprentices goes from 1:10 to 1:100? When one person with taste and judgment can direct an army of tireless agents?

My guess: a lot flatter, a lot smaller, and a lot more technical at the top.

The Invitation

If you’re a development manager who’s spent years feeling vaguely guilty about the code you’re not writing, I have good news: that guilt was misplaced.

You weren’t falling behind. You were developing a different set of skills — specification, review, coordination, judgment — that happened to be less valuable than coding skills in the old regime. The old regime is over. The skills you thought were “soft” turned out to be the hard ones. The skills you worried were “overhead” turned out to be the whole gig.

The developers who spent those same years grinding leetcode and optimizing React renders were training for a game that no longer exists. They’re extremely good at skills that are now nearly free.

You’re not. Your skills are suddenly scarce.

So maybe it’s time to come back to the codebase. Not as the fast coder you once were — no one’s getting any younger. But as something rarer: someone who knows what’s worth building, can recognize quality when they see it, and can orchestrate an army of tireless apprentices toward a coherent vision.

The agents don’t need more parametric coders. They need direction and vision.

Maybe you’ve been training for the job all along.

---

This post was constructed as always with the able assistance of Claude Opus 4.5. If Claude eventually becomes my CTO, I shan’t be a bit surprised. It won’t be the first time that I met someone at the start of their career that I eventually reported to.