Velocity Sickness: When AI Makes Teams Too Fast

There's a newsletter writer Matt Dailey met who built an agentic pipeline impressive enough to preserve their actual voice—not flatten it into the usual AI-smoothed mush. The writer walked him through the whole system: research ingestion, idea synthesis, editorial passes. Genuinely sophisticated. Dailey was impressed. Then the writer mentioned they were now producing, effectively, a book a week.

Dailey asked the obvious question: was their audience reading a book a week?

They were not.

That gap—output without uptake, velocity without destination—is what Dailey, CEO and founder of the engineering tool Ref, calls velocity sickness. He laid out the concept at a recent AI Engineer conference, and the framing is worth sitting with, because it names something that's been fuzzy in most conversations about AI and developer productivity.

The Pathology

Velocity sickness isn't a performance problem. The output numbers look great. Code is shipping. Commits are landing. Agents are humming. The sickness is a coordination problem wearing a productivity costume.

Dailey maps it across four symptoms. The first is the PR flood: individual engineers discover AI can 10x their commit rate, push a week's worth of pull requests by Tuesday, and watch the merge queue collapse under the weight. The second symptom is directional fragmentation—agents running tasks in parallel while the humans steering them have stopped talking to each other, resulting in engineers "bumping into each other" across a codebase nobody has a unified view of.

The third symptom has the best name: agent bankruptcy. Dailey describes the pattern with precision: "You're cranking. You have like your 12 terminals open. At the end of the day you're like, 'Yeah, I did a lot of work.' You step away from your laptop. Next morning you come back and it's like walking into just a room of strangers."

The agents get deleted. The work gets redone. Tokens spent twice on the same problems.

The fourth symptom is the one that worries him most: critical decisions getting made by agents while engineers are heads-down implementing. "If you as an engineer are letting an agent make a critical decision, you are ceding control of your code. You are no longer the owner of that code. The agent is." Scale that across a team, and you no longer own the product.

This isn't a hypothetical risk. It's an ambient pressure built into how AI coding tools are currently designed. The path of least resistance—accepting the agent's "recommended option" and hitting enter—is also the path toward a codebase that reflects the agent's implicit choices more than the engineer's explicit ones. Research tracking developer skills trade-offs suggests this erosion can happen gradually enough that teams don't notice until the decisions have already been made for them.

The Structural Problem Is the Chat Window

Dailey's diagnosis points at something specific: the chat interface is the wrong primitive for decision-making, and it's become the default environment for work that requires exactly that.

"Chats are isolated, ephemeral, and brain-off," he says. "They're made to build things and get stuff done." That's fine when you want implementation. It's a liability when you're doing the upstream work of figuring out what to build and why. Decisions made in a chat session—which direction to take an API, how to model a data structure, what to deprioritize—exist only as long as the session does. The code survives. The reasoning doesn't.

This produces a particular kind of fragility: a codebase whose present state can be reconstructed from git, but whose decision history lives nowhere legible. Which is basically the situation most teams were already in before AI, just arriving faster and at higher volume.

The human-in-the-loop problem isn't just about catching bugs. It's about catching architectural choices—the kind that shape everything downstream—before they get baked into the implementation.

The Fix: State Lives in the Doc, Not the Session

Dailey's proposed solution is conceptually simple, which is either a point in its favor or a reason to be skeptical, depending on how many "conceptually simple" solutions you've watched fail in practice.

The core idea: separate the decision layer from the implementation layer. Give the decision layer a durable artifact—a document, not a chat—that holds state explicitly rather than letting it accumulate implicitly inside an agent session.

"What you want is to separate the agent as the action and the doc as the state," he explains. That separation does a few things. It makes agents effectively stateless—any new agent can spin up from the same document and arrive at the same starting context, rather than inheriting a tangle of prior conversation. It makes the decision history auditable and shareable. And it means that when you return to a project after a day away, rebuilding your understanding is a matter of reading a file rather than interrogating a confused agent about what it did yesterday.

He's careful to distinguish this from "plan mode" in tools like Claude or Cursor, which he describes as "largely a rich chat message"—better visualization, but still siloed and ephemeral. He's also distinguishing it from fully specced-out requirements documents that operate at the product level and lose the engineering texture. The target is something in between: a living technical document that a human can read, edit, and hand to a teammate.

The Counterintuitive Success Metric

Here's the thing Dailey says that's actually interesting: the sign that this approach is working is that engineers start writing plans they never implement.

That sounds like failure. It's actually prioritization.

When the plan is the thing you invest in first—when you're forced to think an idea through to the point of documentation before spinning up agents to build it—you discover faster which ideas are worth building at all. "You're shifting from code velocity to idea velocity," Dailey says. "Rather than getting stuck in prototype gravity where you build something and you're so excited to ship that thing... you can now more effectively explore that whole maze and find the gold that's around the corner."

Prototype gravity is a real phenomenon. The moment something runs, it accumulates momentum—time invested, ego invested, the narrative that this is the thing now. Front-loading the thinking, and doing that thinking in a shared document, moves the selection process upstream of that momentum. Some ideas don't survive contact with explicit articulation. That's useful information, and it's cheaper to discover before the agents have spent three days building.

This connects to something structural about AI-assisted development: the tooling that accelerates implementation doesn't automatically improve judgment about what to implement. That judgment still requires deliberate human process. You have to build the process yourself, because the tools aren't going to constrain you toward it.

What This Doesn't Resolve

Dailey is, to be clear, selling something. Ref is a tool built for this decision layer he's describing, and the talk is happening at a conference where that's the context. That doesn't make the diagnosis wrong—vendor talks can identify real problems—but it's worth noting that the solution he's proposing conveniently requires the category of tool his company makes.

There's also an organizational question his framework doesn't fully answer: who maintains the document? In teams under shipping pressure, shared docs have a well-documented lifecycle: created with good intentions, updated for the first sprint, quietly abandoned when urgency rises. The discipline required to keep a decision document current is the same discipline that makes standups and postmortems useful when done well and theater when done poorly. Dailey treats the document as the structural fix, but the document is only as good as the team's commitment to it.

And there's a harder version of the problem lurking beneath the surface. Dailey focuses on decisions made inside individual agent sessions—the micro-choices that shape a feature. But the same dynamic operates at larger scales: product direction decisions made in Slack threads, architectural decisions made in rushed code reviews, strategy decisions made in meetings with no durable record. AI-accelerated code review can move PRs through faster, but speed at the review stage doesn't fix decisions that were wrong before the code was written.

His three immediate recommendations are concrete: recognize which gear you're in (planning vs. implementation), treat the plan as a live portal to the system rather than a one-time prompt, and—the one he says feels most unnatural—share your plan with a teammate before you hand it to an agent. That last one is interesting precisely because of the resistance it anticipates. Engineers have always had a reflex toward solo building; AI makes that reflex cheaper to indulge and more expensive to recover from.

The newsletter writer producing a book a week nobody reads is an uncomfortable mirror. It's possible to be genuinely skilled, genuinely productive, and still be building in a direction that doesn't connect with anything that matters. Velocity sickness isn't a failure of effort. It might be a failure of asking, early enough and out loud, whether any of this is the right thing to build.

---

Marcus Chen-Ramirez covers AI, software development, and the intersection of technology and society for Buzzrag.