technical-term · Operating model · practitioner · Reviewed

Velocity sickness

Matt Dailey’s practitioner term for the coordination strain that appears when local AI-assisted production accelerates faster than a team can decide, review, integrate, verify, and absorb it.

Definition

Velocity sickness is an attributed thought-leadership framing—not a clinical or validated organizational diagnosis. It names a real systems question: what happens when generation throughput rises but product decisions, review, test environments, verifier ownership, merge capacity, release authority, and operational learning do not rise with it?

The underlying queue and coordination dynamics are established; this exact label is a new practitioner coinage and should remain attributed.

Why it matters

AI can make implementation locally faster while making the delivery system globally slower.

Rejecting speed is not the answer, and unlimited concurrency is not absorption. The response is to redesign the full value stream around evidence, constraints, and real bottlenecks.

System anatomy

Generation rate
How quickly code, PRs, analyses, and alternatives are produced.
Decision capacity
How quickly humans can resolve product, risk, and architecture choices.
Verification capacity
How much work independently owned checks can credibly challenge.
Integration capacity
How safely the system can merge, test, release, and learn from changes.

Important distinctions

Developer productivity
More generated artifacts or activity does not by itself mean more delivered value.
A universal 10x claim
Measured outcomes vary by task, developer, tool, system quality, and time period; “10x” is a provocative scenario, not an established constant.

Implementation signals

  • Track queue time, rework, stability, outcomes, and cognitive load alongside generation
  • Limit work in process to integration and verifier capacity
  • Use small batches and isolated workspaces
  • Preserve named human product and release decisions

Failure modes

  • PR count becomes the success metric
  • Review is automated by a correlated model and called independent
  • Teams suppress new tooling without fixing the actual constraint

Sources and further study

  1. Matt Dailey · AI Engineer World's Fair — Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster

    A practitioner framing for the coordination pain that appears when individual generation accelerates faster than shared decisions, review, and integration. It is an attributed field term, not a clinical or validated organizational diagnosis.

    Use in this library: Practitioner perspective. “Velocity sickness” is an attributed practitioner coinage, not a clinical term, validated diagnosis, or measured universal effect.

    talk · video · Published 2026-08-09
  2. Google Research / DORA — DORA 2025 State of AI-assisted Software Development Report

    Large-sample research framing AI as an amplifier of the capabilities and dysfunctions already present in an engineering organization.

    Use in this library: Empirical evidence. The report identifies population-level relationships and system conditions; it does not promise that AI adoption will improve any individual team or metric.

    research · research · Published 2025
  3. Microsoft Research / ACM Queue — The SPACE of Developer Productivity: There's more to it than you think

    A multidimensional productivity framework spanning satisfaction, performance, activity, communication, and efficiency rather than reducing engineering value to one activity metric.

    Use in this library: Empirical evidence. Interpret the result within the published sample, task, model, environment, and measurement design; it does not establish a universal outcome.

    research · research · Published 2021-02
  4. GitHub — Agent pull requests are everywhere. Here's how to review them

    A current practitioner account of agent-generated pull requests saturating review bandwidth and the continued need for contextual human judgment.

    Use in this library: First-party case study. This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.

    engineering · engineering · Published 2026-05-07
  5. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

    A randomized study in one narrow setting that found experienced contributors took longer with early-2025 tools. The authors explicitly caution against generalizing the result to all developers, tools, repositories, or later model generations.

    Use in this library: Empirical evidence. The randomized study covered 16 experienced contributors, 246 tasks, mature open-source repositories, and early-2025 tools; it does not establish that AI always slows developers or predict later tools.

    research · research · Published 2025-07-10