How Tech Lead Mick helped drive AI Adoption at Cube.

A move that was about more than just commute time.

When I asked Mick why he chose Cube, he started by laughing and mentioning the shorter commute. Of course, the fact that Oldenzaal is closer to home than his previous employer played a role, but that was mainly just the reason to start a conversation. The real reason lay elsewhere. At his previous employer, he was already working with AI agents on a daily basis, and he continued to experiment even outside of work hours, comparing different models, figuring out which one best suited a particular type of problem, and discovering where the limits lay. Not as a hobby project, but because he was convinced that AI would fundamentally change software development. He was eager to share that knowledge: “I think the knowledge I have can be put to good use by other teams and other people.”

During his interviews, he learned that Cube was heading in the same direction. Not isolated AI experiments, but organization-wide change. Moreover, he saw a culture where colleagues easily reach out to one another and knowledge doesn’t get stuck within a single team. “Great culture, great colleagues, enthusiastic team,” he sums it up matter-of-factly. It was precisely that combination that sealed the deal for him. Not just working with AI, but also helping an entire organization learn how to work with it.

Joined at just the right time.

The timing could hardly have been better. In 2024, Cube took its first steps with AI in software development. Early this year, there was a concrete plan to make AI a structural part of the development process. That plan was already underway when Mick walked in on his first day of work. That made his experience immediately valuable. After all, the question was no longer whether coding agents would find a place within development. That decision had already been made. The challenge lay elsewhere: how do you ensure that four development teams can work with them on a daily basis without everyone developing their own way of working? Mick had already gone through that process before.

He knew which models excel at different types of work, when an agent isn’t the best choice, and how to prevent different tools from working at cross-purposes. For colleagues who were curious but had little experience, hands-on experience proved more convincing than any presentation. There was someone right there with them who was simply already doing it. Yet, according to Mick, the greatest benefit doesn’t lie in the tools themselves. “An AI model does exactly what you ask it to do. So you need to know how to get it to do things and how to give it more knowledge and context.” In practice, that’s exactly what makes the difference. It’s not the model that determines the quality of the result, but the way you work with it.

A flying start.

His first day on the job didn’t really feel like a first day. Even before he officially started, Mick joined a team get-together. Pizza on the table, getting to know colleagues, and the first conversations about projects and AI. “The ice had already been broken. So on your first day, you don’t walk in as a complete stranger.”

For the first few months, he worked as a developer. After that, he moved into the role of tech lead. How he experiences the team is perhaps best illustrated by something that has absolutely nothing to do with software. When Mick got married, he invited his coworkers to the wedding. “And what a party it was,” I say with a laugh. That’s exactly what characterizes the atmosphere at Cube. Collaboration doesn’t stop at the boundaries of a project or team. People know each other, help each other, and support one another. That open culture later proved to be perhaps the most important factor in making AI an integral part of daily work so quickly.

That’s how AI became part of our daily work.

It started with a small group of tech leads. They were the first to start working with coding agents, not to immediately overhaul the entire organization, but to discover how AI truly adds value to the development process. It didn’t take long. Within a few weeks, virtually all developers were working with an AI agent on a daily basis. Interestingly, this acceleration didn’t stem from a single, rigid plan. All across the organization, colleagues were figuring out what worked in their own ways. One tested different models at home; another built a smart tool for an ongoing project. Everyone discovered something slightly different. The real breakthrough came when those individual insights began to reinforce one another.

This is how the first “skills” emerged: set instructions that define how an agent behaves within Cube, which standards apply, and which tasks it is allowed to perform independently. What began as a handy solution for a single developer grew into a shared approach that everyone could build upon. The same thing happened with the first MCP servers. These give an AI model access to the systems, documentation, and data sources associated with a project. No longer a standalone chatbot that has to guess, but an agent that understands the context of a project and acts accordingly.

Making choices that will stand the test of time. Not just today, but a year from now as well.

For Mick, this development felt familiar. He’d seen before how quickly something like this can grow, provided people continue to share their knowledge. His experience helped bring ideas together more quickly and make decisions that not only work today but will still hold up a year from now. Still, he believes the greatest strength lies not in the technology. “Someone from one team comes up with something, and someone from another team had the same idea. Then those two sit down together and see if they can turn their two ideas into one good idea.” That characterizes the way people collaborate at Cube. New ideas don’t disappear onto someone’s personal laptop; instead, they’re discussed during knowledge-sharing sessions, further developed during hackathons, and continually improved as colleagues build upon them.

“Everyone here has that mindset of helping one another.” You notice it especially in the small moments. Two colleagues spontaneously huddling around the same screen. A message on Friday afternoon where someone shows what they just got working. Or a solution that’s already part of another team’s workflow by Monday. What started with a few tech leads has now simply become the way software is developed.

From programming to providing direction.

If you ask Mick what AI has done for his workday, he doesn’t start talking about programming faster. According to him, the biggest change lies in everything that comes before it. “Back then, you spent a lot of time thinking about how to build something, and then you still had to build it yourself and test it yourself.” That thinking hasn’t gone away. It’s just shifted to a different stage. Whereas developers used to focus primarily on implementation, the emphasis now lies much earlier in the process. What exactly needs to be built? How does a solution fit within the existing architecture? And what context does an agent need to be able to work independently? Only once that foundation is in place does an AI agent take over a large part of the execution work. “You work out an issue so thoroughly that you can hand it right over to the agent and say, ‘Go ahead and build it.’”

That doesn’t mean the developer can sit back and relax.

