I have spent much of the last 3 decades building software in very different environments, from early web and mobile through to large scale production platforms at startups, investments banks and mobile operators. At SmartAsset, my fintech startup, we grew from zero to more than 100 million users/month.
More recently, however, I spent a year rebuilding internal systems at a Venture Capital firm, using AI coding tools end to end. Not as a side experiment, or a novelty. As the actual way the work got done.
That experience entirely changed my view of what these tools are, and what they are not.
There is a lot of noise around AI coding right now. Some people talk about it as if software engineering is basically over. Others dismiss it as glorified autocomplete. Honestly, neither view matches what I have seen in practice.
Used badly, these tools can absolutely create mess. Used properly, however, they can change the speed and shape of software development in a radical way. They do not remove the need for judgment, experience, engineering discipline, or technical depth. But they do change what a strong engineer can get done in a day, a week, or a month.
That was the backdrop to Codistry.
The obvious question was whether this would translate beyond my own work. It is one thing to use these tools deeply yourself. It is another thing entirely to help a room full of experienced engineers change how they work.
That is why our first pilot mattered so much.
We were introduced to a senior engineering lead at a company in Stockholm in late December. The timing was perfect. Their team was already thinking about how to adopt new AI coding tools, but like most companies, they were still trying to work out what that should actually look like in practice. They moved quickly and agreed to a pilot.
In February, we ran a two day session with one team of senior developers.
The group was skeptical. These were not people looking to be dazzled by demos. They were experienced engineers with decades of experience. However, they were open minded enough to listen, try things, and discuss options, but they were not going to pretend to believe in something just because it was fashionable.
We kept the training practical, not vague talk about productivity but rather how to actually build things. We focused on how these tools behave when you are trying to build, modify, refactor, debug, and reason about software in an actual engineering environment.
And if I am honest, when the two days ended, I felt pretty dejected.
My immediate reaction was that it had not landed. I walked away thinking maybe this kind of training simply does not work with experienced engineers. Maybe the gap between seeing the tools used and actually changing behavior was bigger than I had assumed.
Two days later, the team lead sent me a message saying the team had gone from "0 to 100 overnight."
That message changed everything.
What I had missed was that the shift was not happening during the session. It was happening afterwards. Engineers needed a bit of time to process what they had seen, try things themselves, test the tools in their own environment, and connect it to their own work. Once that happened, the change was fast.
A few days later, the company signed up another 18 developers for training, including all of their senior staff engineers.
That first pilot taught me something important.
Skepticism is not the obstacle. In many cases, it is the starting point. Good engineers are supposed to be skeptical. They have seen hype before. They have seen tools overpromise. They have spent years cleaning up after shortcuts dressed up as innovation. You do not get through to people like that with slogans. You get through by showing them something real enough that they go back to their desk and try it properly.
It also taught me that this space is far less uniform than people like to pretend.
There is no single "AI coding rollout." Different teams come to this from completely different places.
Some are buried in legacy code and want to move faster without destabilizing critical systems. Some are working on greenfield projects and want to accelerate delivery from day one.
Some have endless backlogs of useful internal tools and product improvements that never make it onto the roadmap.
Some have a heavy mix of junior engineers and are trying to work out what good supervision and learning now look like.
Some are deeply specialized across frontend, backend, infrastructure, or data.
The training has to reflect that reality. It cannot be generic. It has to meet the team where they are.
We also learned very quickly that the tool choice matters more than I first expected. A lot of companies are centering their workflows around Claude Code. Others are investing around OpenAI Codex or Google Gemini, or in some cases, AWS Kiro Code too.
Part of the job became helping companies think clearly not just about adoption, but about fit. More importantly, it is about how teams adopt these tools consistently. You cannot have one developer shooting from the hip, while others are trying to review and verify that code.
The other surprise was how quickly interest spread beyond engineering.
Very early on, we started seeing strong demand from non engineers too. Product managers, Business analysts, marketing teams, data and finance teams. That makes sense: the ability to build useful internal tools and automate meaningful work is no longer confined to people who can write software from scratch in the traditional way.
But that does not mean everybody should just start throwing prompts at a model and hope for the best.
The same principles still matter. Structure, reliability, security all matter. The opportunity is real, but so is the risk of building fragile nonsense if people are not given the right foundation.
That is one of the clearest things I have taken from these early pilots. This is not just a new set of developer tools. It is a broader shift in how software gets built inside companies. Engineering sits at the center of it, but it will not stay there.
We are still very early. So far, we have trained around 50 engineers across a few European and USA companies. That is not a huge number, and I do not want to pretend otherwise. But it is enough to see patterns. Enough to know the demand is real. Enough to know that teams are actively trying to work this out right now.
These tools change constantly. New capabilities appear, old assumptions break, and best practices do not sit still for long. The companies getting the most value are not the ones looking for a one off demo or a quick burst of excitement. They are the ones willing to think seriously about how this changes engineering work, team design, and who gets to build what.
That first Stockholm pilot was a useful reminder that change does not always look dramatic in the room. Sometimes it is quiet. Sometimes it looks like doubt. Sometimes it looks like a room full of smart engineers withholding judgment.
And then two days later, the message arrives, and you realise something has shifted.
This was the point where Codistry stopped being just a conviction and started being tested in real teams, with real engineers, under real conditions.
If this sounds familiar, or your team is trying to work out how to approach AI coding in a practical way, feel free to reach out at hello@codistry.com.
Comments