Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster

What happens when individual engineers get faster with AI, but the team does not? Matt Dailey, who introduces himself as Ref’s founder and CEO, starts with this gap. His tenfold acceleration scenario asks what breaks when everyone speeds up; it is not a measured productivity result.

The first visible failure is a pile of pull requests. An engineer generates changes faster than they can merge them. Multiply that across the team and the problem becomes merge conflicts, overloaded review and a merge queue that breaks down. Producing the next change is no longer the limiting step.

Three more failures follow:

• Too many directions. An individual tries to remember what each agent is doing until the coordination itself becomes exhausting. Across a team, engineers sprint toward different goals, sometimes colliding, without moving the system coherently.
• Agent bankruptcy. An engineer finishes the day with twelve terminals open and a satisfying sense of accomplishment. The next morning, the sessions feel like a room of strangers: what are they doing, and why? Deleting them and starting again feels easy, but it repeats work and spends tokens on problems already explored.
• Critical decisions made by agents. When an engineer lets an agent make a consequential choice without taking ownership of it, control of the code shifts to the agent. Dailey’s concern is that repeating this across a company means giving up ownership of the product itself.

Dailey calls this velocity sickness: the stress caused by sudden increases in AI-assisted output, affecting both individuals and teams. Its defining result is output without impact. Everyone feels productive, yet the outcomes that should follow from that productivity fail to arrive.

The problem is easier to see outside software. Dailey describes a conversation with a newsletter writer whose agent workflow begins with the writer’s own ideas, then moves through research, exploration, connections between ideas and editing to preserve their voice. He admires the system: the agents amplify the writer’s thinking rather than producing generic filler.

Dailey reports that the writer described producing a book’s worth of writing every week. When he asks whether the audience reads that much, the answer is probably not. The conversation exposes a mismatch between production capacity and readers’ attention, even when the writing itself is good.

Unread pages have a software equivalent: features and products that fail to connect with the people they are meant to help. The desired outcome is not simply more words or more code, but something that improves how people live and work. AI expands the ability to make those things; velocity sickness is the experience of that increased ability failing to land.

Before agents, the familiar engineering workflow began with planning, moved into a substantial stretch of implementation, and ended with polish and shipping. Implementation could be exploratory and iterative, but much of it involved an individual working heads down. The IDE fit that pattern: it was built to help one engineer write and refine code.

Agent implementation changes the shape of that work. A human starts with an idea and fleshes it out; an agent implements it; the human takes the result back and asks whether it matches the original intent. In this workflow, planning and polish become the two prominent sites of human judgment. Both are creative and collaborative, even though the implementation between them may happen largely through an agent.

Planning is especially different from merely requesting code. An engineer has a vague idea and a complex existing system. They need to understand the system’s contours, identify the relevant parts and decide how the idea should change them. That is where engineering taste enters: which direction should this system grow? Team structures may change, but a group of people still has responsibility for deciding the system’s future.

This creates a decision layer distinct from implementation. The practical skill is recognizing the gear you are in and choosing tools that support it. A tool optimized for producing code may not be the right place to reason collectively about the decisions that code will embody.

A workspace for the decision layer should center on documents rather than chats. Dailey characterizes implementation chats as isolated, ephemeral and oriented toward getting something done. An engineer can explore an idea there, but consequential decisions accumulate in a conversation the rest of the team does not see. The eventual code contains the consequences without necessarily making those choices explicit.

The interaction can also encourage reflexive approval. An agent proposes a course of action, asks permission to proceed, or marks one option as recommended. Selecting that recommendation keeps work moving, but it can bypass the thinking the engineer needed to do.

A shared document gives that thinking somewhere to happen. The human job is to identify the decisions that matter, make them deliberately and let agents fill in the rest. This is a familiar alignment practice: a manager would not respond to a confused team by asking everyone to disappear into separate Slack DMs. They would bring important decisions into a shared space where people could discuss and resolve them.

Two nearby approaches are useful but do not quite describe this workspace: agent plan mode and full, factory-style specification-driven development. Dailey places the decision layer between them.

In Dailey’s description, plan mode remains a rich chat message inside an isolated session. At the other end, specifying behavior and letting a factory produce the implementation can leave engineers too far from the system they need to understand. The middle ground is a long-lived technical plan that the team can examine together.

