13 CTOs walk into a bar and realize: There is no best AI adoption strategy

This March at CTO Craft Conference in London, I sat down over dinner with 13 senior leaders and CTOs and had the kind of conversation you rarely get at conferences. There were no slides or presentations, just talk about how AI implementation works in different companies.

AI is a blessing for some, but a headache for everyone else.

That was one of the clearest takeaways from our CTO dinner in London, where my colleague Ivan Brezak Brkan IBB (Developer Experience Director, Infobip) and I hosted a dinner with CTOs from a dozen great engineering organizations.

Not that I didn’t suspect it, but hearing it out loud, black and white, makes your assumptions impossible to ignore.

For some, AI is putting the fun back into coding. For others? Welcome to AI shaming. Champions are treated like heroes; skeptics get rolled over, dismissed, or quietly frowned upon.

Oh, to finally build again!

As our conversation made clear, it’s no surprise that leaders and C-level execs are more excited about AI than most employees. But that excitement isn’t always about business – sometimes it’s just curiosity, fascination, or even fun.

And I was struck by how many participants talked about the sheer joy of working with AI, finally getting to build again instead of just managing others.

AI has allowed leaders and CTOs to bypass the so-called “atrophy” of framework-specific knowledge, letting them focus on problem-solving and architecture.

In practice, this means more time is spent creating ideas and prototyping, rather than learning the specific technologies needed to build things. One participant noted:

I’d say there’s a bunch of things I always wanted to do but never had time for. I’d either have to get someone else to solve the problem or just live with it.

Now, if I’ve got an itch I want to scratch, I can build it myself. That freedom to solve my own problems also means I can solve more problems for others.

On the topic of prototyping, multiple participants agreed that tasks that used to take several days now take just a couple of hours. This allows leaders to experiment and prototype their own ideas without overloading their engineering teams.

And so far, so good.

Using AI across the organization sounds like a no-brainer: ideas flow, everyone’s impressed at the speed of routine work, and it feels like you’re on the right track. But then it hits you –you haven’t really thought about the people who are actually writing and reviewing the code.

AI shame, shame, shame

While many companies (especially Infobip) actively encourage the use of AI tools in the workplace, an unavoidable “AI stigma” still hangs over the tech space.

This fear often comes from worrying about being perceived as incompetent – or as someone leaning on AI for work they’re “supposed” to do themselves.

We concluded that you could approach it in one of two ways:

Embrace the early Facebook mantra: “Move fast and break things.”

Pause regularly to ensure that the “break things” part isn’t causing too much damage.

The participants of the dinner echoed these statements, with one participant mentioning an example where a pull request was not reviewed because “it looked like AI-driven code”:

One of my engineers was helping an ML engineer make a change in the iOS app. They relied primarily on Claude Code to write it but worked closely with the iOS engineer to test everything thoroughly. They checked and refined the code wherever necessary.

However, when the change was submitted for code review to the team that owned this codebase, it was immediately rejected, with the assumption that the authors hadn’t tested anything beforehand.

I believe there’s no single right or wrong way to approach this. Being overly zealous about AI has its drawbacks: teams may resist because they feel pressured. On the other hand, being too conservative risks falling behind, arriving late to the AI party, and scrambling while competitors are already there, relaxed and sipping champagne.

We all know that in the AI world there’re no universal playbook. What worked in some cases (rushing to full engineering adoption) might be a masterstroke for one organization and a disaster for another.

At the dinner, participants pushed back on the very definition of “AI usage.” Is it opening a tool once a week? Using it daily? Or only when it actually changes how work gets done? Turning employees into internal AI Ambassadors, where colleagues help each other was one of the more promising ideas around the table.

The foundation is laid. Now what?

For us at Infobip, this conversation was something we’ve been living for a while now. We held hackathons, organized education programs, and made moves in infrastructure and security. This made adopting tools like Claude as easy as possible. We’re now at a point where over 80% of the company uses AI tools daily.

But here’s what the dinner made me think about: the subjective experience and the data don’t always agree. When we talk with our engineers, they report feeling more productive. But when we look at DORA metrics or business outcomes, the improvement isn’t easy to correlate.

The funny thing is that everyone feels more productive and energized, but it’s hard to put a finger on the exact metric.

And if the dinner told us anything, it’s that we’re not the only ones thinking about that gap.

Which brings me to the real takeaway: we’re entering a new phase, where it’s important to make AI usage count. That means top-down initiatives that change how teams work, including bringing non-technical teams in more.

There might not be a “best” AI adoption strategy. But for those of us who’ve got adoption off the ground, the question is no longer quantity – it’s quality.