The condition: output without impact#

Dailey’s own definition is precise: velocity sickness is “the stress caused by sudden output increases thanks to AI,” it “affects individuals or teams,” and the result is “output without impact” [1]. It is not burnout in the usual sense. Nobody is producing less. Everyone is producing more, and the outcomes that should follow from more output, more shipped features, more resolved problems, more value delivered, are not showing up at a matching rate.

Dailey makes the condition concrete with a story from outside software entirely. He describes talking with a newsletter writer who had built an elaborate AI-assisted pipeline for research, drafting, and editorial polish, all in the writer’s own voice, genuinely impressive work rather than generic output. Partway through the conversation, the writer mentioned, almost in passing, “I’m basically writing a book every week.” Dailey’s next question was the one that mattered: “Is your audience reading a book every week?” [1]. The writer’s own answer was that they probably were not. This is Dailey relaying an interview he conducted, not a study or a named source, and the point of the anecdote is the mechanism it exposes rather than any statistic: a system tuned entirely for output volume can hit its own metric and still miss the thing that was supposed to matter. Software teams building with AI are running the identical pipeline. Pages get written and go unread. Code gets shipped and moves nothing.

Four symptoms you can check right now#

Dailey names four symptoms that show up first at the individual level and then compound once the whole team is experiencing them at once [1].

Too many PRs to merge. This is the first problem most engineers hit after adopting AI coding tools. Output outpaces review capacity almost immediately. At team scale it compounds into merge conflicts and a merge queue that stops draining, because every engineer’s agents are shipping in parallel.

This is the shape of a bottleneck we have already mapped from the individual engineer’s side: agentic coding removes the typing constraint and hands the workload to review, not to nothing [2]. Fiona Fung, Anthropic’s Director of Engineering for Claude Code and Claude Cowork, already reports living inside that exact constraint on her own team: “Verification, code review, and security took their place,” and “I don’t think I’ve seen a non-Claude-assisted commit in the last four months” [3]. Dailey’s talk is the team-dysfunction version of the same relocation, observed from a different vendor’s vantage point entirely.

Moving in too many directions at once. Individually, this is a handful of agents doing different things simultaneously until, in Dailey’s words, “your brain gets fried” [1]. Organizationally, it is engineers each picking up a thread and running with it, sometimes colliding with a teammate’s thread, without any cohesive sense of where the whole system is headed.

Declaring agent bankruptcy. A recurring pattern: an engineer runs a dozen agent terminals through a working session, steps away for the evening, and returns the next morning to accumulated state nobody recognizes anymore, “walking into just a room of strangers” [1]. The response is to discard the sessions and start over. The real cost is not the discarding itself. It is that the same work gets redone, meaning the team spends both time and tokens twice solving the same problem.

Critical decisions being made by agents. Dailey calls this the most important symptom, and his framing is direct: “if you as an engineer are letting an agent make a critical decision, you are seeding control of your code. You are no longer the owner of that code. The agent is” [1]. At company scale, engineers quietly ceding decision ownership means the organization no longer fully owns its own product.

KEY INSIGHT: A team that lets agents make its critical decisions has not become faster. It has quietly transferred ownership of the product to a system nobody is accountable for.

Figure 2 - The four-symptom self-diagnostic: Too many PRs to merge, moving in too many directions at once, declaring agent bankruptcy on stale sessions, and critical decisions being made by agents. A team can check itself against all four, and the fourth is the one that matters most.

Why the mismatch: tools built for the old shape of work#

Dailey traces the mismatch back to how software tooling actually evolved [1]. The pre-AI shape of engineering work was plan, then build and implement iteratively in relative isolation, then polish and ship. Every dominant coding tool, above all the IDE, was built to serve exactly that shape: heads-down, individual implementation.

AI changes the shape of the work itself, not just its speed. The new shape is plan, delegate implementation to an agent, then polish what comes back. Implementation is no longer the human’s job in the way it once was. What remains as human work are the two creative, collaborative stages that bookend it, planning and polish, and of the two, planning is where the mismatch is sharpest. Planning is inherently exploratory: understanding a complex system, applying a vague idea to it, expressing engineering taste about where the system should go next. The tools available for that work are still built for solo implementation, because they were designed before the work shape changed underneath them.

Dailey names the missing piece the decision layer, a layer of tooling for the planning and decision work, distinct from the implementation layer the IDE already serves well. “The skill now is what gear am I in? Am I using the appropriate tools for the gear I’m trying to accomplish right now” [1].

