All blog posts
AI this and AI that? A CTO's perspective
What working with AI looks like for a CTO beyond the hype: going AI-native in development, building safeguards when the output reaches boardrooms, and the costs few talk about.
· 5 min read
Contents5 sections
AI has changed how we build software at Odyssey, and I count myself among the converted. Making it work when our output ends up in our clients' decisions has taken safeguards, senior judgement and a sober view of the costs, and those rarely appear in posts about AI.
Most of what is written today is about AI in one way or another, and this text, too, was written with Claude, my “buddy” with a capital C. It is not the euphoric, evangelical post you normally see, even if I count myself among the converts.
A large share of posts on LinkedIn are about AI in some form, and my feed on X is full of it too. I also see how tired many people are of the topic, and I count myself among them.
What tires people is often less the subject than the euphoria, the bragging and the herd mentality, with AI presented either as a saviour or as the thing that will ruin us. In my experience, neither picture is the whole truth.
Much of what is written contains some truth and a lot of exaggeration, and it is often hard to tell what was written by AI, what is true and what is made up. AI is good at producing all of these, but it learned them from us.
Becoming AI-native in software development
I am the CTO of Odyssey, a scale-up in market and brand research. We deliver a SaaS service that gives our clients brand trackers, brand positioning, trend analyses and other decision-making data, digitally and continuously.
We have gone from a larger to a small, lean organisation, largely because we invested early in automation and digitalisation. AI has become one more part of that work.
For a long time I saw parts of the AI hype as just that, hype. In recent months that has changed, because of what happens in day-to-day work rather than headlines or demo videos. In writing code and building digital solutions, the tools have gone from impressive to something that changes how we work.
We have gone from deep scepticism to what I would call AI-native. Most of our development now happens with AI, including code, new features and services, and we also use it to maintain our existing codebases.
The turning point was the tooling rather than a new model, since the models have probably been good enough for six months or more. When tools like Claude Code and similar command-line AI assistants matured, we could fit AI into a real development process instead of using it as an advanced autocomplete.
The other half was finding a method. Our workflow now looks like this:
- AI documents and structures the work.
- We give it detailed context about what is being built.
- We manage its memory and history deliberately.
- We guide it with planned steps and clear instructions.
It resembles a traditional development process, and fundamentally it is one, but with AI it is far more productive. Finding this model took time.
Why AI needs safeguards when the output reaches the boardroom
It is not as simple as it looks. Our data and deliverables are used inside our clients' decision-making processes and leadership teams, as steering instruments.
If AI got something wrong without safeguards and verification, the result would not stay in a chat window. It would end up in a boardroom presentation, a strategic plan or an investment decision.
Being wrong is not allowed.
AI is sometimes wrong, and that is built into how the models work. They hallucinate, jump to conclusions and present uncertainty as fact. In a consumer app that can be annoying, but where the deliverable is decision-making data it can do real damage.
So we build safeguards:
- Architectures where several AI agents check each other, with layers of validation.
- Protection of our clients' data and our own intellectual property, so that nothing leaks.
- Protection of the service against uses it was not designed for.
This is what keeps me up at night: one AI uses "best practice" to create something, and another AI uses "best practice" to validate it. Is that really the best practice we want? When best practice validates best practice, who is doing the thinking, or being creative?
I like the new tools, and I am becoming AI-native in everything I do. I still believe that experience, knowledge and above all human judgement are needed to validate business outcomes, quality, security and whether what is being built is sound, at least with today's language models.
This part of working with AI rarely shows up on LinkedIn. It is slow, detailed and necessary work, and it does not fit in a 30-second demo.
The costs of running AI in production
Cost is the other issue few people discuss. Experimenting with AI is relatively cheap, while running it in production at enterprise scale, with requirements on reliability, security and performance, is much more expensive.
API costs, compute, infrastructure for monitoring and failover, and the expertise to manage it all add up quickly. For a small organisation like ours it is manageable, but for large organisations rolling AI out at scale the sums become significant.
There is also the cost of wrong choices. A poorly guided AI can produce architectures, infrastructure decisions or code that look reasonable but are fundamentally flawed. By the time this is discovered, more has been built on top, and undoing it can take a great deal of time and money.
This is why seniority matters. Experienced people need to evaluate what AI produces, steer it in the right direction and catch mistakes before they compound. Without that guidance, AI becomes a liability.
Then there is the uncertainty in the AI companies' own business models. They are spending capital very fast, which raises the question of when prices will rise. It is nearly impossible today to project what AI will cost in two years, and that is a real problem for anyone building a business on it.
Meanwhile, leadership and clients who have seen the demo videos expect AI features to be delivered quickly. Going from a demo to something reliable enough to steer business decisions takes time, investment and senior people who can guide AI toward the right architecture.
What AI requires from an organisation
AI has changed how we work, in our organisation, our code and our product development. We went from cautious sceptics to believers by doing the work ourselves.
It also requires a few things:
- An understanding of what AI can do, and equally of what it cannot.
- Control, planning and senior architectural judgement, especially where what you deliver influences other people's decisions.
- Building properly instead of chasing what looks impressive in a demo.
AI-assisted workflows at Odyssey
At Odyssey we are now moving all our internal processes to AI-assisted workflows. We have tested, failed, adjusted and found something that works. That is our own odyssey, and it is far from over.
Related product: Odyssey Brand Signal, the brand tracking platform
About the author
