The Productivity–Reliability Paradox

Idea one

Individual output is not system performance

The gains are real, and denying them would be as unhelpful as treating factory automation as a faster hand tool. A developer generates more code, closes more tickets, submits more pull requests. An analyst produces more scenario models. A service unit handles more inquiries per person. At the level of visible activity, the organisation looks more productive.

The system-level questions are different ones. How much of that work is accepted without substantial rework? How often do outputs create downstream ambiguity? How many defects escape into later stages? How much additional review is required? Are customer outcomes improving? Are people gaining capacity for higher-value work — or simply spending more time validating a larger volume of machine-generated material?

So the paradox is precise: output is accelerating faster than organisational reliability is improving, and in some settings output accelerates while reliability actively deteriorates. Both statements can be true at once, which is exactly what makes it hard to see from a dashboard.

Idea two

Generated work is inventory, not value

Generative systems reduce the friction of beginning. That reduction in initiation cost is powerful, both operationally and psychologically — work that once demanded concentrated effort now starts with a prompt.

But when the cost of generating content falls sharply, organisations begin producing more content than they can meaningfully absorb. More reports, because reports are easy to create. More code, because code is easy to generate. More analyses, because data can be summarised in countless ways.

The result is a new form of digital inventory: unreviewed or weakly reviewed AI-generated artifacts. It behaves exactly like excess work-in-process on a factory floor — it creates the appearance of activity while concealing congestion. A large queue of generated outputs is not completed value. Until it has been validated, contextualised, approved and integrated into a reliable downstream process, it is a partially finished artifact.

And in some cases it is not an asset at all. It is a future verification obligation.

Idea three

Churn, and defects wrapped in mutual confirmation

Software shows this most clearly — not because it is uniquely vulnerable, but because code leaves a detailed operational trail that can be counted, committed, tested, reverted and traced.

Churn is usually defined as how often code changes after being written. In an agentic context it is better understood as a symptom of unstable convergence: generate quickly, revise after review, modify after testing, rework after integration, patch after deployment, and possibly replace when the original design proves incompatible. Visibly active, not progressing cleanly toward a dependable outcome.

Some churn is healthy; good engineering requires iteration. The problem begins when the speed of generation overwhelms the system's capacity to absorb, understand and validate what has been generated. A model may not know the undocumented architectural decisions in a codebase, may duplicate a utility that already exists, may use a library version no longer approved, or may mishandle a rare but consequential exception. Compilation is not comprehension, and a passing test is not proof of system fitness.

The sharpest version of this is technical aligned failure. If the same flawed context informs both the implementation and its tests, the system looks internally consistent while being wrong. The code works according to the test; the test passes according to the code; the pull request looks complete; the dashboard records progress. The defect was not prevented — it was wrapped in mutual confirmation.

A tired reviewer may read an extensive generated test suite as rigour, when it is only a larger amount of unexamined material.

Idea four

The three outcomes, and all of them are waste

When generation capacity rises in volume but review capacity does not rise in quality, one of three things happens. There is no fourth option, and each is a form of waste with a Lean name.

Delay. Pull requests wait longer, release cycles slow, and the organisation discovers its productivity gain has simply moved the bottleneck into review. That is waiting waste.

Superficial approval. Reviewers scan for obvious mistakes, accept plausible explanations, and rely on automated tests that may not be testing the right things. That is defect risk disguised as throughput.

Informal rejection. Experienced people quietly stop trusting generated contributions and rewrite them, which creates frustration and destroys the very productivity the tools were meant to deliver. That is overprocessing and hidden rework.

None of the three appears if leadership watches commit volume, ticket closure or first-draft speed. And when generated work grows faster than the organisation can validate it, what accumulates is epistemic debt: unsupported assumptions, weak summaries, incomplete rationale and unexamined edge cases entering operational flow. Some will be caught. Others become part of the organisation's working reality.

Review itself changes character here. In a healthy environment it is a collaborative examination of design, assumptions, security and fit — a way experienced people transfer judgement. Under volume it degrades into a throughput ritual.

Idea five

Amplified, or destabilized

The same class of tools extends human capability in one organisation and erodes it in another. That is the amplified versus destabilized divide, and the difference is not model quality.

In the first kind, AI is aimed at low-value searching, repetitive drafting, routine formatting and predictable coordination — and the organisation simultaneously invests in source quality, workflow standards, review design, agent boundaries and employee capability. AI creates capacity, and some of that capacity is deliberately reinvested in learning and quality rather than immediately spent.

In the second, the objective is output expansion or labour compression. The system is dropped onto fragmented processes and a weak knowledge environment. Employees absorb the exceptions, review queues grow, workarounds return, and the organisation responds with more pressure, more dashboards, or an instruction to use AI more effectively. There may still be short-term gains — but it is amplifying the entropy already present in the operating system.

The difference is the maintenance discipline surrounding the model.

Which is why the conventional measures no longer stand alone. Tasks completed, tickets closed, documents produced, calls handled, lines written, hours saved — these describe activity, not capability. A high volume of completed tasks may mean success, or it may mean errors are moving rapidly through an automated pipeline. The revealing measures connect speed to reliability: rework rates, reviewer override rates, defect escape rates, exception aging, human intervention load, decision reversal rates, and the time required to restore trust after an error. They do not reject productivity. They place it inside the purpose it was supposed to serve.