His metaphor is a Tony Stark-style portal into the software system: “Show me what matters.” For the change at hand, AI can find related parts of the system and lay them out for inspection. The engineer then organizes those pieces to express how the system should evolve. The document is therefore more than a task checklist; it is a malleable representation of the relevant engineering problem.

A long-lived agent session builds implicit context as it works. Discoveries, decisions and actions become intertwined in the session’s history. That context is useful, but it is difficult for another person—or a fresh agent—to start from exactly the same place. The architectural move is to separate the agent as action from the document as state.

New agents can then begin from the same explicit context. The document becomes the place where context is selected and organized, making the agents largely stateless relative to the project’s durable record. Humans can inspect that record to understand which decisions have been made. The core unit of work becomes the document rather than the conversation.

For example, a planning document for a proposed CSV export could preserve the request, the relevant system facts and the boundary between an approved decision and an unresolved one:

# CSV export plan

## Request
Let users export the currently filtered orders.

## Relevant system context
- The orders list already applies account permissions.
- The list and the export must use the same filter semantics.

## Decisions
- Approved by the team: preserve existing account permissions.
- Pending human review: synchronous download or background job?

## Next agent task
Inspect the export paths and explain the tradeoffs for the pending
choice. Record findings here. Do not implement the export yet.

In this example, a replacement agent can read the same request and constraints without reconstructing an earlier conversation. The pending choice remains pending: preserving state does not turn a proposal into an approved decision. This is the practical purpose of doing context engineering in a shared document.

Dailey reports an initially surprising behavior when people adopt this approach: they write plans and then do not implement some of them. He treats that as a good sign. An engineer can bring a vague idea to an agent and ask for help understanding it, without immediately asking for code. After exploring several possibilities, they choose which ones deserve implementation.

This shifts the target from code velocity to idea velocity. A fast prototype can exert what Dailey calls prototype gravity: once something exists, the excitement of shipping it pulls the team down that particular path. Exploring ideas before committing to implementation makes more of the idea maze accessible, including valuable alternatives that an early prototype might have crowded out.

The proposed workflow addresses the opening failures by changing when and where people align:

For pull requests, the key is to answer the hardest review question earlier: what actually matters in this change? Once the team has agreed on that, code review can focus on whether the implementation follows through. For divergent work, sharing plans creates an opportunity to correct direction before someone spends even a day building deeply into an idea. The same plans help an individual understand work distributed across several agents.

Dailey argues that agent bankruptcy disappears when agents are stateless and the results of their work persist in the document. The mechanism depends on that persistence: the human rereads the project state and resumes from it, rather than discarding opaque sessions and repeating the work. Most consequentially, the workflow makes human ownership of decisions explicit, preserving ownership of the software and the product it expresses.

Extracting shared state also makes parallel agents easier to coordinate and creates a durable decision log. Rather than asking an LLM to summarize a long session afterward—and risking that it selects the wrong details—the team records and agrees on important decisions up front. Those decisions remain available for later reference.

The larger organizational consequence is more collaboration. Dailey predicts that engineering will become multiplayer by default because more of the human work is creative. Under the pressure to deliver as AI accelerates development, working together is also how people handle the strain. Tools for the decision layer should support that collaboration, not merely increase each person’s isolated output.

Dailey closes with three practices that do not require waiting for an entirely new toolchain:

1. Recognize planning and polish as different gears. Notice when a single agent session drifts from figuring out what to build into refining something already built. Reassess whether the tool still serves the work you are doing.
2. Treat the plan as a portal into the system. Ask it to reveal the system details relevant to the current problem. Shape that representation until it helps you make the important decisions.
3. Share a plan with a teammate before handing it to an implementation agent. Even when sharing feels unnecessary, teammates carry context that is absent from your own thinking and from the agent’s session. Their feedback can change the plan before code makes the direction harder to reconsider.

He positions Ref Plans as a tool for this decision layer and says Ref works with all existing implementation tools. That is his compatibility claim; the closing invitation is to see a demo at the booth or speak with him in person. The proposed addition to the toolchain is a shared place to decide what should happen before agents carry those decisions into code.