AI Guide for CTOs
The million dollar question: What to do with AI?
AI is rapidly transforming software development. CTOs get pressure from business, product management and the CEO to adopt AI to the maximum to cut costs and increase speed.
On the other hand, AI creates problems with maintainable code, developer roles, chaning AI models and tools.
Based on talks with many CTOs and experimenting with AI myself, here is my current guidance on AI for CTOs.
Experiment more
No one knows what is going on. The futuree 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? Constant experimentsx let you learn about AI and you, something no one can do for you.
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.
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.
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. 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.
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.
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.
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”
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. 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 etc.
AI is not about “more code, faster!”
AI has many benefits for developers, finding bugs, fixing bugs, explaining code, suggesting migrations, summarizing framework usage, and much more. If you’re AI usage is focused on generating code, and this is all what you communicate to developers, you’re doing it wrong.
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.
