AI can increase output faster than a team can decide what matters, creating too many pull requests, scattered work, repeated effort, and output without impact.
2
Engineering work now has a decision layer, where people explore systems and agree on direction, and an implementation layer, where agents write much of the code.
3
Shared, durable documents can hold decisions and context while agents provide actions, so humans retain ownership and teams can work from the same state.
Summary
Matt Dailey describes velocity sickness as the stress caused by a sudden AI-driven increase in output that produces work without enough impact. He connects it to overloaded pull requests, engineers moving in conflicting directions, repeated work after abandoning agent sessions, and agents making decisions that engineers should own. Dailey argues that AI changes engineering from a mostly implementation-focused process into one with two distinct gears: planning and polishing. The planning gear is creative, exploratory, and collaborative. It needs a durable shared document rather than an isolated chat. The document holds decisions and system context, while agents take actions from that state. This makes agents easier to replace, lets people coordinate parallel work, and gives engineers a way to recover their understanding by rereading the document. Dailey's practical advice is to notice which gear you are in, treat plans as portals into the software system, and share plans with teammates before giving them to agents.
AI output creates team problems when coordination does not speed up with it
Dailey starts with four problems that appear when engineers use AI faster than their teams can absorb the work. There can be too many pull requests to merge, with merge conflicts and a broken merge queue. Engineers can move in many directions at once, with agents and teammates working on disconnected ideas. People can also declare "agent bankruptcy" by abandoning a mess of terminals and starting again, which repeats work and spends tokens twice. The most serious problem is allowing agents to make critical decisions. Dailey says this gives up ownership of the code, and at company scale it means the team no longer owns the product.
Velocity sickness is output that increases without producing impact
Dailey names the combined problem "velocity sickness." He defines it as the stress caused by sudden output increases from AI, affecting individuals and teams and resulting in output without impact. He illustrates the idea with a newsletter writer whose agentic workflow preserves and amplifies their voice. The writer says they are effectively producing a book every week, but their audience is not reading a book every week. The unread pages are the point of the example. Software teams can also build far more than the people they want to help will use or value.
AI changes engineering from one implementation loop into planning, implementation, and polish
Before AI, Dailey describes engineering as planning, building, iterating, and polishing before shipping. Existing tools, especially the IDE, were built for an individual working heads-down on implementation. With agents, a person starts by exploring an idea, an agent implements it, and the person takes the result back to judge whether it matches the original intent. Dailey says the human parts that remain most important are planning and polishing. Planning is where engineers understand a complex system, decide where it should go, and express their taste. That work is creative and collaborative, so it needs different support from code implementation.
The decision layer needs tools built around shared documents rather than chats
Dailey calls planning the decision layer and says engineers need to recognize which gear they are in and use an appropriate tool. A decision-layer tool should be built for documents, not chat. Chats are isolated and ephemeral, so decisions made while exploring with an agent can disappear even when code remains. A document brings important decisions forward for a team to review and align on. Dailey distinguishes this from plan mode, which he describes as a richer chat message, and from product-level specification work that is too far from the technical details engineers need to understand their systems.
A durable document holds state while agents supply actions
Dailey describes the plan as a portal into the software system. AI can find related parts of a system and lay out the material relevant to a decision. The important change is to separate the agent as the action from the document as the state. New agents can start from the same context and work on the same shared state instead of relying on one long-lived session. Dailey calls this context engineering in the document. When agents are effectively stateless, people can reread the document to understand the project and see which decisions have been made.
Planning ideas that are never implemented can be evidence of better prioritization
Once teams work this way, Dailey says they often plan ideas that they never implement. He considers that a good sign because the team is exploring vague thoughts before committing to code. Some ideas survive that exploration and others do not. He frames the change as moving from code velocity to idea velocity. Instead of getting trapped by the excitement of a prototype and following one path through an idea maze, engineers can explore more of the space before deciding what deserves to be built.
Early alignment reduces review work and prevents scattered implementation
Dailey applies the document-and-decision approach to the four problems he introduced. Aligning on important decisions before implementation makes code review easier because reviewers do not first have to work out what matters. Shared plans also let teams discuss direction before an engineer spends a day building a prototype in isolation. Agent bankruptcy becomes less necessary because the work is recorded in the document, and a person can rebuild their project context by reading it. Most importantly, humans retain ownership of the decisions behind the software and product.
Engineers should share plans with teammates before handing them to agents
Dailey ends with three actions. Engineers should think in terms of planning and polishing, notice when they move between those gears, and check whether their current tool fits the work. They should treat a plan as a flexible portal that can show the parts of the software system relevant to the current decision. They should also give the plan to a teammate before giving it to an agent. Dailey says this can feel unnatural because people assume they already understand the work, but teammates have useful context and can provide feedback early.
"The problem we work on at Ref is one you might be familiar with where individual engineers are going really fast with AI, but the team as a whole is not."00:12
Who should watch
Your engineers are producing more AI-assisted code than the team can review, merge, or coordinate.
You are losing context when agent sessions are abandoned and people have to reconstruct what happened.
You want a practical way to separate human decisions from agent implementation across a shared codebase.
