Why did projects used to move slowly, yet more often deliver?

Everyone says AI will let businesses do more on their own: launch marketing campaigns, gather analytics, prototype products and write code faster, build interfaces, do without part of their contractors.

Seen this way, AI looks like a technology of direct access to execution. Between a company's intent and its realization there should remain fewer people, fewer approvals, fewer outside vendors. Business gets to test ideas without losing time, in-house teams ship results faster, and contractors stop being a mandatory link in the production chain.

The paradox

This expectation looks perfectly rational. AI is already taking over a noticeable share of the work that used to be bought from agencies, developers and consultants: draft copy and campaign plans, first design variants, research, prototypes, boilerplate code, testing, data processing. What used to take a small team weeks of work can now sometimes be had in a few hours.

Hence the new business logic. Why keep a long chain of contractors if part of the work can be done in-house? Why wait in line for the IT team if a product manager can put together a first prototype on their own? Why buy production hours in bulk if AI lets a small group of people produce far more? For agencies and IT companies the conclusion is mirrored: the same services will have to be delivered faster, by smaller teams, under a much tougher conversation about price.

Only yesterday this picture seemed utterly realistic, but as the wave of enthusiasm subsides, a question arises: why don't we see the radical changes in business that the AI evangelists promised us? And why did projects used to run slower yet more often end in working results, while now, with AI, they are done fast and bring none?

What research and the experts say

The overwhelming majority of current publications — consulting, technology, academic — converge on one frame: AI is fine, the organization is not ready. The standard list of causes is the same everywhere: the data isn't ready, the goals weren't defined up front, there is no owner on the business side, governance is weak, skills are lacking, people resist.

RAND Corporation, in the largest-coverage study of AI failures to date (65 interviews with practitioners), names five root causes: stakeholders misunderstanding the problem, poor data quality, infrastructure gaps, excessive focus on the technology instead of the task, and applying AI to problems it cannot handle. Alice Labs added two more from its own practice: the absence of a business owner and insufficient governance.

And all these sources propose an identically structured answer: first run a data audit, appoint an owner, do the economics, formulate metrics, build governance, assemble a cross-functional team — and only then move to implementation. It is the standard seven-step framework, reproduced with minimal variation all the way from McKinsey down to narrowly specialized IT blogs. IBM calls it the "journey from pilot to production"; 7N Consulting, the "AI Execution Gap"; Pythian, "from pilot to production failure".

From this picture follows the familiar recipe: pick more mature use cases, set KPIs more precisely, prepare processes more carefully, look for strong technology partners. In some cases it genuinely works. Klarna, for example, automated a significant share of routine support requests, but then restored a more visible role for humans in complex cases and kept the option of handing the conversation over to a person. The trouble begins where this recipe is applied to every project alike — as if each of them already contained a well-understood piece of work that merely remained to be organized properly.

What's wrong with this picture

That is how things look if you accept as an axiom that at the start of any project a clear problem statement exists. This assumption underlies all tender procedures and standard project methodologies. How else could one suppose that project success depends on how competently specialists approach its execution? Yet that is exactly how the question is posed when it comes to replacing them with AI.

In reality, in a significant share of digital and organizational change the task does not exist in advance. It emerges in a process where business knowledge, system constraints, technological possibilities, the interests of different departments and the consequences of choices collide. Data, KPIs and a business owner are necessary elements, but they do not assemble this process automatically. They help control execution only once it is already clear what exactly needs to be built.

There used to be an expensive, slow, human production chain standing between a business's vague intention and a finished result. The agency, the analyst, the architect, the designer, the project manager and the developers reassembled the original idea many times over: asked uncomfortable questions, showed mockups, argued about priorities, discovered constraints, made mistakes in early versions and refined the solution as the work went on.

This work was almost never singled out or sold separately. It was dissolved in free presales, analysis, documentation, calls, revisions and development iterations. A strong contractor compensated for a poorly formulated task with its own expertise and a great deal of communication; a weak one got endless change requests and a conflict over "the wrong result". But the slow cost of production created enough time and friction between the parties for people to notice they did not understand each other.

AI severs this hidden link. It sharply cheapens and speeds up precisely the production layer: a prototype, code, analysis, a design variant, a text, a piece of research can be obtained before people have had time to agree on the meaning and boundaries of the task. What used to be slowly clarified over the course of a project now instantly materializes in dozens of quite convincing candidate solutions.

