From Prototype to Production: The 70% Wall

Where the 70% comes from, and what is not behind it

The concept was introduced by a piece of professional writing from late 2024, and the author is unusually honest about his source:

"A tweet that recently caught my eye captures perfectly what I see in the field."

The wording goes like this: non-developers get "surprisingly quickly to 70%, but the last 30% turns into an exercise in diminishing returns".

Let us say it plainly: the 70% is an observation, not a measurement. There is no sample, no methodology, no publication behind it. And it does not mean that AI does 70% of the work — no measurement supports that figure.

This does not weaken the idea, it sharpens it: the observation holds, the number is invented. The real measurements are somewhere else — and they are stronger.

The other number that gets quoted wrong

Whenever the subject turns to return on investment, sooner or later someone says that "95% of AI pilots fail". It is worth knowing exactly what that is.

The source is a 2025 report based on 52 structured interviews, 153 executive questionnaires collected at industry conferences and a review of more than 300 publicly announced initiatives. A convenience sample, not peer-reviewed, not representative.

And what it actually says: "95% of organisations achieve zero return". That is not the same thing as 95% of pilots failing.

A university expert's verdict on the report, word for word: "There appears to be no further support for the 95% claim. I have read the document through several times and I still do not see where it comes from."

What is worth quoting instead

The best-documented figure comes from August 2026: 1,719 respondents from 97 countries, surveyed in May and June 2026.

• 37% of companies attribute at least some bottom-line effect to their use of AI.
• That is the same as a year earlier.
• Only 6% count as frontrunners.
• Meanwhile 80% say their personal productivity has gone up.

The wall in one sentence: there is individual benefit, there is no company-level benefit. Eighty percent feel faster, thirty-seven percent can show anything at all — and that share has stood still for a year.

There is a forecast too that often gets quoted as a measurement: it says more than 40% of agentic AI projects will be scrapped by the end of 2027. That is an estimate, not data — but the same analysis notes that of the several thousand vendors calling themselves agentic, roughly 130 offer genuinely agentic capability.

What is in the remaining part?

Four things have hard measurement behind them, the rest only practice. It is worth telling them apart.

Security — measured. Across more than a hundred models and four languages: 45% of the code samples failed the security test, introducing a known vulnerability. The spread by language is wide: for one major enterprise language the pass rate is only 28%. The sentence from the researcher who led the work: "While the models kept getting better at writing working, syntactically correct code, they got no better whatsoever at writing secure code."

Maintainability — measured. A study analysing 623 million code changes found that between 2022 and 2026 the share of refactoring among changed lines fell from 21% to 3.8%, code-block duplication grew by 81%, and error-swallowing constructs by 47%.

Delivery stability — measured. According to the largest industry survey, AI adoption correlates positively with throughput but negatively with stability: more failed changes, more rework, longer lead times.

The productivity illusion — measured. In a controlled experiment, experienced developers finished 19% slower with AI, while afterwards they felt a 20% speed-up.

And what is not measured: authentication, permission handling, data migration, fault tolerance, load, observability, compliance. These come from practice, not from measurement — but the bigger half of the wall is made of them, and that is exactly why no number can refute it.

What does it cost to run?

This is the part most of the myths circulate about, so it is worth working through.

Say you have a feature — a customer-service summary, for instance — that serves ten thousand requests a month, at 4,000 input and 600 output tokens per request. That is 40 million input and 6 million output tokens a month.

(Own calculation with September 2026 list prices. Formula: number of requests × tokens per request ÷ 1,000,000 × unit price, separately for input and for output.)

At ten times the traffic, with a mid-tier model, that comes to $1,400 a month, roughly $16,800 a year. Caching repeated context brings the input side down to a fraction of that; asynchronous batch processing carries a further substantial discount.

The order-of-magnitude lesson: the token is not the expensive part.

And here is what is not in that figure:

• hosting, database, vector database, monitoring, logging;
• the retries and the agent loops — an agent run is not one call but ten to a hundred; the multiplier easily reaches ten to fifty times;
• the evaluation runs, which during development often burn more than live traffic does;
• the human review loop — the most expensive item on the list, and it is not measured in tokens;
• and the movement of model prices.

So the 70% wall is not a wall because tokens are expensive. It is a wall because the remaining part takes people, tests, accountability and operations — and not one of those gets cheaper because the prototype was ready in two days.

The anatomy of the wall

WHAT YOU HAVE IN TWO DAYS
  working screens, a basic data model, the happy path
  -> this is what you see in the demo

WHAT COMES AFTER THAT
  authentication and permissions   (who may see what)
  data migration                   (what about the old data)
  fault tolerance and recovery     (what if it falls over)
  load                             (what if many people come)
  observability                    (how you know it fell over)
  compliance                       (who answers for it)
  SECURITY                         (measured: 45% failure rate)
  MAINTAINABILITY                  (measured: duplication +81%)

THIS IS NOT 30%. This is what makes software software.

How you get through anyway

Not by magic. There are three things the measurements point at:

• The frontrunners redesigned the process instead of slotting AI into the existing one. In that survey of 1,719 respondents, close to three quarters of the best performers rebuilt their workflow from the ground up.
• Review capacity has to be planned in advance. If the volume of code grows and the volume of review does not, the wall gets higher, not lower.
• The prototype is not an early phase of the live system, it is a separate product. The cheapest decision is often to throw the prototype away and start again with what you learned.

Common misconceptions

• "AI does 70% of the work." No measurement supports that figure; its own author writes that he took it from a tweet.
• "95% of pilots fail." The source says that 95% of organisations achieve zero return — and that comes from 52 interviews and 153 questionnaires gathered at industry conferences.
• "It works for us, everyone got faster." Eighty percent feel that way. Thirty-seven percent can show any bottom-line effect.
• "Running the model will be expensive." Inference itself sits between ten and a few hundred dollars for a medium-traffic feature. The agent loops, the evaluation and the human checking are what cost.
• "The next model will carry us over the wall." The bigger half of the wall is authentication, migration, load and accountability. A better model does not help with any of those.

What to take away

The 70% is not a measured number, but the observation behind it is sound — and the real measurements are harder than it is: individual productivity at eighty percent, demonstrable business effect at thirty-seven, unchanged for a year. The remaining part does not turn on the model but on people, tests, operations and accountability. Tokens are cheap; proof is expensive.

Where the line sits for forgetting that the code exists is what the vibe coding reality check post maps out; the buy-or-build decision is worked through in the new buy-or-build calculation post, step by step; and the operations side is where the DevOps with AI post picks it up.