A CTO I know approved an AI coding tool rollout he did not understand. The technology was within his reach, he had not touched one in nine months, so he no longer knew which questions to ask. He sat through the vendor demo, nodded at the architecture slide, asked a question about pricing, and signed. Three months later his team was dealing with consequences he had not anticipated, and he still could not explain which questions the rollout process had failed to ask.
When I asked him what questions he wished he had asked, he paused for a long time. “I did not know what I did not know. I had not used the thing recently enough to know where the failure modes are.”
He is not unusual. The CTO who drifts from practice does not lose capability overnight. It happens over quarters, one delegated decision at a time, until the distance between their judgment and the technology their team uses every day becomes a gap someone else has to fill.
In IBM’s 2026 CEO Study, seventy-six percent of CEOs said their organizations now have a Chief AI Officer, up from twenty-six percent a year earlier. The study surveyed more than two thousand CEOs. The role is real, it is growing, and in engineering organizations it often fills the judgment vacuum created when the CTO steps away from the tools.
What becomes scarce when production is abundant
The last several months of data have made something visible. AI made software production abundant: code generation is faster, cheaper, and available to more people than at any point in the history of the profession. Recent writing here has traced that abundance through the productivity paradox, the 5x myth, comprehension debt, and the economics of build versus ownership.
What becomes strategically scarce once production is abundant? The organizational capacity to maintain, govern, and evolve what gets built. Judgment about what to build, whether to build it, how to keep it alive after the initial excitement fades, and when to stop before maintenance costs exceed the value produced. That judgment does not come from reading quarterly reports. It comes from proximity to the work.
The CTO’s job shifted. When production was the constraint, the job was to accelerate it. Now that production is abundant, the job is to govern what remains scarce: the judgment about what to keep, what to kill, and what to never build in the first place. The CAIO often enters the engineering conversation when the CTO has stopped supplying that judgment, whether or not the role also has a legitimate enterprise-wide mandate.
The credibility moat
I write code every day. I build my own tools, I maintain my own MCP servers, I run my own automation pipelines. The purpose is credibility, not productivity. A CTO who builds daily is harder to fool with a demo because sustained practice gives them questions the demo cannot answer. They know what “works in staging” means versus what “survives three months of production traffic” means. They know which architectural shortcuts a vendor demo hides because they have made those shortcuts themselves last week.
The drift happens gradually. Hands-on technical work falls from a meaningful share of the workweek in year one to nearly nothing by year four, as meetings, strategy, and organizational management consume the calendar. LeadDev’s 2026 Engineering Leadership Report offers a more current signal: forty-four percent of CTOs or equivalents reported doing more hands-on coding and code review than the prior year. That figure suggests some leaders are moving back toward the work, perhaps because distance has cost them something they cannot recover by reading a summary.
Venture capital due diligence has required this for decades. Camp’s Venture Capital Due Diligence lists the CTO’s ability “to contribute personally to research, development, and/or engineering because of up-to-date in-depth knowledge of the technologies in which the company is involved” as a screening criterion. Investors formalized what practitioners feel intuitively: a CTO who cannot evaluate the work personally is managing by narrative, not by judgment.
Gupta makes the exception explicit in his engineering leadership guidance: avoid delegating “tasks that require your unique perspective.” High-criticality work “should be handled by EMs and leaders.” The delegation orthodoxy never said delegate everything. It said delegate the mechanical so you can focus on the irreplaceable. The problem is that when AI makes the mechanical invisible, the CTO forgets what the irreplaceable part was.
What fills the vacuum
A European automotive company appointed a CAIO whose first decision was to require every AI agent to be registered before deployment and to block MCP servers unless fully documented. Approval became slow enough that teams stopped using the word. “Just prompts, skills, API calls, anything but agent,” one engineer on the inside said. “Saying that out loud would cost us our jobs. So we simply do not call things agents anymore unless we have to.”
The CAIO is doing what the position currently gives them: creating gates. In this organization, the CAIO could evaluate, classify, and approve, but could not redirect engineering resources or override architectural decisions. That left gates as the most visible instrument of authority, and when those gates slowed delivery, teams created naming workarounds that left the organization with less visibility than it had before the role existed.
I am not arguing the CAIO is illegitimate. IBM’s research found that companies with a Chief AI Officer had a five percent higher return on their AI investments. The enterprise-wide mandate (legal, workforce, data, customer operations) is real and growing. But the engineering-governance portion, the slice that determines whether AI-generated code ships safely, whether agent architectures hold under load, whether the tools your team uses daily are worth their cost: that portion cannot be delegated to someone who does not build.
The practice that keeps it yours
The Stanford Digital Economy Lab statement published in July gives that choice a useful frame: “guide AI to complement humans rather than simply imitate them.” The CTO who keeps building contributes the judgment, context, and practice AI cannot supply. A CTO who delegates every technical decision gradually becomes a coordinator, and coordination is exactly the layer organizations can ask AI to absorb. Acemoglu co-signing that statement means the framing transcends optimism versus pessimism. The choice is whether the CTO keeps enough contact with the work to challenge the model’s output, or becomes the person who approves a process someone else designed.
The operational version is simple enough to start this week: before signing a purchase order for an AI tool, use it yourself for two weeks on a real task. Not a demo, not a sandbox, not a summary from your staff. Know the failure modes from your own hands. Know what it cannot do, where it hallucinates, how it handles the edge cases your team will hit in month three. If it requires credentials, understand the scope of what you are granting. If it generates code, read the code it generates for your codebase, not the codebase in the vendor’s marketing video.
One bounded commitment, repeated with every tool decision that crosses your desk, maintains the muscle that atrophies the moment you start approving things you have not touched.
The CAIO debate is evidence of an industry problem, not a solution to it. A new title does not restore the judgment that left the room when the CTO stopped building. It just gives the vacuum a name and a reporting line.
I am writing more about what that daily practice looks like, and about knowing when not to build it myself. That is a narrower question than which software a company should own, and the answer is less obvious.
Ricardo