Figure 3 - The work shape changed, the tools did not: Before AI, engineers planned, then built and implemented iteratively, then polished. The IDE was built for that middle stage. After AI, implementation moves to an agent, leaving planning and polish as the two human stages, and the tooling gap sits squarely in planning.

The decision layer: docs instead of chat#

If the missing layer is for planning and decisions, Dailey’s next move is to name what a tool built for that layer would actually look like: a tool built for docs, not chat [1]. Chat sessions, he argues, are a relic of the implementation era. “The problem with chats is that they are the relic of building for implementation. So they’re default isolated and ephemeral and brain off” [1]. Working inside an isolated agent chat means decisions get made, whichever option to pick when the agent asks a clarifying question, what the actual goal even is, without the rest of the team ever seeing them, and those decisions disappear the moment the session ends.

The fix Dailey proposes borrows a pattern most engineering leads already know from managing people rather than agents: “if your team was having struggling [sic] with alignment, you would not tell them let’s go all work in Slack DMs… you’d say, let’s bring forward key decisions, align on them” [1]. A shared, durable document does for a team of engineers and agents what a shared planning doc has always done for a team of people: it surfaces the decisions that matter instead of burying them inside private conversations.

Dailey is careful to distinguish this from two things it is not. It is not plan mode, which is “a rich chat message… still in this isolated ephemeral environment” [1]. It is not full spec-driven development either, which operates at the product-behavior level and is “a little far away from the engineering reality” [1]. The target sits between the two: a durable, shared, long-lived planning artifact that stays close to actual technical decisions. Dailey frames the ideal version of this as “the portal to the software system, where you are like Tony Stark and you’re like, ‘Show me what matters’” [1], a tool an engineer actively queries for what is relevant to the work in front of them, rather than a document written once and handed off.

Dailey’s own company builds a product aimed squarely at this decision layer [1], and the pattern he describes does not require any specific vendor. A shared markdown file in an existing repo, a wiki page, any durable, multi-editor document carries the same properties that matter here: durable, shared, and legible outside any single agent’s session.

Figure 4 - The decision layer runs on docs, not chat: A chat session is isolated by default and disappears when it ends, so decisions made inside it never reach the rest of the team. A shared durable document surfaces the same decisions the way a team already resolves alignment problems, by bringing them forward instead of burying them in a DM.

Making agents stateless against the doc#

The structural flip underneath the decision layer is where state lives. In a long-lived chat session, context builds up implicitly over the conversation, useful, but private and non-transferable. Dailey’s proposal moves that state out of the session entirely: “we’re pulling out the state… you can spawn new agents that have the same context or starting from the same place… You’re ultimately doing context engineering in this doc, so that every agent is largely stateless and starts from this place” [1].

This directly resolves the third symptom. Declaring agent bankruptcy “is just not a thing because you’ve made your agent stateless. So, the result of their work is in the [doc]. If you need to rebuild your human context, you just read the doc” [1]. If the durable record of what mattered already lives in a document instead of a chat history, discarding a stale session costs nothing, because there was never anything irreplaceable inside it in the first place.

KEY INSIGHT: Once state lives in a shared document instead of a chat session, discarding a stale agent session costs nothing, because the record of what actually mattered was never inside the session to begin with.

Figure 5 - The agent becomes the action, the doc becomes the state: When a shared document holds all the state, new agent sessions can spawn from the same context and old ones can be discarded freely. Rebuilding human context means reading the doc, not reconstructing what happened inside a chat that already ended.

Two gears, not one continuous activity#

Dailey’s practical instruction is to treat planning and polish as two distinct gears rather than one undifferentiated activity [1]. Notice which gear a given moment of work is actually in, planning and deciding versus polishing what an agent already produced, and check whether the tool in hand is serving that gear. Treating both as the same activity is itself part of the failure mode, because a chat window that is excellent for polish is a poor fit for the collaborative, exploratory work planning actually requires, and a durable planning document that is excellent for surfacing decisions is the wrong tool for line-by-line polish of generated code.

Figure 6 - Planning and polish are different gears: Planning is collaborative, exploratory work that belongs in a shared durable document. Polish is close, line-by-line evaluation of what an agent produced, and belongs in a focused session with the agent. Drifting between the two inside one undifferentiated session is part of what causes velocity sickness.

How the fix maps to each symptom#

Run the decision layer back against the four symptoms and each one resolves for a structural reason, not a discipline reason [1].

