Skip to main content

02.20Concept

The acceleration paradox

AR Labs' view of AI productivity: feeling faster is not being faster, and some work, learning above all, should not be sped up.

Read the essay: The Acceleration Paradox
A speed dial: the felt needle swings to ten times, the measured one sits under one. An hourglass marks slow work.A large speed dial on a log scale from a quarter to a hundred times. A violet needle labelled felt swings to ten times, while an ink needle labelled measured sits just below one. Speed streaks trail behind the dial; to the right an hourglass stands for learning and judgement, which should not be fast.REDLINE0.25x0.5x1x2x5x10x20x50x100xFELTMEASUREDLEARNING AND JUDGEMENTSHOULD NOT BE FASTTHE FEELING OF SPEED IS NOT A MEASURE OF ITAR LABSCONCEPTSC-08FELT VS MEASUREDSCALE NTS
On this page
  1. The thread from cognitive science
  2. The argument in seven parts
  3. How we apply it

The acceleration paradox is the observation, central to how AR Labs works, that the push to go faster with AI may be taking people in the wrong direction. Marketing around AI tools promises ten or a hundred times the output, and the feeling of speed is real. But the feeling is not a reliable measure, faster delivery can carry hidden costs in quality and learning, and some kinds of work, such as learning and judgement, should not be sped up at all.

Richard M. Thompson, who founded AR Labs, set out the argument in an essay, The Acceleration Paradox, which introduces a seven-part series. This page summarises the idea and how it shapes our way of working.

The thread from cognitive science

The series ties its arguments together with an idea from our founding framework, cognitive ecology: conscious attention inherently lacks ecology. Attention is a narrow beam, good at optimising the one variable it is pointed at and blind to the wider system that absorbs the cost. Gregory Bateson, whose essays on conscious purpose underpin that framework, warned that technology adds power to conscious purpose without widening its view. The acceleration story, in the essay's words, is what happens when that beam gets an engine.

The argument in seven parts

The essay lists the parts of the series, each taking one strand of the argument. Part 2 rests on a 2025 randomised study by the research organisation METR, in which experienced open-source developers took longer to finish tasks with AI tools while believing the tools had made them faster.

  1. Acceleration as the product: the promise of velocity, and the questions the marketing never asks.
  2. Felt faster, measured slower: the METR study, and why the feeling of speed cannot be trusted.
  3. The engineering productivity paradox: feature delivery goes up, and so do duplication, complexity and technical debt.
  4. Some things should not be fast: learning, judgement, and the case for the human bottleneck.
  5. Hidden costs: low-quality generated content, devalued effort, and keeping one's own thinking in working order.
  6. Do not pull the ladder up: if AI replaces junior developers, the route by which people become senior developers disappears.
  7. When the builders are scared: what the people building AI have said under oath about their own creations.
FIG. 01
flowchart LR
  A["Promise of speed"] --> F["Feels faster"]
  F --> M["Measured outcomes lag"]
  M --> H["Hidden costs: technical debt, low-quality output, lost learning"]
  H --> C["Choose deliberately what to speed up"]

How we apply it

The essay's conclusion is a middle path: work more slowly and purposefully where it matters, and use AI for what it does well. It closes on the advice of Mario Zechner, creator of the Pi coding-agent harness, from his talk "Building Pi in a World of Slop": slow down, think about what is being built and why, learn to say no, and build fewer features, choosing the ones that matter.

That position runs through our practice. Our coding pipeline puts planning, written specifications, tests and independent review between an idea and merged code, and a person merges to the main branch. The harness paradox argues that useful agent autonomy comes after careful constraint. And the temperature of specification slows the early stages of a project down on purpose, so that later stages do not race toward the wrong solution.