Does the Role of CTO Still Mean Something in the Agentic Age?

I’ve been thinking a lot lately about what it actually means to be a CTO. Not theoretically, but personally. For most of my career, my pathway was reasonably clear: I was a technologist. I built things, wrote software, designed systems and solved technical problems. I founded a technology company and, perhaps inevitably, became its CTO. Technology was the scarce capability I possessed.

Increasingly, however, I find myself doing something different. I’m spending less time thinking about how something should be built and considerably more time deciding what should exist in the first place. What problem are we solving? What outcome are we trying to create? What constraints matter, and what does good look like? Once I’ve worked through those questions, another increasingly follows: can I instruct an agentic system to work out the rest?

That’s a very different relationship with technology. The more capable those systems become, the more I find myself moving away from the traditional role of CTO and toward something that looks much more like the role of CEO. That transition has forced me to confront an uncomfortable question: if someone who has spent most of his career building technology is deliberately moving away from its production at precisely the moment it is becoming more powerful, what exactly is changing?

Perhaps the question isn’t simply how AI will change the CTO. Perhaps it’s more fundamental: does the traditional role of CTO still mean something in the Agentic Age?

It’s easy to forget how unusual the ability to build technology has historically been. There are more than eight billion people in the world, yet SlashData estimated approximately 48.4 million active software developers globally by late 2025. That’s around six developers for every thousand people on the planet, and its estimate for professional developers is smaller again. ^[1]

Even across advanced OECD economies, where technical capability is much more concentrated, ICT professionals represented only around 3.1% of employment in 2024. Historically, those populations were considerably smaller. ^[2]

Within that already scarce group, capability was never evenly distributed. There is an enormous difference between being able to write some code and being able to understand a complex organisation, design an appropriate architecture, build reliable systems, operate them, evolve them and make sound technical decisions under uncertainty. Good technical operators were scarce. Good architects were scarcer, and people capable of connecting technology to commercial strategy were scarcer again.

That scarcity shaped the organisations we built around technology. We created engineering departments because technical capability needed to be concentrated, and engineering management because that expensive capability needed to be coordinated. Architecture functions emerged because complex systems exceeded the ability of individual developers to reason about the whole. Eventually, we placed someone above those structures: the CTO.

Seen through that lens, the CTO wasn’t created simply because organisations inherently require a Chief Technology Officer. The role emerged because technological capability was scarce, specialised and difficult to coordinate. That distinction matters, because agentic systems are beginning to attack the underlying scarcity.

We’ve been making software development easier for decades. Assembly gave way to higher-level programming languages, languages gained frameworks, and infrastructure moved into the cloud before becoming managed services. Entire technology functions became SaaS products, while low-code and no-code platforms lowered the barrier further. Each abstraction allowed fewer people to accomplish more.

But throughout almost all of those transitions, one thing remained remarkably persistent: somebody technical still had to translate intent into execution. The business could explain what it wanted, but somewhere downstream a technical operator had to convert that requirement into a system.

Agentic computing changes that relationship. Increasingly, we can describe a desired outcome in natural language and have a system investigate the problem, formulate a plan, interact with tools, write software, inspect existing systems, test its work, respond to failures and iterate toward the outcome.

None of this means autonomous agents can reliably build and maintain every production system today. They can’t. Long-running software development remains particularly difficult, and the current version of Zhenfeng Cao’s 2026 paper Agentic Software points to benchmark evidence showing a substantial performance drop when agents move from isolated tasks into sustained software evolution. ^[3]

But arguing about whether agents can currently replace an entire engineering organisation risks missing the bigger change. I’m less interested in whether an agent can do everything a software engineer can do than in how much of the machinery that historically existed between human intent and technical execution still needs to exist. How quickly is that machinery being compressed?

A recent paper helped crystallise this for me. In June 2026, Zhenfeng Cao published an arXiv preprint under a deliberately provocative title: The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm. Within days, the title and conclusion had been revised, and the paper became Agentic Software: How AI Agents Are Restructuring the Software Paradigm.

