AI makes it possible to produce code faster than ever, but more code does not automatically mean more value. What AI really does is amplify the skill and judgement already present in the person or team using it. That makes the ability to understand the problem, spot risks and know what not to build more important than ever.
This is not an article whose point is "AI got it wrong once, so we might as well carry on as before, this is mostly hype anyway". Nor is the point that everyone should redraw their organisation tomorrow because everything is now completely different. The technology we have access to today will not disappear, and very likely it will only get better. But at what pace it will happen and what effects it will have, we can only speculate. When so much is happening, it is easy to be in too much of a hurry to change everything without thinking it through a little first. To feel stress because everyone else seems to have already started, so you want to start running before you can walk.
I think many underestimate what actually happens when developers start using AI to write code.
There is an idea that AI means you no longer need developers, or that a development team can suddenly produce ten times as much. In many moments AI can make people much faster, because code, tests, documentation, API clients and technical proposals can be generated at a speed that would have been hard to imagine just a few months ago.
But that does not automatically mean the value grows at the same pace. The idea that you no longer need people builds on a misunderstanding that writing was the hard part.
It rarely was. The hard part has always been to understand what should actually be built and why it should be built. Which problem it solves and what constraints exist. And not infrequently, understanding when nothing at all should be built.
AI code is not magic. It is a result of instructions, examples, assumptions and follow-up questions, and those things come from people.
If you are good at understanding the business problem, it will show in how you use AI. You will give better context, ask better follow-up questions, ask for the right trade-offs and review the answer in a more relevant way. If you have architectural thinking, you will see when AI proposes something that works in an isolated example but does not fit into the whole. If you are good at spotting risks, you will react when AI misses permissions, error handling, performance and so on.
But the opposite also applies.
If you tend to over-complicate solutions, AI will often help you over-complicate them faster. If you are unclear about what the problem actually is, AI will fill in the gaps itself, and sometimes it will turn out well and sometimes less well. The sharper models rarely generate bugs, but in cases where the gaps are filled with assumptions that do not match what you want, these are often hidden in seemingly elegant code.
AI does not remove your patterns, it scales them up. And that becomes a growing problem because AI will start from your existing code base and see it as something worth building further on. The existing code base sets the basic direction, and your prompt narrows in on that direction. So you get a fantastic tool for running incredibly fast in entirely the wrong direction if things go badly.
The same applies to teams. AI amplifies not just individuals' capability but also the team's way of working. Strong teams with clear direction and good communication can get enormous leverage from AI. Weak teams, on the other hand, will scale up their problems.
The bigger a team is, the more important communication becomes. If AI suddenly makes it possible for the team to create significantly more code and more changes but communication stays at the same level, a gap arises. That gap quickly becomes dangerous when more things are built but fewer things are grounded. More decisions are taken, but fewer are shared.
It is easy to think this will mostly be a technical impact, but it is the whole organisation that is affected. The organisation is used to it taking a certain time from A to Z, and that time means you have space to catch problems and iterate before something is done and released. With the pace you can now hold, a completely different pressure is put on getting things right straight away. Decisions must be thought through from the start, and now that you have the possibility to do even more things at the same time, you need to think another step ahead to foresee how these things interact.
We often talk about competence as if it were a single scale from junior to senior, from bad to good. But in reality competence is much more multi-dimensional. A developer can be very fast but weak on business understanding. Another can be technically skilled but build solutions a bit more complicated than actually needed. A third can be good at writing code that is easy to read and understand but have trouble seeing the whole.
When AI comes into the picture, these differences do not disappear, they rather become stronger. Because AI does not just produce code, it produces code in the direction you steer it. And the direction is decided by your judgement.
Yes, you can. You can ask AI to write a neutral solution, follow best practices, keep it simple and avoid unnecessary complexity. That is often a good start.
But then you also get a fairly neutral solution, which does not need to be a bad thing. Many systems would benefit from more neutral and slightly less creative code. And in many cases a neutral solution is more than enough for what you need. But if the goal is to create something really good, "meh" is rarely enough.
Good technical solutions do not arise just by avoiding mistakes. They arise through trade-offs and by predicting future requirements.
What should be flexible and what should be hard-coded?
What should be built now and what can wait?
Which system should own which data?
Where should the complexity sit, and what is unnecessary complexity, and what is the complexity that is the heart of the system?
Which future needs are reasonable to accommodate, and what is just fantasy?
These are not questions AI can solve in a vacuum. Not least because these are questions that require human creativity to solve. The LLM architecture we have with AI today looks backwards in the sense that it has collected the whole world's knowledge and distilled it down to you. But some of the problems you face are entirely new, or at least the composition of the problems is new. Which requires creative thinking that is hard to use AI alone for.
If everyone in a team starts using AI and becomes three times faster at producing code, it at first sounds like fantastic news.
But the question is: three times more of what? Three times more thought-through solutions? Three times more customer value? Three times better architecture?
Or just three times more code?
Because code is not free just because it is fast to write. Code has to be read, tested, troubleshot, developed further, documented and sometimes retired. It has to fit into the whole. And not least, it will form the context for the next AI agent that is to build on top of it. Good code breeds good code, bad code breeds bad code.
This is where the blast radius comes in. All developers have a blast radius, and all teams have a blast radius. All organisations have a blast radius. Every time something new is created, there is a blast radius just from things changing.
Some create small problems that are easy to fix. Others create big problems that affect several systems, several teams and several years ahead.
AI does not automatically shrink that blast radius. It can just as easily make it bigger, because the blast radius is proportional to how much is produced.
The value moves from writing every line of code yourself to formulating the right problem. Hammock Driven Development becomes more important than ever.
It also means specifications become more important. I know, it sounds boring. A specification in an AI-driven development process does not have to mean hundred-page documents that no one but AI reads. It can mean using AI to think better before you start coding, or for other tasks for that matter. Ask AI to find errors in your spec, or let AI interview you to help you produce it.
Every time I have used AI in different ways, the conclusion has always been that the more concrete my problem and my formulation is, the sharper AI is at solving it. AI is significantly better at fixing bugs or finding where there is inconsistency in a specification than it is at solving "build a good e-commerce system for me".
AI is already changing how development is done. It will make many things faster and it will make it possible for more people to build more. Which in itself is fantastic. Several of my colleagues who never wrote a line of code before have been able to contribute things in days or hours that previously took a developer days or weeks, so there is no doubt that the world looks different today than it did just a month ago.
But if we only measure AI by how much more code we can produce, we risk missing the point.
The important question is not: How much faster can we write code?
Think of it as AI being a way of tuning your car from being able to drive at 100 km/h to being able to drive at 10,000 km/h. Do you really want to get in that car without checking that there is not a big mountain in the direction you were planning to drive?
For you who buy systems or services, we are now entering a bit of a wild west period where you will get offers to buy systems and services from entirely new players using AI to solve your problems. It will be tempting to cut costs this way, and the challenge for you will be to know who is offering a car at the speed of light heading for the abyss, and who can understand what it is you need and then execute on it.
The important question becomes: How much better can we think before we write or order code?
AI does not automatically make your team wiser. It makes the team's judgement more scalable. And that is both the opportunity and the risk.
AI does not only increase productivity, it also increases the blast radius.
Related articles
AI does not only make development faster, it moves the capability out into the whole organisation. Suddenly anyone can build and change things in the systems. It is enormously powerful, but combined with old ways of working it leads to either chaos or no effect at all. Here is how you lead the shift from tree-tender to forest ranger before entropy runs away from you.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
For many years 'no code' and 'low code' have been pitched as the answer to the integration problem. The promise has been simple: no developers, no code, just draw a few arrows between systems and everything is solved. Read on to see why 'much code' is a better option.
