While working on estimates for new projects, I increasingly catch myself on an uncomfortable thought. We continue to calculate timelines and budgets as if nothing fundamental has changed in the industry over the past two years. As if developers still do not have a constant intellectual assistant at hand. As if modern LLMs have not become part of everyday engineering practice.
Formally, everyone agrees that productivity has increased. In certain classes of tasks, significantly. Yet when you look at the final numbers for the client, this increase is barely visible. Budgets do not shrink. Timelines are reduced only marginally. Sometimes they are not reduced at all.
This creates a paradox. LLMs genuinely reduce the effort required from developers, but they almost never reduce costs for the client.
At the level of low-level implementation, the effect is immediately noticeable. Typical application code, infrastructure glue, integrations, data serialisation, standard API components, automated tests and technical documentation are all produced faster and with fewer mechanical defects. Cognitive load is reduced. There is less routine work, fewer accidental errors and a higher baseline level of execution quality.
However, the higher the level of abstraction, the weaker the effect of using LLMs becomes. Architecture, context boundaries, complex scenarios, asynchronous processes and product trade-offs are all areas where LLMs do not make decisions. They can accelerate thinking, help validate hypotheses or highlight risks, but responsibility remains with the people and the team.
It is precisely at this level that defects begin to accumulate, cancelling out the gains in implementation speed. These defects cannot be caught by linters or tests. They exist at the level of reasoning and interaction, not at the level of code.
As a result, the time saved is not converted into lower budgets but into rework. Logic has to be rewritten or adapted. Systemic mistakes are corrected only after everything was supposedly delivered quickly.
From the client’s perspective, this looks straightforward. The timelines are the same. The budget is the same. And inside the team there is no clear feeling that they are working faster than before. They are working differently, that much is certain.
At the same time, we know another well-established fact. Solo developers who use LLMs consciously and systematically often demonstrate productivity gains of x2 or more. They genuinely deliver more in the same amount of time. This raises an obvious question. Why are teams unable to reach the same level of efficiency as individuals?
There are several possible reasons. One of them is modern corporate culture pushed to the extreme of functional segregation. Front-end separately, back-end separately, databases separately, infrastructure separately. Every boundary requires coordination. Every interaction requires synchronisation. All of this coordination begins to consume the very efficiency gains delivered by faster development at the task level.
Another reason is the averaging effect across teams. In any team there are top performers who already know how to use LLMs effectively and truly work at a much higher speed. Their results are offset by developers who have not yet learned how to extract the same level of efficiency from these tools. As a result, average team productivity grows far more slowly than the productivity of its strongest members.
Finally, time itself may be a critical factor. Widespread use of LLMs is not just about access to tools. It requires changes in engineering habits. Not everyone has learned this yet. Not everyone has adapted their way of thinking. Until this gap is closed, team efficiency will continue to lag behind individual performance.
LLMs have already changed software development. But they have not yet changed the economics of teams to the extent they could. This is not a technological problem. It is a problem of processes, culture and the way we are still accustomed to thinking about how teams work.
