Two experiences from practice show why it is not enough to watch how quickly people and AI agents complete tasks. What matters more is which decisions they carry out, who is accountable for them and what they leave behind for the company's further development.
The more I work with AI in real software development, the less I care how much code it can write.
What I care about is whether what we build today will still help the company in six months. Or whether we are just preparing more work that we will have to pay for again.
AI can speed up implementation significantly. That is an advantage. But at the same speed we can also carry out decisions whose consequences we have not thought through.
For a company's leadership this changes one important thing: delivery speed on its own is not yet proof that an investment creates value.
On two projects I saw how differently this can turn out.
When cheap development starts to get expensive
On one project a new application was being built with AI agents using an approach now called vibe coding. The first weeks looked very good. Features were added quickly and the daily cost of AI was around CZK 500.
Gradually it rose to roughly CZK 1,000, then to CZK 1,500. After about six weeks it was CZK 8,000 to 10,000 a day.
With twenty-two working days, that pace would mean roughly CZK 176,000 to 220,000 a month for AI alone. That is an extrapolation of the daily rate, not a documented monthly invoice. It does not include people or infrastructure.
The growth in consumption on its own proves nothing, though. More agents can do more work. The scope of tasks and the price of the models used can change too.
So I wanted to know what the agents were spending their time on.
They increasingly had to go back to parts of the system that already existed. They untangled dependencies, fixed the impact of earlier changes and looked for a way to add the next feature. Sometimes their solution meant another coupling or layer that solved the task locally but made the whole more complicated.
From this I cannot calculate exactly how much of the rising cost the architecture caused. But I see a risk that I think matters more than token consumption itself: an agent can complete the task it was given and still make the conditions worse for every task that follows.
And it works the same way with people. When a developer does not know the wider goal, they can do good work in the wrong place.
What should a CEO deal with here? Not which prompt the agent received. Above all, whether the company knows if it is creating useful capabilities ever more cheaply, or just extending a system faster that will be ever more expensive to change.
When we do not know everything, we do not have to stop work
On a project for public administration we had a different problem. We needed to continue development even though the target infrastructure had not been finally decided.
We could have waited. That would have pushed delivery back. Or we could have bet on a specific technology and accepted the risk that we would later have to replace it at great cost.
We decided differently: we separated the system's capabilities from the technologies that provide them. We set the boundaries of components, interfaces and tests. Thanks to that we could keep working and make some decisions later, once we had more information.
For me this is the essence of decision-making under uncertainty. We do not need to know all the answers today. We need to know which decisions are irreversible, which can wait and what it costs us to keep our options open.
The concrete impact showed in integrating systems for passing messages.
The first implementation for Azure Service Bus, including generalising the shared component and testing, took about 24 hours. The next implementation for Apache Kafka took 6 to 8 hours. For RabbitMQ, where the AI agent could already use the shared foundation and the two previous implementations, we got down to 2 to 3 hours.
This is not a controlled experiment. The first piece of work included building the foundation, and the individual technologies are not equally demanding. I cannot honestly calculate the return on the architecture from these numbers.
But they show the principle: a first decision can create something that further decisions benefit from. Not just a finished piece of software, but the ability to change technologies without rewriting everything else.
For a CEO this is not a story about message brokers. It is a story about a project that did not have to stop because of an unresolved question, and about a later change that did not have to devalue the earlier investment.
Flexibility is not free. And it does not always pay off
I am not saying that every project needs an elaborate architecture. Sometimes the best decision is a simple solution that meets today's need.
Imagine a model example: a more general component costs 20 hours more than a one-off solution and needs another 5 hours of maintenance over the period in question. If it saves us 5 hours each time we use it again, the investment pays back after five further uses.
With two uses it does not pay off. With ten it probably does, if our assumptions hold.
This is not a calculation from the project above. It is a way of thinking I would like to see in decisions about technology investments: what the decision costs us today, which changes we expect and what it will cost us if our assumptions turn out to be wrong.
Deciding well does not always mean investing more. It means knowing what we are paying for and what option it gives us.
The quality of a decision can get lost on the way to delivery
There is one more thing that interests me in both stories. A decision on its own changes nothing. Someone has to understand it and turn it into work.
Leadership determines what the company wants to gain. Technical leadership chooses the approach. Teams or AI agents carry out the individual steps. And between any two steps, the reason why we originally decided this way can get lost.
When everyone optimises only their own task, every individual result can be right and the whole can still fail to work.
This is exactly where, for me, the importance of communication begins.
From the start I wanted to build IDEALINE as a non-directive company where nonviolent communication matters. That does not mean we avoid conflict or that nobody is accountable for anything. The point is that people can say what they do not understand, what they disagree with and what they need, without the conversation turning into a fight over who is right.
In my experience, this very way of working together has helped us get through even very demanding technical situations. Not because communication replaced expertise. But because it allowed that expertise to actually come together.
When someone points out a wrong assumption in time, we can change the decision while it is still cheap. If they are afraid to speak up, we can carry out the same decision for a long time and very efficiently in the wrong direction.
Good communication is therefore not just a way to hand over a finished decision. It is also a way to get the information needed to change it.
With AI agents a similar principle of working with context, boundaries and feedback applies. The difference is that an agent bears no human accountability for the consequences. That accountability must be clearly assigned to the person or team that entrusts it with the work.
Autonomy without a shared goal and rules is not the same as independence. Neither for people nor for agents.
Three questions I would want answered as a CEO
Before a larger investment I would not start with the question of which technology we choose. I would first want to know three things.
What exactly do we want to change, and how will we recognise the benefit? Finishing the project is not enough. We need to know what should improve for the customer or the company.
What do we not know today, and how much could a mistake cost us? Some decisions we have to make. Others we can postpone or first validate cheaply.
How do we make sure the original intent does not get lost in delivery? Who has the right to change a decision? Who can raise a problem? How do we get information from people and agents back to those who decide?
At project level I would then track not only AI costs or the number of completed tasks, but above all the cost of comparable completed functionality including people, testing, fixes and handover. And alongside that, the real business benefit, delivery time and the amount of work we have to redo.
When these indicators start moving in the wrong direction, it is not an automatic reason to change the technology or the team. It is a reason to find out which assumption stopped holding and whether we need to change the decision.
What will remain after today's decision?
AI makes some parts of delivery cheaper and faster for us. But it does not relieve leadership of responsibility for direction. If anything, it reveals how expensive it can be when we have no direction, cannot explain it or fail to notice in time that conditions have changed.
For me, strategy is therefore not a document we create once. It is a way of deciding under uncertainty, of communicating about decisions and of recognising when they need to be adjusted.
Whether we work with people or with AI agents, I am interested in the same question:
When we finish the next task today, what will remain after it? Only the result, or also the ability to do the next one better?