Ref CEO on AI Velocity: "Output Without Impact"

Matt Dailey, CEO and founder of Ref, addressed the common challenges teams face when integrating AI at the AI Engineer World's Fair. He highlighted the paradox where individual engineers are moving at an unprecedented pace with AI tools, yet the collective team velocity is not keeping up. Dailey coined the term "velocity sickness" to describe the stress caused by these sudden output increases, which often result in "output without impact."

The Four Pillars of Velocity Sickness

Dailey outlined four key problems stemming from the rapid adoption of AI:

• Too many PRs to merge: Engineers are shipping features at a faster rate, leading to an unmanageable volume of pull requests, merge conflicts, and breakdowns in the merge queue.
• Moving in too many directions: Individually, engineers might find themselves managing multiple AI agents performing different tasks, leading to cognitive overload. Organizationally, this translates to teams and individuals pulling in disparate directions, hindering cohesive progress.
• Declaring agent bankruptcy: Engineers often find themselves overwhelmed by numerous open terminals and agents, leading to a pattern of abandoning these agents and starting over, resulting in duplicated effort and wasted resources.
• Critical decisions being made by agents: When engineers allow AI agents to make critical decisions, they risk ceding control of their codebase and, ultimately, ownership of the product.

These issues collectively contribute to "velocity sickness," characterized by high perceived productivity that doesn't translate into meaningful impact.

From Implementation to Decision-Making

The traditional software engineering process, Dailey explained, was built around planning, implementation, and polish, with tools like IDEs supporting individual, heads-down work. However, AI has fundamentally changed the workflow. The process now involves planning, agent-driven implementation, and human-led polishing. Dailey emphasized that the critical shift is in the planning stage, which is becoming more exploratory, creative, and collaborative.

He proposed that the future of engineering tools should focus on the "decision layer," moving beyond simple chat interfaces. "Tools should be built for docs, not chat," Dailey stated, explaining that chat interfaces are often isolated and ephemeral. In contrast, working within documents allows for key decisions to be brought forward, made clear, and shared with the team, fostering alignment.

Dailey drew a parallel to pre-AI management practices, where addressing team alignment issues involved bringing forward and spending time on key decisions. He advocated for a similar approach with AI, suggesting a need for more durable, shared, and long-lived tools that facilitate collaborative decision-making.

Shifting to Idea Velocity

The core solution proposed by Dailey is a shift from "code velocity" to "idea velocity." By focusing on thoroughly planning and vetting ideas before implementation, teams can avoid the pitfalls of "prototype gravity" and ensure they are building impactful solutions. This approach allows for more comprehensive exploration of ideas, ultimately leading to better outcomes and more meaningful impact for users.

Dailey outlined three actionable steps for teams to combat velocity sickness:

1. Think plan then polish: Recognize the distinct gears of planning and polishing in the AI-assisted workflow and assess if current tools adequately support each phase.
2. Treat plans as portals: View plans as powerful, malleable tools that provide access to the software system, enabling engineers to understand and make informed decisions about the system's future.
3. Share a plan: Actively share plans with teammates to leverage their diverse perspectives and feedback, fostering collaboration and ensuring alignment early in the process.

Ref, as a company, is building tools to support this "decision layer," working with existing implementation tools to help teams navigate the complexities of AI-driven development and achieve true team-wide velocity.