Our AI Journey: an unromantic truth

One of our product owners wrote a user story with AI support. Comprehensive, well structured, with flawless language. He skimmed through. Looked fine. The story landed with the developer, who had been experimenting eagerly with Claude Code for a while. He started reading. For a long time. Too long. At some point he asked in the daily: can AI please summarise our stories?

Nobody had really decided. Everyone had somehow agreed.

More than a year ago we started at UFirst with AI product development. Very classic: a few developers got Claude Code in their hands. It would run by itself, we thought. Who wouldn't be fascinated by the technology?

It turned out differently. The developers were surprisingly reserved and largely stayed in their usual tracks. AI ran alongside the daily business. Nobody was exclusively on it. Everyone interpreted the brief "use AI" slightly differently. Some worked in their own style. Others defined their own rules.

Clear processes or governance did not emerge that way. On top of that: no overall architecture, no shared component library. Nobody really took ownership of decisions. Every story turned into its own mini project, and they grew longer and longer, because AI tends to write long.

The realisation came late, but clearly: AI in software development is not a tool you simply hand to developers and then watch what happens. It is a new way of working. Without focus, without structure, without clear ownership, it goes wrong.

A few months ago we restarted the initiative from scratch. A dedicated crew of seven people has been working on and with what we call the Factory ever since, daily. For a few weeks now, our business colleagues have been testing it too. The most important technical insight was that AI needs structured transitions. Exactly where business value is created, a human must decide, not an algorithm.

The bottleneck shifts

Upfront: the way software is developed does not fundamentally change. What changes is the volume, and that makes thinking the bottleneck, not typing. The code itself loses value. What counts is know how and context of the business and market environment.

Jordan Jarolim is a Partner at UFirst and built the pipeline on the technical side. He puts the principle this way: the Factory proposes, the human decides. In concrete terms: we have a clearly defined flow from idea to finished code. A so-called pipeline. Each phase has a clear owner. Each phase has a checkpoint where a human must say yes before things move on. From the business case through the user story, the UX and the architecture to the code, the review and the E2E test.
AI takes over what is repetition and speed. Humans keep their hand on the steering wheel wherever judgement and business understanding matter.

What really matters

The same applies to components. At first AI built its own pieces for every page. No reuse. No respect for the design system. By now the Factory forces us to look for existing components. New ones are only built when nothing really fits.

But it is not only about components. On top of that, we have put further guardrails on the process: standards for documentation, a strict glossary, clear specifications for security. A lot of this sounds trivial. But exactly these trivialities make the difference. They decide whether a system scales or falls apart after three features.

Today we see efficiency gains of 20 to 40 percent, depending on the initiative. Some topics benefit strongly, others less. It depends on how complex the code is, how mature the requirements are and how disciplined the team works. We don't want to romanticise this: AI is not a multiplier across everything.

Still, we see four effects in our own work and in the first tests with clients.

Business can query the codebase directly.

Complex logic used to be really understood by only one developer on the team. Today it is accessible to anyone with the right questions. It does not replace the developer. But it makes the business faster and more independent. Especially with complex topics like permission systems, pricing logic or workflows, where many iterations were needed before clarity emerged.

Cost and lead times become visible and predictable early.

In fifteen years we have seen again and again how projects get out of hand. Risk analyses and breakdowns are anchored early in the Factory, before money flows into the build. It is the biggest lever we have for planning certainty.

Quality emerges from structure, not from the genius of a single person.

The Factory forces us into the same approach on every project. In concrete terms: clear ownership, defined handovers, unified standards. This is the basis for scaling and governance, from the single project up to the entire organisation.

No vendor lock in.

The Factory does not only work with Claude Code, other AI models can be used just as well. Things are moving in the market and European alternatives like Mistral are becoming more important for many clients. The same goes for ticket systems: Azure DevOps, Jira or others, we dock on where our clients are.

The Factory project is not finished. We develop it further every day and keep learning. But what we know for sure: AI in product development only works with clear structures, dedicated teams and people who carry the responsibility.

• Three questions that continue to occupy us, and perhaps you too:
• What does your AI landscape look like today, and where do you want to go?
• Where should humans keep control, where can AI lead the way?
• Which initiative would you bring forward if the way to get there was clear?

If one of these makes you think, let's talk. 30 minutes is enough for a first exchange.