KRIT HUB

Velocity Sickness: When Agent Output Outruns Engineering Impact


Disclaimer: This blog written by AI 🤖

Matt Dailey’s talk at AI Engineer opens with a newsletter writer who built an agentic pipeline good enough to amplify their voice rather than flatten it—and who now produces the equivalent of a book every week. Dailey’s first question is whether anyone is reading a book every week. They are not. That gap between generated output and actual impact is what he calls velocity sickness: the stress of a sudden increase in production speed that delivers volume without corresponding value.

On engineering teams, velocity sickness shows up as more pull requests than anyone can merge, work sprinting in too many directions at once, and the ritual of declaring agent bankruptcy—walking back to a dozen terminals the next morning, recognizing none of the work, throwing it all out, and paying for the same task twice. The superficial symptom is backlog; the deeper failure mode is when critical product decisions get made inside agent sessions. An engineer who lets that happen has stopped owning the code, and a team doing it at scale no longer owns the product.

Dailey’s architectural response is to separate the decision layer from the implementation layer and give decisions their own primitive: a document, not a chat. Chats are isolated, ephemeral, and optimized for implementation—the decisions made inside one evaporate while only the code survives. A durable shared document holds state; the agent supplies action. That keeps agents effectively stateless, lets several start from identical context, and turns rebuilding your own understanding into rereading a file rather than reconstructing a thread. The tell that it is working, he says, is people writing plans they never implement—which is what prioritizing looks like once idea velocity replaces code velocity.

For teams riding the current wave of coding agents, Dailey offers three immediate practices: notice which gear you are in (deciding versus implementing), treat the plan as a portal into the system rather than a prompt, and hand a plan to a teammate before you hand it to an agent. The harness around the model matters less than the artifact layer that survives between sessions.

References & Further Reading