The conversation about AI in software engineering usually falls into two camps: panic or evangelism. At Ximedes, the approach is different. It’s quiet and pragmatic. The company has never shied away from new technology, but we do not adopt tools for the sake of novelty. We adopted Kotlin early because it solved a problem. We skipped Scala because it did not.
Now, the tool everyone is talking about is the AI assistant built by Anthropic, Claude.
AI usage in the market has exploded. In just a few months, tools like Claude that were once seen as experimental have become standard practice for Ximedes teams. But with speed comes a new, often overlooked danger. It is not that AI will replace the engineer. It is that AI might make the engineer’s job miserable.
We sat down with Ximedes CEO, Joris Portegies Zwart to discuss how Ximedes is navigating this shift and where the company sits, at the moment, in the big “AI debate”. We discussed the specific dangers of "firehose" coding, why AI lacks the ambition to build great products, and the existential threat these tools pose to the traditional time-and-materials business model.
Here is our conversation.
Joris Portegies Zwart: It exploded. That is the only way to describe it. Over the past few months, we went from tentative experiments to widespread adoption. Teams are now using Claude as a standard part of their daily workflow.
Our ethos has always been simple. We welcome new technology if it solves a problem. We do not block innovation, but we do not blindly follow trends. Right now, AI is solving problems and is removing friction. But we have to be honest about the limitations. It is not magic. It is a tool, and like any power tool, it can be dangerous if you do not respect it.
Joris: The risk is volume. AI knows a vast amount of information, and it types faster than any human. It can generate pages of code in seconds.
This creates a trap. If you are not careful, the role of the software engineer changes. You stop being a creator and you become a reviewer. You spend your day reading code generated by a machine to ensure it is fit for use, fit for purpose, and fit for change.
Reviewing code is not simple. It requires immense concentration and can often be boring. If we let AI handle all the writing while we handle all the reviewing, we risk turning a creative, exciting profession into a very boring administrative job. We have to guard against that.
Joris: You keep the changes small. You do not ask Claude to "build me a payment system." You ask it to write a specific function or refactor a specific module.
The engineer must remain the driver, own the design and the architecture. You define the solution, and then you use the AI to handle the implementation details within those bounds.
Tools like Claude lack memory. They lack long-term context. You have to provide that context explicitly. You cannot just tell it what you want, you have to explain how and why you want it. This forces you to clarify your own thinking. If you treat it like a junior developer who needs explicit instruction, you get good results. If you treat it like a magic wand, you get a mess.
Joris: Because AI has no ambition. It has no desire. It does not care if the product succeeds. It does not care if the user is happy.
A human engineer brings intent, they bring purpose. AI is a tool for people who already know how to write code. It cannot replace the strategic thinking or the drive to solve a client's problem. It can only execute the syntax.
The misconception is that AI replaces the engineer. At this point, it does not. It replaces the keyboard. It replaces the syntax lookup, but it most definitely can’t replace the "why" behind the code.
Joris: This is the strategic challenge. Our industry is built on selling the time of engineers. If AI allows us to finish a task in four hours instead of eight, we have a problem. We are effectively halving our revenue while delivering the same value.
We cannot ignore this, and adapting is an inevitability. This might mean we need to sell twice as much functionality in the same timeframe. It might mean shifting toward value-based pricing. It might even mean transitioning into a product company.
The model will change. We cannot pretend that selling hours is sustainable when the value of an hour is changing so drastically. We have to be ready for that shift.