A single tall, mature tree towering above a field of young saplings in morning mist at sunrise.

By now, most CTOs have already seen AI change their personal output dramatically. Whether you call it 10x, 100x, or something else, the practical reality is the same: they can think, analyze, design, automate, review, and ship across a much wider surface area than before. That is not the hard part anymore. The harder question is whether that leverage stays with the CTO, or becomes part of how the company operates.

I came to that question through my own workflow. For years, I have been looking for ways to reduce the distance between an idea and a working result. Earlier, that meant better development workflows, internal tooling, automation, test loops, and small process improvements. Now it also means prompts, agents, permissions, review gates, and workflows where humans and AI can hand work back and forth safely.

But that is still only personal leverage.

If the CTO is the only person who knows how to use AI well, the company has not become AI-native. It has only made its existing technical bottleneck faster.

In a small company, many questions are not purely engineering questions, but they still route through engineering because the context lives there. Is this product idea simple or expensive? What does the data actually say? Why did a customer see this behavior? Can this feedback become a workflow, a report, a design direction, or a product change? Historically, the CTO translates those questions into database queries, code paths, product history, permissions, deployment risk, and sequencing.

The new CTO role is to reduce that translation cost without creating chaos.

At Hero Group, the internal AI work has taught me this directly. The goal was not to give everyone a chatbot. The goal was to put an agent near real company context and real working surfaces, with enough access to be useful and enough boundaries to be trusted. Teammates should be able to ask product, data, design, and workflow questions in natural language and get back something concrete enough to inspect: a data read, a product note, or a proposed change.

Within the right boundaries, it can go further. A teammate can review an AI-built change, approve it, and have it move through merge and deployment without waiting for the engineering team to translate every request into code and release steps.

The important signal is not only that engineers can ship faster. The stronger signal is when non-engineers can move work forward without waiting for every step to pass through engineering.

This is not theoretical for us. In one recent three-month period, about 84% of the questions our internal agent answered came from non-engineers. Our COO, who has never been a frontend engineer, now drives product UI and UX decisions with the agent in the loop: talking to users, working through ideas, and pushing improvements forward.

I wrote more about the operating layer behind that here: Removing the CTO as the Bottleneck.

But passing this leverage to the company is not only a tooling problem. It is a cultural transition.

People do not all work the same way. Some immediately see how to use AI. Some need examples close to their actual work. Some over-trust it; others under-use it. The CTO cannot just build agents and assume adoption will happen.

The internal AI layer is a product. Its users are the people inside the company. The CTO has to watch where they hesitate, which outputs save time, which ones create more review work, and which handoffs feel confusing. Then the system changes: prompts, tools, permissions, and review paths improve as the team learns.

The company learns how to work with AI through real usage, not a policy change. People learn by trying it in their own work, seeing how teammates use it, and building the judgment to ask better questions, inspect outputs, know when to trust and when to challenge, escalate risk, and recognize when a human decision is still the point.

At Hero Group, I have noticed that once teammates start using AI in the flow of real work, they do not really go back to the old default. When the models are unavailable, it feels less like one tool is down and more like the internet is down. The company can still work, but the normal rhythm has changed.

There is also a cognitive cost. AI can help someone produce far more than before, but that often means they now have far more to evaluate: more drafts, more options, more decisions, more context switching, and higher expectations. The work changes shape; it does not remove the need for human judgment.

This is why the CTO has to understand the team, not only the models. AI can be extremely capable and strangely wrong in the same workflow. Helping a company navigate that reality is now part of technical leadership.

Once that adoption loop starts, attention shifts to the work itself. In the age of AI, part of the job is to keep asking: what should no longer require a human to start from zero?

Reports, follow-ups, QA passes, customer summaries, and recurring analysis all contain repeatable patterns. Some parts still need judgment. Some parts need approval. Some parts should never be automated. But many parts can be prepared, checked, summarized, routed, or drafted by an agent before a person touches them.

That does not usually happen because every person in the company independently imagines the future workflow. Most people are focused on doing their job with the tools in front of them. They may not know what can be delegated to AI, what context the agent could safely use, or how a recurring process could be redesigned.

The CTO has to see those patterns and keep looking at ordinary company work, asking where AI can remove repetition, shorten feedback loops, and free people for the parts that actually need human judgment.

This changes what technical leadership has to design. The architecture is not only APIs, queues, Rails models, databases, and infrastructure. It is the AI boundary too: what context the agent can read, which tools it can use, where writes require approval, how actions are logged, what it must refuse, and where human judgment remains the gate.

Cost management becomes part of that system too. If agents are doing real work across the company, the CTO has to know which tasks need the strongest models, which can run on cheaper models, where caching or batching helps, and where another long agent loop is not worth the cost. AI spend should be visible enough to manage, but not controlled so tightly that people stop using it for high-leverage work.

The same redesign has to happen inside engineering itself. It is not only the CTO using AI. Engineers are using it too. Agents are writing code, tests, plans, migrations, and fixes. The amount of code a team can produce in a day is changing faster than the old review process can absorb.

If engineering output becomes 10x but review, testing, deployment, and production monitoring remain 1x, the bottleneck does not disappear. It moves into the pipeline, and the risk goes up with it.

The CTO cannot personally review every AI-assisted diff. A team lead cannot manually inspect every line generated across every branch. But saying no to the speed is not the answer either. The responsibility is to redesign the delivery system around the new output rate.

That means stronger automated tests, AI-assisted review, preview environments, staged rollouts, observability, rollback paths, and clear human gates for anything that can affect customers, money, data, or production stability.

The engineering pipeline has to become AI-native too.

Not because AI should approve its own work blindly, but because a human-only review process cannot be the only safety layer when the volume and speed of work have changed.

That is not a softer version of engineering. It is deeper engineering applied to the operating model of the company. It also requires more understanding of the business, not less. You cannot build useful AI leverage from the codebase alone. You need to understand where operations loses time, what customer-facing teams repeatedly ask for, how product decisions are made, where design gets stuck, and which mistakes would actually hurt customers, money, production, or trust.

This is why I do not think the CTO role becomes smaller with AI. It becomes more architectural. The CTO stops being only the person who makes technical decisions and becomes the person responsible for how technical context can be safely used across the company.

AI can multiply output. It can also multiply bad assumptions, weak permissions, unclear ownership, and messy context. The companies that get this right will not be the ones that simply encourage everyone to use AI tools. They will be the ones that deliberately build the operating layer around AI use.

That operating layer also has to be designed for where the models are going, not only where they are today.

Model capability is moving too quickly for a company to rebuild its operating model from scratch every time the frontier changes. A workflow that feels barely possible today may become ordinary in a few months. A task that needs heavy human supervision now may become safe to delegate later if the context, permissions, evals, and review paths are already in place.

That matters internally and externally.

Internally, it means the CTO has to keep pushing the boundary of what the company asks AI to do. Some workflows may be too expensive, too brittle, or not quite possible today. But in this market, today’s bad fit can become tomorrow’s normal operating path. The company needs someone continuously testing that boundary, so it is ready to absorb the next jump in model capability.

Externally, it means building products and services with the same awareness. If you are building an AI-native product, the roadmap cannot only reflect what models can do this week. It has to account for what they are likely to make possible next, and where your product should be ready to absorb that capability.

This is not about guessing the future perfectly. It is about building a company that can adapt when the future arrives faster than expected.

My current view: the CTO’s job is not to be the smartest AI user in the company. It is to make the work itself smarter: sharper questions, clearer communication, stronger reviews, sounder decisions, and more consistent follow-through across the team. That is where productivity compounds.

Originally published on LinkedIn.