• Too many PRs to merge: the review point moves earlier. Aligning on key decisions before implementation means code review no longer has to first work out what actually matters here, because that question was already answered in the shared document.
• Moving in too many directions: the team aligns on direction before anyone spends a day building a prototype down a given path, both individually, understanding a large task before spawning agents against it, and organizationally, since shared plans surface conflicting directions before they compound.
• Declaring agent bankruptcy: stops being a real cost, because the agent’s session state is disposable once the durable state lives in the doc rather than the chat history.
• Critical decisions made by agents: solved directly. The doc is where humans express engineering taste and own the decision. The agent fills in the implementation only after the decision is already made and recorded.

Figure 7 - Each symptom has a structural fix, not a discipline fix: Too many PRs resolves because review happens earlier. Moving in too many directions resolves because the team aligns before anyone builds. Agent bankruptcy resolves because state lives outside the session. Agent-made decisions resolve because the doc is where humans own the call.

The counter-intuitive signal: idea velocity over code velocity#

Teams that adopt this pattern report an unexpected early effect: people start planning ideas and then not implementing them. Dailey frames this as a genuinely good sign, not waste, because it means engineers are exploring an idea fully, deciding whether it is worth building, and only committing an agent to implementation once that judgment is made [1]. When planning is cheap and durable, a team can generate and discard many ideas before committing to the ones actually worth shipping. Dailey names this a shift from code velocity, how fast can a team ship code, to idea velocity, how fast can a team explore and select the ideas worth shipping [1].

The alternative he names is prototype gravity: building something, getting excited about shipping it, and following one path down the idea maze instead of exploring the whole maze for a better option waiting around the corner [1]. Velocity sickness, in this framing, is a team shipping too much code that is not going anywhere. The fix is not to ship less. It is to move the velocity upstream, into the judgment that decides which code is worth writing in the first place.

KEY INSIGHT: A team that plans many ideas and ships only the strongest few has not slowed down. It has moved velocity from code to the judgment that decides which code is worth writing.

Figure 8 - Idea velocity replaces code velocity as the metric that matters: Prototype gravity pulls a team down one narrow path the moment something ships. Idea velocity explores the whole maze first, plans several branches cheaply, and commits an agent to implementation only on the branch worth building.

Three actions to start this week#

Dailey closes with three concrete moves, none of which require adopting any specific product [1].

1. Treat planning and polish as two gears. Notice when a single session drifts from one into the other, and check whether the tool in hand still fits the gear the work is actually in.
2. Treat the plan as a portal, not a static handoff. Query it for what matters to the work in front of you right now, rather than writing it once and forgetting it exists once implementation starts.
3. Share the plan with a teammate before an agent touches it. Dailey calls this “very unnatural for a lot of people,” and true anyway: “You have smart teammates. They have great context in their heads. You should tap into that” [1]. His closing framing extends the same idea to the whole discipline: “I think the future of engineering is multiplayer” [1].

The individual side of this same discipline, an engineer’s obligation to still own every decision a solo agent makes rather than trust it by default, deserves its own separate treatment. This piece stays at the team level, where the failure mode Dailey names actually compounds.

Figure 9 - Three moves that need no new tool: Notice which gear a session is in, treat the plan as something you actively query rather than write once, and share it with a teammate before an agent implements it. None of the three requires buying anything.

Conclusion#

Velocity sickness names a real and specific gap: individual output rising fast enough to feel great, and team-level impact not rising to match it. Dailey’s four symptoms, too many PRs, too many directions, agent bankruptcy, and agents making decisions that belong to engineers, give a team a way to check itself against the condition [1]. His diagnosis is structural rather than a call for more discipline: the tools most engineering teams still reach for were built for a shape of work AI has already replaced, and the planning stage that remains genuinely human has no dedicated layer of its own.

The fix does not require a new platform. It requires moving planning out of ephemeral chat and into a shared, durable document that the whole team reads and edits, making agent sessions stateless against that document, and treating planning and polish as two distinct gears rather than one blurred activity. The payoff shows up first as a counter-intuitive signal: plans that get explored and then discarded, which is idea velocity doing its job, not a team losing momentum. For a team that recognizes even two of the four symptoms, the honest next step is an audit of where the current workflow is producing output instead of impact, and installing the decision layer that closes the gap.

References#

[1] M. Dailey, “Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster,” AI Engineer, YouTube, Aug 2026. https://www.youtube.com/watch?v=Kz4QJmNrVXU

[2] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Orchestration Tax: Why Loop Engineering Has a Human Ceiling, Not a Token One,” 2026. /insights/claude-code-17-orchestration-tax/

[3] F. Fung, “Running an AI-native engineering org,” Anthropic, Jun 2026. https://claude.com/blog/running-an-ai-native-engineering-org