“AI makes teams move faster” - we’ve all heard this sentence. We usually think of startups producing entire products in just a few days.
But we forget that we can also move faster in the wrong direction. And that is exactly where the danger of AI in software development lies.
In this article, we look at what the new limiting factor in software development is, what problems it creates, and how we can come to terms with it.
The Bottleneck Has Shifted
It Used to Be Time
Time used to be the limiting factor in software development. Today it no longer is, at least not to the same extent.
And because time was the bottleneck, software teams thought carefully about which tasks they wanted to work on and when. It was about using the time as well as possible.
The rise of AI agents has shifted this bottleneck.
It still takes time to develop software, but not as much anymore - and that’s exactly the point. Things like “That would take me two weeks. Let’s postpone it for now.” are rarely heard anymore. More often it’s “I’ll take a quick look and get back to you tomorrow.”.
The problem is:
Just because something can be built quickly doesn’t mean it is quickly understood or correctly decided.
4 Things That Are Now Becoming Bottlenecks
Unfortunately, the consequence of the last section is not that there are no more bottlenecks and we can create endless amounts of software in no time.
Instead, 4 other topics are now becoming bottlenecks.
Focus
Just because everything can be built faster now doesn’t mean everything should be built.
We all know those products that seemed almost perfect at the beginning because they solved exactly one problem very well. But over time, more and more features get added until the product eventually becomes barely usable and you have to look for an alternative..
Exactly the same thing is happening now through AI, only much faster and also in smaller teams.
New features just keep getting added instead of questioning what is best for the product.
Coordination
The effort of a feature used to be a natural filter for decisions. This relationship no longer exists today, and big changes are suddenly cheap.
Furthermore, large features can be implemented in a short time:
The custom “Text 2 SQL” implementation doesn’t deliver the desired reliability? No problem, quickly replace it with a third-party API. An hour later you realize that the other developers have to adapt all their modules because the data structure of the new API is slightly different. And you also forgot to check what rate limits the provider has, and now you have to pay a lot of money to get around them. But the whole thing is already deployed.
In the past, the decision would have been discussed in the team. Today it just gets implemented.
Understanding
In the past, you had to understand the code to be able to write it. That took longer in the short term. But in the long term, it had the positive effect that developers understood the system, could debug faster, and could give project managers better answers (“How does our system actually decide XYZ?”).
Nowadays, however, less and less attention is paid to this understanding.
Instead of understanding the code and architecture that the AI implements, people often say “it works, that’s the most important thing”. AI decouples writing code from understanding code.
In the short term, this allows more code to be produced.
In the long term, developers lose control over the code and put themselves in situations where they no longer know what their system does.
And not infrequently, they develop code (or have it developed) that is hard to debug, even for an AI agent. And that is exactly what makes this development so dangerous.
Ownership
Another problem that is amplified by AI: responsibility.
In many teams, you now see the following situation: you find a bug and the associated code is hard to understand. So you ask the developer who pushed this code for an explanation. But the developer’s answer is: “Honestly, I did that with an AI agent. I don’t know why it was implemented exactly that way”.
Just a few years ago, every developer would have been ashamed to admit not knowing what they had done.
Today it’s different.
And that’s because developers no longer feel responsible for the code that the AI implements. They no longer see themselves as the author.
4 Rules to the Solution
These problems don’t arise from AI, but from how we deal with it. And that is exactly why we need to adapt our way of working. The following rules should help with that.
You Are in Control
Many developers hand over control to the AI. They let the agent decide what the architecture should look like and which implementation strategy to pursue.
With this approach, chaos is inevitable.
The agent will make bad architecture decisions, introduce unwanted patterns, fail to properly integrate existing services, and so on. And faster than you think, this will lead to a codebase that is maintainable neither for you nor for the agent.
The solution is to do your own research and make your own decisions before you involve the AI agent.
Then you can prompt like this: “I want to implement feature XYZ. Create a new model with these fields: […]. Then create a controller named XYZ and a new service ABC”.
You leave the AI no room for decisions at all, which also makes the later code review easier for you.
Your Code, Your Responsibility
If you push the code, you are responsible for the code. You will have to answer for it if something goes wrong with it, and you will have to fix bugs in the code. And when questions about the code come up, you must have an answer.
Understand Every Line
You should understand everything the AI agent produces. Read every line, understand the flow, question everything.
Only this way can you make sure that you understand it and that you can take responsibility for the code.
This becomes more difficult the larger the AI agent’s changes are. If only one new method with 5 lines is added, it’s fairly easy to understand it. But if 1,000 lines and 15 files are touched, it gets difficult.
The easiest way to avoid this is by following rule 1: you make the architecture decisions yourself and then let the AI carry out the changes in small steps that you can review bit by bit.
Don’t Make Big Decisions Alone
Even if it’s tempting to quickly implement larger changes and features yourself - better not.
Bring it up with the team and get their opinion. Almost always you will gain insights that influence your plan. And your colleagues will thank you for not bypassing them.
Conclusion
Software development has changed a lot in recent years. While the time investment used to play a big role, it is less relevant today.
However, this has created a whole new category of bottlenecks that must be met with a lot of discipline and strict rules.