That change is important. The argument became more nuanced: software engineering isn’t simply disappearing. Instead, Cao argues that the definition of software itself is changing. In traditional systems, humans write the decision logic in advance and encode it into software. In an agentic system, the reasoning engine increasingly determines what actions to take at runtime, generating code and using tools as necessary to achieve an outcome. ^[3]

Cao describes the transition as:

It’s a deceptively simple distinction. Under the first model, AI helps humans produce the software that produces the outcome. Under the second, the human describes intent and constraints; the agent plans, executes, validates and returns the outcome.

The code may still exist — sometimes a great deal of it — but it becomes an instrument used by the system rather than necessarily the product around which the entire process is organised. That begins to explain what I’m seeing in my own work. ^[3]

Think about the organisational chain historically required to turn a business idea into functioning technology. It might have looked something like this:

Every layer existed for a reason. Complexity needed to be translated, technical decisions made and work decomposed so that specialists could execute it. Quality needed to be checked and infrastructure operated. Agentic systems don’t need to eliminate every one of those activities to fundamentally change the economics; they merely need to compress enough of them.

A CEO might increasingly be able to say:

From there, an agentic system can begin decomposing the problem itself. Other agents can research, architect and execute, while others test the work and challenge the output. The human moves progressively upward.

Cao describes that emerging human role as moving from code author toward intent architect, coordinator and auditor. In his proposed progression of agentic engineering, the role continues moving upward again: architect, orchestrator, and eventually goal setter and governor. ^[3]

That progression caught my attention because, if you follow it far enough, it stops sounding very much like software development and starts sounding remarkably like executive leadership.

Perhaps the biggest change I’ve noticed isn’t what the agents can do, but what I increasingly don’t need to do. Historically, I would approach a technology problem through implementation. Increasingly, I can begin much further upstream.

Then I can instruct systems to investigate and execute increasingly significant parts of everything underneath those questions. My role becomes judgement: challenging assumptions, examining the architecture, interrogating the commercial rationale and recognising unintended consequences. I’m connecting decisions to the broader organisation, allocating resources, determining risk and deciding whether we’re solving the right problem in the first place.

That’s not really the job of a software developer. Increasingly, I’m not convinced it’s even the traditional job of a CTO. It looks much more like the job of a CEO, which creates an interesting paradox: technology has never been more central to what I do, yet I’m becoming less involved in directly producing it.

My technical experience hasn’t become irrelevant. Quite the opposite: it gives me the judgement necessary to recognise good technical decisions, bad ones and dangerous ones. But the economic value of that experience is shifting away from my ability to personally execute.

This is where the argument becomes uncomfortable for companies like Neon Light. Historically, software development was something we sold, and that made complete sense. Clients had problems they couldn’t solve because they lacked the technical capability required to solve them. We possessed that capability, and the scarcity created value.

I’m increasingly unconvinced that software development itself should remain a primary part of our offering. Not because software is becoming less important — there will almost certainly be vastly more of it in the world — but because the production of software is becoming progressively less scarce.

That’s a very different proposition, and we can see the economic moat around software production eroding before our eyes. A capability that historically required specialists, substantial capital, large teams and significant time can increasingly be accessed through natural language and relatively inexpensive compute. The output isn’t uniformly good, safe or maintainable, but the direction is clear enough that ignoring it feels more dangerous than acknowledging it.

When the cost of producing something falls substantially, the market eventually reprices its production. Software development doesn’t have to disappear for software development as a differentiated service offering to come under enormous pressure. It simply has to become sufficiently accessible.

At that point, software becomes increasingly analogous to infrastructure: still essential, still technically complicated underneath, and still capable of catastrophic failure when handled badly, but progressively less likely to be the thing a customer considers their source of competitive advantage. It becomes an implementation detail.

This is where the transition becomes particularly relevant to Neon Light. We’ve already been moving the business upstream, with our own process framed around four stages:

When we originally formalised that process, those stages represented a way of approaching complicated technology engagements properly. Viewed through the Agentic Age, however, something else becomes apparent: agentic systems disproportionately attack Deliver. They make production cheaper, increase implementation capacity, reduce the number of people required to execute and shorten iteration cycles. They allow technical work to happen in parallel and increasingly convert implementation knowledge into something accessible on demand.

But making Deliver cheaper doesn’t automatically make the other three stages easier. In fact, it may make them more important. If an organisation can build almost anything, discovering what actually matters becomes more valuable. If implementation is cheap, diagnosing the correct problem becomes more important than rapidly solving the wrong one. And if technical capacity becomes abundant, designing the right system, organisation and operating model becomes the differentiator.

Then Deliver becomes what it arguably should always have been: the execution of decisions already made well. That is a significant validation of where Neon Light has been heading. Our value doesn’t need to be our ability to supply more implementation capacity; it can sit in helping organisations make better decisions about technology.

That means understanding the problem, diagnosing the organisation, designing the architecture, defining the operating model and establishing governance. It means identifying where humans should remain accountable, determining where agentic capability creates genuine leverage and where it simply introduces more complexity, and then orchestrating the capability required to deliver the outcome.

Removing software development from the centre of our offering therefore isn’t retreating from technology. It may be recognising that technology production itself is moving downstream in the value chain. The scarce capability is moving upstream.

I don’t think the answer is simply that the CTO disappears, but I suspect the role splits.

Someone still needs to decide which decisions agents can make and which require humans, what information they can access and what authority they can exercise. How do agents identify themselves, how is their activity audited, and how do autonomous systems interact?

There are also decisions about which models and platforms an organisation should own and which it should rent, where organisational knowledge lives and how agent performance is measured. And someone has to answer the most uncomfortable question: who is accountable when an autonomous system produces exactly what was requested, but the request itself was wrong?

Those aren’t simply software engineering questions. They’re questions about organisational architecture, authority, risk and strategy. The future CTO may therefore be less responsible for running a technology department and more responsible for architecting the relationship between people, information, technology and autonomous systems.

That is a substantially different role, and potentially a far more important one. But it also implies something uncomfortable: a significant amount of the work currently performed under the title CTO may not survive the transition.

For much of the technology era, one of the most consequential questions in business was: can we build this? That question created enormous industries — software companies, technology consultancies, system integrators, engineering organisations, outsourcing markets and cloud providers. Entire careers existed because turning an idea into functioning technology was difficult.

Agentic systems increasingly answer: probably. And when can we build it? becomes easier to answer, the harder questions move elsewhere. Should we build it, and why? What problem are we actually solving? What does success look like, and what should remain human?

Those questions extend well beyond the system itself. What happens to the organisation if this works, or if it fails? Where does our advantage come from when our competitors have access to the same models? And perhaps the biggest question of all: what should we do when our ability to execute is no longer our primary constraint?

Those are questions of judgement, direction, context and accountability. Ultimately, they’re questions of leadership.

Yes, but perhaps not in the way it once did. If the CTO is primarily the organisation’s most senior technical operator — the person who controls the machinery required to translate business intent into software — then I think that role is facing genuine disruption. The scarcity upon which it was built is eroding.

If the CTO instead becomes responsible for designing how people, agents, information and technology operate together, then the role may become considerably more important. But that’s an evolution, not simply a new collection of tools added to an old job description.

For those of us who have built careers around technical capability, there is an uncomfortable question worth asking now: how much of what I do has value because technical execution is genuinely valuable — and how much has value because technical execution used to be scarce?

I’ve started asking myself that question. The answer is changing my own role, it’s changing Neon Light, and increasingly I think it’s changing how we should define technology leadership itself.

Perhaps the ultimate consequence of the Agentic Age isn’t that everyone becomes a developer. It’s that fewer people need to be one. Technology doesn’t disappear, software doesn’t disappear and engineering doesn’t disappear, but the implementation layer becomes thinner.

The people who historically built their value around operating that layer face a choice: compete with increasingly abundant execution, or move upstream toward the things that remain scarce:

judgement, intent, architecture, direction and ownership of outcomes.