Start with Why, Even with AI
TL;DR: First know what you want to solve. Then build. Not the other way around.
I see it in almost every technical discussion now. AI here, AI there. And in almost every client conversation, someone eventually says: “We need AI.”
What is asked far less often: what for, exactly?
That is what occupies my mind. In many places, AI has become a premise rather than the result of deliberation.
There used to be a problem on the table. You looked at different options and chose the right tool. Today, the decision to use AI often comes first, and then a place is found where it somehow fits.
To be clear: I use agentic coding tools every day. I build agentic systems myself. That is exactly why I sometimes say in discussions: “You do not need AI for that.”
Not because I have anything against it. But because I believe you should first understand which problem you want to solve and only then decide which tool makes sense.
Vibe coding is great, until it is not
The current hype is called “vibe coding”. Do not plan for long, just get started. Enter a prompt, look at the result, keep going.
For prototypes, this is fantastic. You can test ideas in hours instead of weeks. You learn faster. You get early feedback. For experiments or throwaway prototypes, this is an enormous step forward.
It gets difficult when that speed becomes a habit.
Code can be produced in minutes today. But the questions that follow remain the same as before: Is the solution secure? Is it maintainable? Does it fit into the existing landscape? Who takes responsibility when it becomes a production system?
These questions do not disappear just because the first prototype was built quickly.
Some time ago, I experienced exactly that. A business unit wanted to “quickly” build an order management system. Technically, that was no big deal today: some frontend, a cloud backend, Supabase for authentication and data storage. Within a short time, a working prototype was running.
Then something happened that happens frequently.
People started working with it. Data was entered. Processes formed around the system. The prototype gradually became a production tool.
At some point, IT was supposed to take over.
Then came the usual questions: code review. Security checks. Integration into existing identity management and authorisation concepts. Operations. Monitoring.
And suddenly it became clear that the original decisions had been made for exactly what they had wanted to build at the time: a quick prototype. Not a system that was supposed to be a long-term part of the enterprise landscape.
The prototype was not the problem.
The problem was that nobody had defined at which point it stopped being one.
When building gets cheaper
It gets even more interesting at the organisational level.
For a long time, software development was expensive enough to enforce a certain discipline. Before a team built something new, they checked whether a solution already existed. Not necessarily out of architectural conviction, but because building from scratch cost time, money, and resources.
Today, that barrier has become significantly lower.
With modern frameworks, cloud platforms, and AI-assisted development, working solutions can be created in remarkably short time. That is fundamentally a positive thing.
The flip side, however, is that the natural brake falls away.
When building becomes very cheap, the temptation arises to solve problems locally. Each team optimises for its own situation. Each department builds the solution that fits best at that moment.
The result often looks like this:
Five teams build five variants of the same application. All of them work. All of them serve their purpose. All of them were developed with good intentions.
And yet a problem emerges.
Because the costs have not disappeared. They have merely changed location.
Instead of developing once, you suddenly operate five solutions. Five deployments. Five security concepts. Five integrations. Five systems that need to be maintained, updated, and documented.
The real fallacy lies in equating “easy to build” with “cheap”.
The first build has become cheap.
Operations, maintenance, governance, and standardisation have not.
Agentic AI amplifies this effect
Agentic systems will accelerate this development rather than slow it down.
When multiple teams use their own AI assistants to create data pipelines, APIs, or internal applications, working solutions emerge very quickly. Each one can be perfectly sensible for its respective use case.
From the perspective of central IT, however, a different picture emerges.
Suddenly, three different architectures exist for the same problem. Three different ways to process data. Three different integration approaches. Three different operating models.
Nobody necessarily did anything wrong.
The teams simply used the possibilities available to them.
That is exactly why I believe the answer does not lie in slowing down or curbing innovation.
The answer lies in a stronger platform orientation.
The easier building becomes, the more important shared standards, golden paths, templates, and reusable building blocks become. The easiest path should simultaneously be the path that fits well into the overall landscape.
When development costs decrease, the value of good architecture increases.
Not every AI is a win
Another point often gets lost in the current enthusiasm.
Every additional AI system brings responsibility with it.
It needs to be operated. It needs to be secured. It needs to be monitored. It needs to be explainable. In many industries, it will eventually need to be assessed and documented from a regulatory perspective as well.
When an AI system delivers clear value, that effort is often justified.
When it was merely added because AI was supposed to be on the roadmap, the calculation looks different.
Then you create additional complexity without solving a corresponding problem.
And complexity has the unpleasant property of rarely being visible immediately. The bill usually comes later.
The questions I would like to hear more often
Before anything is built, a few surprisingly simple questions help, in my view:
Sometimes the answer is yes.
Sometimes a script is enough.
Sometimes a rule.
Sometimes a better-defined process.
And sometimes it turns out that the real problem lies somewhere else entirely.
That is not a step backwards. That is solid engineering.
Where AI actually makes a difference for me
Despite all the critique, I use AI every day.
For quick HTML dashboards and reports where function matters more than perfection.
For research and formatting tasks that cost time but generate little creative value.
Above all, though, as a learning tool.
When I need to get into a new framework, a library, or a technical concept, AI is often an excellent sparring partner. It does not replace documentation or independent thinking. But it significantly shortens the path to a usable understanding.
That is exactly where it plays to its strengths: it accelerates work that needs to be done anyway.
In the end, the question is surprisingly simple
For me, it is not about whether AI is used or not.
The real question is:
Are we solving a problem and then choosing the right tool? Or have we already committed to the tool and are now looking for a problem to go with it?
This is not a case against AI.
It is a case for thinking before building.
First understand.
Then decide.
Then build.
Transparency: This post was created with AI assistance. I reviewed it and take responsibility for the content. More under AI Transparency.