AI Strategy for CTOs

The million dollar question: What to do with AI?

AI is fundamentally reshaping software development. As a CTO, you’re under constant pressure from business leaders, product managers, and CEOs to leverage AI for delivery speed. But adopting AI isn’t just about efficiency - AI enables companies to generate more ideas and bring greater ideas to market than before. AI makes developers and CTOs creators again. AI introduces new challenges: maintaining code quality, redefining developer roles, and keeping up with rapidly evolving AI models and tools. After countless conversations with CTOs and hands-on AI experimentation, here’s my actionable guidance for CTOs navigating the AI transformation.

Overcommunicate

Communicate that you’re doing AI. And talk about AI. And talk about AI. And talk about AI. Until everyone knows you stand for AI and tell you to stop being annoying.

Don’t treat it as a sidegig

AI is not a sidegig. It needs to be the center of your tech vision and strategy. Don’t treat it like a sidegig, it’s not just another tool, it’s the main course.

AI is not cloud

AI is a distruptive technology. Too many of the CTOs I meet treat is as just another technology like cloud, to decrease cost and increase efficiency. AI is not. AI is disruptive and will change all software development around it. Those companies who thought the internet was just like telefax, are no longer.

Experiment more

No one knows what is going on. The future is wide open. You need to experiment more with AI, what tools work for you, what tools do not work for you. Do you need your own AI model? Do you need to fine tune an AI model instead of writing source code? Local RAG with a vector database? Constant experiments let you learn about AI and you, something no one can do for you or tell you about.

Hire people - interns if no money - to find out what AI means for you

With your services and your data and your business model, only you know what AI means for you. Hire people to find out what AI means for your company. If you don’t have the money, hire some interns now, like yesterday.

Have a new product funnel

Experimenting more needs to have process. One suitable process, depending on the size of your company, is to produce one Prototype per day. Prototypes are for playing around and finding out if an idea makes sense. People can take a look at the prototype and discuss it.

From the prototypes, find the one that has the highest potential. Once a week create an MVP from that prototype. The MVP is there to show it to customers and discuss it with customers, find out it they need it (not want it).

AI needs more guardrails

AI needs more control. What worked when the guardrails were in the heads of the developers, now needs to be explicit. We forgot the many things developers have in their head - only a small portion is described in each ticket.

Architecture guidelines, screenshots, domain models, coding style, security requirements. All of these need to be documented in the project so the AI will do the right thing. AI without the guardrails produces unmaintainable, buggy code.

Human vs AI ownership of code

Declare all modules and microservices as either AI or Human owned. AI owned modules need different rules and guardrails than human owned modules. What do you need to confidently deploy AI owned modules to production?

My tip would be to read the test summary of the AI module - like in the old days where as CTO you would take a look at the manual test list and decide: If all of that works, I’m confident we can deploy.

For human owned modules: All code generated by AI here is onwed by the developer who told the AI to produce it. In a crisis, “the AI wrote this” is not a valid defense. You generate it, you own it. You need to understand the code, review the code, test the code. It’s your code, just like with autocomplete before (“The IDE autocompled the line, I didn’t write it” was never an excuse).

Over time, migrate human owned modules to AI owned modules.

Have people with AI in their title

Only if people have AI in their title, it will be in their mind 100% of the time. And then there is someone in your org who relentlessly pushes AI. If someone has AI in their title, they will get into the company in the morning and think “What can we do with AI?” Everyone else has something different on their mind.

Have teams with AI in their name

You don’t want to have taken AI away from you. To make it clear, that AI is with technology, rename data team to “AI & Data”, rename “DevOps” to “AI Infrastructure”. Expect resistance from all sides.

Have MCP everywhere

MCP is an easy step towards utilizing AI. Add MCP to all your services. Perhaps MCP will even replace REST in your microservices or public API. MCP (Github) can help you with DevOps, e.g. fixing that CI/CD pipeline. MCP (Linear) can read a ticket. MCP (Figma) can get the design. MCP (Playwright) can check if the code works in the UI as intended.

Set minimum standards for AI usage

Not enough CTOs talk about their expectations. AI is no different here. Tell developers what your expactations around AI are. Set a minumum standard for AI usage, like “Everyone uses Cursor”, or “Bugs are fixed with Claude Code”

Metrics

Start with adoption metrics, e.g. every developer uses AI each day. Progress to impact metrics, e.g. halfing time to market, doubling the number of tickets per sprint. Show AI impact in a meaningful way - the CEO will ask you about that metric.