On the contrary. Mick deliberately works according to the “human-in-the-loop” principle. The agent performs tasks, but every important step is reviewed before the process continues. Responsibility thus remains where it belongs: with the developer.  The initial investigation at the start of an issue also looks different these days. Whereas he used to search through an unfamiliar codebase himself to figure out where a problem lay, he now has an agent first analyze how components are interconnected, where dependencies exist, and where the cause is likely to be found. That saves time, but more importantly, it frees up time for the work where human experience makes the difference: architecture, edge cases, maintainability, precisely the choices that determine whether software will still be easy to maintain a year from now.

Why quality actually improves.

This was the question I was most looking forward to. Everyone understands working faster, but why does quality improve rather than decline? If software is built faster, doesn’t that come at the expense of quality? According to him, the exact opposite is true. Not because AI makes fewer mistakes than humans, but because the development process is checked at many more stages. “You get a lot more merge requests and a lot more review work. That became the bottleneck.”

That’s why every merge request is first assessed automatically, not just for style or syntax, but specifically for connections that developers easily overlook. “It simply says: you’ve modified this code here, but the same construct appears in that other file. Check there too to make sure it’s still correct.” That first round doesn’t replace the review, but it makes it more targeted. A developer still decides whether something gets merged.

Furthermore, even before code is committed, a security scan based on the OWASP guidelines runs. Vulnerabilities are flagged immediately and often accompanied by a suggested fix right away. A developer then assesses whether that solution is actually correct. Checks that used to take place later in the process are now part of every change.

Don’t just test the happy path.

Still, Mick sees the greatest improvement in quality elsewhere. Virtually every developer unconsciously writes test scenarios based on the situation where everything goes right until AI comes up with scenarios you hadn’t thought of yourself. “When you write a test plan, you unconsciously focus only on the happy path.”  An agent, on the other hand, also looks at situations where something goes wrong. What happens if a user doesn’t have the right permissions? If required input is missing? Or when a process is unexpectedly interrupted? His conclusion is therefore strikingly simple. “I actually think your code becomes more secure when you use AI properly. More tests, more edge cases, a security scan before you commit.”

The developer remains in control.

Despite all the possibilities of AI, Mick is very clear about one thing: using it properly still requires expertise. An agent can take a lot of work off your hands, but only if you tell it exactly what you want it to do. “If you just say, ‘Turn this design into issues,’ things will go wrong. You really have to specify exactly what it should do, how, and when.” 

According to him, that’s precisely where a large part of development work lies these days, not in writing code, but in clearly defining a task, providing the right context, and evaluating the outcome. Once an issue has been worked out, for example, the agent generates a test plan. Mick then goes through it himself to verify its functionality. Only when everything checks out does it go live. The decisions “under the hood” also remain a human task. Which model do you use? What skills do you equip it with? Which systems and data sources is an agent allowed to access? These aren’t technical details, but deliberate trade-offs that determine how reliable the outcome is. So AI does change the developer’s role, but it doesn’t take it over.

Four lessons for developers who want to get started with AI agents.

What advice would Mick give to developers who are curious about AI but haven’t gotten beyond asking a chatbot a question every now and then? His answer doesn’t start with tools, but with the goal. “First and foremost, consider how you want to apply it. If you want to use it for development, first figure out which model you want to use. Then make sure that model has the right context for your project.”

This actually leads to four practical lessons.

1. Choose a model carefully. The large language models are very similar, but each has its own strengths. Which one works best depends on the type of work you want to automate.

2. Define conventions in skills. That way, an agent knows how your team works, and you prevent every developer from reinventing the wheel.

3. Provide context through MCP servers and integrations with a project’s systems and documentation. Without context, an agent is left guessing.

4. Stay in control. Monitor the process, check the results, and learn to understand why an agent makes certain choices.

He often sees the latter go wrong in particular. “You shouldn’t view it as a replacement, but as a tool. You remain in control. You determine what it does.”

It’s not limited to development.

At the end of our conversation, Mick makes one more comment that gets me thinking. According to him, AI isn’t just changing the way developers work. “Project managers who spend their time retyping user stories and tickets, you can automate that. And if you look at the business side: you record a meeting, convert it into action items, turn it into a presentation, and the emails are ready to go. It’s being used in every branch of the organization.”

I can really relate to that. Even in marketing, I’ve noticed how much specialized knowledge is suddenly within reach. Thanks to agents and well-configured skills, I can tackle tasks that I used to have to rely on colleagues for. And if I get stuck on something, there’s always someone willing to help me figure it out. Maybe that’s the biggest difference I’ve seen over the past few months, not the technology itself, but the way people interact with it. Developers, project managers, designers, and marketers are constantly sharing what they discover. Asking questions is normal. So is not knowing everything. New insights don’t stay confined to a single desk: they become part of how everyone works. That’s precisely why development keeps moving forward.

More than just a new tool.

When Mick joined Cube, he stepped into an organization that was just entering a new phase. The first steps with AI had been taken, the ambition was there, and the question was no longer whether coding agents would become part of software development, but how to deploy them in a way that truly helps teams move forward. His experience came at exactly the right time, not to set the direction, but to accelerate a change that was already underway.

What really sticks with me after this conversation is that this change isn’t about any one person or any one smart tool. You see tech leads exchanging ideas. Colleagues who look into something in the evening and share it with the rest of the team the next morning. Teams that improve each other’s solutions instead of starting from scratch. That curiosity is contagious. As soon as someone shows what’s possible, the next person wants to know how to apply it in their own field. Perhaps that’s ultimately the most important lesson from this story: the difference isn’t in the use of AI, but in an organization where people are constantly learning from one another.