So the old vagueness stops being tolerable. Not because AI is "worse than a human", but because it does not automatically create the chain of questions, agreements and responsibility that the expensive human process of work used to create. It can generate an interface or an automation plan, but it cannot itself legitimately decide which business goal the company will sacrifice for speed, where risk is acceptable, and whose interest takes priority in a conflict. The cheapening of routine execution sharply raises the value of the work that precedes it — choosing the direction, the frame, and the next testable hypothesis.

What is described above in plain words rests on a long-known division of work. Back in the early 1990s David Maister, dissecting how professional firms operate, divided their projects into three kinds. The first — "Brains": the task is new, at the cutting edge, and the value lies in inventing a solution that does not yet exist. The second — "Grey Hair": the task is known in principle, but it takes a practiced hand to pick the right path among many. The third — "Procedure": both the what and the how are clear, and the value lies in efficient, high-quality execution.

Maister looked at this from the firm's side — what it sells. Look instead from the side of the task itself, and the same three kinds line up into what I call the funnel of uncertainty — along a single dimension: how much in the task is unclear. At the bottom, where there are almost no unknowns, it is "clear what and clear how"; that is execution. In the middle, "clear what, unclear how"; that is the work of experience. At the top, "unclear even what"; that is the assembly of the task itself — work before which execution makes no sense to begin.

Here the funnel stops being a mere classification. It immediately shows where the boundary of responsibility must run. The execution of the bottom layer can be entrusted to a machine or a team. The middle layer is held by an experienced practitioner. And the top layer cannot be "handed off" to anyone for execution — it is answered for by whoever assembles the subject of the work, and the answering has to happen before anything is put into production.

From here the mechanism of the paradox that opens this article becomes visible. The old expensive process, without ever naming it, served all three layers at once: slow production left time inside which the work of experience and the assembly of the task got done unnoticed. AI collapsed the cost of the bottom layer — and thereby exposed that no one had ever explicitly held the top one. The market keeps treating top-layer tasks as if they were bottom-layer ones: it sends into fast execution what has not yet even been assembled into a task. AI did not create this — it merely removed the slowness behind which it used to hide.

The production cycle stops being the project's skeleton

All of which brings us to the question: how should projects be organized now — inside the company and with outside participants — if fast, AI-powered production no longer compensates for the vagueness of the intent. What should the new model of working on business problems look like — and, more broadly, on any project that involves AI.

Start with this: in such a model the solution is not passed down the classical chain from client to contractor. It emerges at the intersection of different domains: the business knows its constraints, its customers and the price of decisions best; subject-matter specialists know the possible courses of action and their consequences; AI is fastest at producing, comparing and testing variants.

So the technology vendor no longer receives a ready-made task as input and no longer hands over a pre-promised result as output. In essence, the classical contractor or agency here shifts to an expert model of participation. Its work begins with taking part in the very process of determining what, for the company, is the subject of work right now. Not as a separate "phase zero" before the project and not as free presales, but as a permanent function inside it. Under this approach the project is built around the search for solutions rather than around a production cycle.

Tellingly, the market arrives at the same conclusion: a16z investors, in early 2026, describe this shift in almost the same words — the hard problem has moved from how to build to what exactly to build. In effect the function already exists — just in different forms and under different names.

In product teams it lives as continuous discovery: the team does not pass a finished solution further down the conveyor, but keeps returning to the question of which problem is worth solving. In large structures it takes the shape of a competence center — not "the department that picks models", but the function that decides what to automate and where, and which experiments it is time to stop (this is how the joint AI centers of Russian Post and Sber are organized, for example).

Companies that don't need such a function in-house bring it in from outside — for example, as an independent producer, a project runner who takes part in choosing the direction and the architecture, assembles the right people around the task and holds responsibility for the course of the work, rather than arriving with a ready-made verdict. On the vendors' side the same function gets packaged as a separately paid service: ThoughtWorks, for one, deliberately separates understanding the problem from planning the solution, warning that mixing the two pushes a team toward a premature choice.

The cast of participants stays the same — what changes is what each of them holds:

From here it is also clear that production does not disappear — it merely stops being the form of the whole project and becomes one of the resources plugged in at the right moment. The subject of the deal changes too: the business buys neither hours of hands nor a deck of ready answers, but the ability to travel the path from vague intent to governed action — assemble the task, choose the direction, organize the test, and only then roll out fast, AI-amplified delivery.