Promote people to “Product Engineer”

The developer role might change - as with every revolution (the internet brought us DevOps, CTOs and product managers). One guess is that with AI developers will take up more product reponsibility and we will see product engineers become a ting. If this is your strategy, define the role and requirements and promote people to it if they are able to do it. This creates pressure to not be left behind.

Have an AI strategy

Have an AI strategy.

Have an AI policy

Have an AI policy around AI usage, data usage, third party providers, privacy, data leaks, ethics etc.

AI is not about “more code, faster!”

AI has many benefits for developers, doing the boring stuff (like renaming all variables in the project to match the style), finding bugs, fixing bugs, explaining code, suggesting migrations, summarizing framework usage, and much more. If your AI usage is focused on generating code, and this is all what you communicate to developers, you’re doing it wrong. What is in it for the developer?

Have prompt training

Prompting is like project management. Everyone thinks they can just do it, there is nothing to it. But there is a huge difference between good and bad project management - one reason many projects go bad.

The same happens with prompting. Everyone thinks they can just do it, there is nothing to it. But there is a huge difference between good and bad prompting.

Invest in prompt training.

Frequently Asked Questions (FAQ) about AI for CTOs

What are the key benefits of AI adoption for software development teams?

Less boring work, mostly. Developers hate writing boilerplate, renaming variables across 50 files, and writing the same CRUD endpoints for the hundredth time. AI does that now.

The real benefit isn’t “faster code” - it’s that your senior engineers can focus on the hard problems instead of the tedious ones. I’ve seen teams where AI handles 60% of the grunt work, and suddenly those expensive senior developers are actually doing senior-level thinking.

How can CTOs encourage developers to embrace AI tools?

Set the expectation. “Everyone uses Cursor” or “Bugs get fixed with Claude Code first.” Make it the default, not an option.

Then get out of the way. Some developers will resist. That’s fine - give it three months. The ones still refusing to use AI while their teammates ship twice as fast will either adapt or self-select out.

Don’t make it about replacing developers. Make it about giving them superpowers.

What should an AI policy for engineering teams include?

The basics: what data can go into AI tools (spoiler: not customer PII), which tools are approved, who pays for licenses, and what happens to code ownership.

But honestly? Most AI policies I’ve seen are 20 pages of CYA that nobody reads. Keep it to one page. The main points: don’t put secrets in prompts, review AI-generated code like you’d review any code, and use your judgment.

How does AI change the role of developers?

This is the big question, and nobody knows the answer yet.

My guess: we’ll see fewer “I just write code” developers and more “Product Engineers” who own features end-to-end. If AI can write the code, the value shifts to knowing what code to write. That means understanding customers, making product decisions, and thinking about the business.

The developers who thrive will be the ones who treat AI as a junior developer they’re managing - not a replacement for thinking.

Why is prompt training important for developers using AI?

Because prompting is a skill, and most developers are bad at it.

I’ve watched developers type “fix this bug” into Claude and then complain that AI doesn’t work. Meanwhile, another developer writes a detailed prompt with context, constraints, and examples - and gets working code in one shot.

The difference between good and bad prompting is like the difference between a good and bad project manager. Everyone thinks they can do it. Most people can’t.

What are common challenges when introducing AI to engineering teams?

The skeptics. Every team has them - the developers who’ve “seen this before” and think AI is just another overhyped tool.

They’re not entirely wrong. AI is overhyped. But it’s also genuinely useful. The challenge is getting past the cynicism long enough for people to experience the benefits firsthand.

My advice: don’t argue. Find one early adopter, let them show results, and let social proof do the work.

How can CTOs measure the impact of AI on their teams?

Start with adoption: is everyone actually using it? Daily active users in your AI tools.

Then move to impact: tickets per sprint, time to first PR, bug resolution time. But be careful - these metrics can be gamed. The real test is whether your team feels more productive, and whether you’re shipping more value to customers.

Don’t expect miracles in month one. AI is a skill that takes time to develop.

Is AI only about generating code faster?

No. And if that’s all you’re using it for, you’re missing the point.

AI is better at explaining legacy code than any documentation. It catches bugs in code review that humans miss. It suggests test cases you didn’t think of. It helps junior developers learn faster by explaining concepts in context.

The “more code faster” framing is for executives who don’t understand engineering. The real value is making every developer more capable across more dimensions.