# Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.

## Executive summary

The video addresses 'velocity sickness'—the stress of sudden, unimpactful increases in AI-driven output that do not translate into meaningful product progress. The speaker argues that current engineering workflows are flawed because they treat all work as implementation (code) and fail to properly manage the critical decision layer. To solve this, engineers must separate the durable state/decisions from the ephemeral actions/implementations. This is achieved by shifting focus from using chat interfaces for planning to utilizing dedicated, shared document structures that capture system state.

## Key takeaways

- Understanding Velocity Sickness: Velocity sickness is defined as the stress caused by sudden output increases due to AI, resulting in high output without corresponding impact. This manifests as too many PRs to merge, working across too many directions simultaneously, or 'declaring agent bankruptcy' (doing work that isn't retained).
- The Critical Failure Point: Decision Ownership: The most critical risk is allowing agents to make key decisions. If an engineer delegates decision-making, they lose ownership of the code and, by extension, the product.
- Shifting Focus from Code Velocity to Idea Velocity: To combat velocity sickness, teams must shift focus from merely shipping code (code velocity) to prioritizing and exploring ideas (idea velocity). This means focusing on planning and understanding the system's contours before implementation.
- The Solution: Docs for Decisions, Not Chats: The core fix is separating the decision layer from the implementation layer. While chats are isolated, ephemeral, and built for action, durable shared documents (docs) should be used to hold the state and key decisions, keeping agents effectively stateless.

## Technical details

- Decision Layer vs. Implementation Layer: The speaker advocates for recognizing two distinct 'gears' of engineering work: planning/polishing (the decision layer) and implementation. Tools must be built to support the former, which is currently underserved by chat-based AI tools.
- Stateless Agents: By centralizing state in a durable document rather than an ephemeral chat, agents can remain largely stateless. This allows multiple agents to start from identical context and collaborate on the same shared piece of truth.
- Process Improvement: PR Review: By aligning on key decisions upfront (in the decision layer), code review becomes simpler because the hardest part—determining 'what actually matters'—has already been addressed.

## Practical implications

- Treat your planning phase as a 'portal' into the software system, rather than just a prompt.
- Do not hand plans only to an agent; share them with human teammates for valuable feedback and alignment.
- When working in AI sessions, consciously identify if you are operating in the Planning gear or the Polish/Implementation gear.

## Topics

AI Engineering, Software Architecture, Product Management, Build Systems, Agentic Workflows, Matt Dailey, Ref

Source: https://www.youtube.com/watch?v=Kz4QJmNrVXU