Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.
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
2:00
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
5:45
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
10:30
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
13:25
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.
