We can have faster and faster tools, and a slower and slower delivery system. And for quite a while, we may not even notice.
Unless we use data that helps us understand how our delivery system really works. But let’s start from the beginning.
To simplify: what would delivery look like if it were a snake?
Different parts of the snake are the stages through which a lot of thinking, work and collaboration need to flow before the user feels a change, and teams know what to do next. So we are talking about the whole process here: from understanding the business goal and the user problem, through product and technical decisions, implementation, review, testing and production, all the way to insights from data, feedback and setting the next priorities.
You might expect a pretty fit-looking snake. One with a slightly bigger head – not to hold an infinite number of ideas, but to better understand options, hypotheses and trade-offs – and with a narrow, efficient body and tail, meaning a fast flow from decision to solution delivery, validation and feedback.
The drawing below is not meant to be a maturity model or a universal map. It is a simple way to show a few possible shapes of the delivery flow when different parts of the system become heavier, faster or more constrained.
These shapes are, of course, simplified. But they help us see something important: when one part of the flow accelerates, the whole system does not automatically become faster.
And this is exactly what we see in DevEx survey results, conversations with technology leaders and DORA data: a few patterns that are not quite that fit.
In the pre-AI stage, we often saw the bottleneck – the narrow part of our snake – in coding. You know the story: never enough developers… ;)
In theory, that bottleneck should have pushed us to make much smarter decisions about where we invest our teams’ time. But let’s be honest: even before AI, we were perfectly capable of producing things without much coherence. Building features that did not come from a real user problem. Delivering projects that nobody wanted to maintain later. Optimizing velocity while decisions were still circulating between teams. Celebrating that something was “delivered”, even though the business impact was weak.
We wanted a lot of everything. And the question “why?” kept getting lost somewhere in the background.
In a simplified version, the flow looked like this:
Understand → Decide → Build manually → Review → Test → Ship → Learn ↺
Companies that did their homework before AI and built a delivery system grounded in the answer to “WHY” – a system that helped them learn faster, shorten time to insight, understand friction and see the flow of value – entered the next stage with a very different advantage.
Then we entered AI turbo-charged mode.
Understand → Decide → Build with AI → Review → Test → Ship → Learn ↺
And this is where things got interesting. Some companies fell in love with the productivity vibe. And honestly, it is easy to understand why, because locally the effect can look impressive.
But the more important, system-level question is: does value flow to the user faster?
And this is where a few traps are waiting for us. For example:
Classic copy-paste: we choose “proven” tools that everyone in the market is talking about, because if they worked for others, they should work for us too. Usually, these are tools that are easy to implement. But the place where it is easy to implement something is not necessarily the place that will make a real difference in the flow of our snake.
Introducing AI where it is easiest to show something: fast generation of prototypes or code. In this scenario, a now-classic pain point is large PRs and the bottleneck moving further down the snake, to the point where work gets stuck in code review or later – in testing.
Confusing movement with value. Faster coding puts more pressure on the decision stage: what is actually worth coding? If we hadn't done our homework earlier, this is where we get into real trouble. The team may deliver faster, but the question is: what should it deliver? AI will not automatically create more value.
AI does not magically fix delivery. If we do not look at our system as a whole, and if we do not treat decisions about AI tools as system design decisions, AI will speed up selected parts of work, but not necessarily the flow of value. We may end up with more output, more work in progress and more decisions to make – instead of a faster effect for the user.
That is why the question about AI in delivery is not: “what can we easily speed up?”, but: “what is limiting the flow of value today?”
This is classic Theory of Constraints thinking: if we speed up a stage that is not the system constraint, we do not increase the throughput of the whole system. We only increase the amount of work that reaches the queue in front of the real bottleneck.
So yes, AI can shorten the time it takes to write code, and at the same time not shorten the time it takes to reach a meaningful outcome. If the system cannot make decisions faster, validate faster, integrate faster and learn from feedback faster, then faster coding is not enough.
Because delivery is not about how quickly code is produced. Delivery should be evaluated by the flow of value.
What could be – and in some companies already is – the next shape of delivery? AI-native delivery. Inspired by Steve Yegge’s model of AI adoption levels in developers’ work, one possible shape of the flow could look like this:
Understand → Decide → Build with AI → Orchestrate → Verify → Ship → Learn ↺
And here is the key point: AI does not change the logic of delivery, it changes its shape. The business goal still matters, surprise surprise. The user and their problem or opportunity still matter. Technical decisions still matter, and so on. The biggest bottleneck no longer has to be the act of writing code itself. More and more often, it may move towards:
Orchestrate → Verify
This is where we need to handle a growing amount of AI-generated output, check coherence, understand risks, catch dependencies, see the impact on the system and make sure the solution still answers the right problem.
And that we can trust it. This is where responsibility for the whole becomes very visible.
In one system, the constraint will be the Orchestrate → Verify stage, because AI produces more output than the organization can sensibly integrate and validate. In another, the constraint will remain at Understand → Decide, because the problem is not the production of solutions, but the lack of clear priorities, decisions and ownership. In yet another, the constraint will be Ship → Learn, because the company can release things, but cannot quickly learn from data and user feedback.
The constraint is whatever, at a given moment, most limits the system from achieving its goal. Everything else may be a symptom, a local problem, noise or a side effect of working around the real constraint.
That is why the question is not: “Which stage can we speed up with AI?”, but: “What is really limiting the throughput of the whole delivery flow today?”
That is the difference between local optimization and working with the system.
Once we look at AI this way, the competitive gap becomes easier to understand. This is why AI will amplify the differences between companies that understand their delivery system and those that are simply adding tools.
The companies that understand user needs well, can turn them into clear priorities, have strong ownership, fast feedback loops and good data across the flow – they will speed up even more.
Not only in time to market. In time to impact. They will not just produce faster. They will create real effects faster.
And the companies with fragmented processes, weak signals, blurred ownership and decisions circulating around the organization will have more code, more tickets and more work in progress. Not necessarily more value.
That is why, for me, the most important question about AI in delivery is not: “Which tool should we choose?”, but: “Do we understand our system?”
Where is the flow? Where does work wait? Where does ownership blur? Where are we optimizing a fragment that will not actually improve the flow of value? Where are we speeding up a stage that does not speed up value for the user?
Because the bottleneck determines the real throughput of the system.
Different types of data help us get oriented.
Quantitative data, for example DORA, helps us see the technical part of the flow: deployment frequency, lead time for changes, stability and the ability to recover from problems.
That matters, but it is not the full picture of delivery. DORA will not show us the whole path from user problem to business impact.
That is why we also need DevEx data: surveys, comments, interviews and signals from teams’ everyday work. They help us understand friction, frustration, dependencies, quality of collaboration, cognitive load and the places where people lose energy.
One without the other gives us an incomplete picture. Metrics alone will tell us that something is slowing down. People will help us understand why.
Conversations alone will show frustration. Data will show whether it is a local pain or a systemic pattern.
So before we get too excited about how AI speeds up development, it is worth checking whether we actually have something worth speeding up.
Because AI in a good system can create an advantage. In an average system, it can scale mediocrity. And in a chaotic one — it can accelerate chaos.
This is why data matters: not as a reporting layer, but as a way to see how the system really behaves.
For readers who want to go deeper into this from a DevEx perspective, we explored these patterns in more detail in the Polish DevEx report: Polski DevEx: dane, procesy, AI. It looks at what helps engineering teams move faster, what gets in their way, how leaders use data and processes to improve delivery, and where AI strengthens the system or amplifies its weaknesses.
