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

[upbeat music] Thank you so much for coming later in the week here.

Uh, I'm Matt. I'm the CEO and founder of Ref. 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, and we're working to help close that gap.

What I'm gonna be talking about today is that... is what happens when your whole team gets ten times faster, all the things that don't go well.

And my goal is to give you a blueprint for how to get, get through those issues, uh, and have the t- whole team move faster together.

The way I wanna accomplish that is first

talk about those issues, define some terms. Then we'll talk about how did we get here? Where are we at now? Um, and we'll use that to triangulate on some solutions.

We'll start high level, and we'll work down and get more and more practical until we leave with a couple of things you can leave here and do immediately. Um, how's that sound?

I mean, thumbs up? All right, awesome. Great. That was great. Uh, all right, so let's get into it.

These are some of the problems you might be experiencing right now. Uh, these are te-- these are problems that affect individuals and are actually magnified at the team level once the entire team starts experiencing them.

So the first one, too many PRs to merge. This is the, like, classic first problem you hit when you start adopting AI as an engineer. You're like, "Great, I'm shipping stuff," and you push up those PRs and you're like, "There's no way I can merge all these."

Uh, and this is obviously magnified when the whole team does this. Merge conflicts, merge queue breaks down, things get bad.

The second problem is that you're moving in too many directions at once. This is also both individual and a team problem. Individually, this is where you have a bunch of agents doing different things.

You're trying to remember who's doing what, uh, and your brain gets fried.

At the organizational level, this is your engineers picking up things and running in a certain direction. Another engineer's running over here. Uh, maybe some are bumping into each other, and you're, you're not moving cohesively with focus because you're just sprinting in all sorts of directions.

Uh, the third problem you might be experiencing is declaring agent bankruptcy. This is a, a common pattern I see engineers get into where, you know, you're cranking, you have like your twelve terminals open.

You're like-- At the end of the day, you're like, "Yeah, I did a lot of work." You step away from your laptop, uh, spend time with your friends and family.

Next morning, you come back, and it's like walking into just a room of strangers. Like, who are these people? What are they doing here? But like, no problem. They're agents, so you just, like, get rid of them and start over again.

The problem, though, is, you know, you... it feels like you're doing a lot of work, but you're doing the same work, uh, and you're spending tokens twice. You're doing the same problems over, over again.

Um, and if you think about that organizationally, that's your team not being efficient with both their time and their, their token resources. Uh, problem four, though, is actually the most important one.

It's critical decisions being made by agents. Once you have agents doing a lot of your work, if, if you as an engineer are letting an agent make a critical decision, you are ceding control of your code.

You, you are no longer the owner of that code, the agent is. Uh, and if you imagine that at scale at your company, if the engineers across your team are, you know, giving up ownership of the code, you no longer own the product.

Um, these are a bunch of problems you might be experiencing at different degrees at different days. Uh, the way I like to bundle it up is into this term velocity sickness.

This is, uh, the stress caused by sudden output increases thanks to AI. Um, it affects individuals or teams, um, and the result is output without impact. So this is that feeling of like, we're moving really fast.

This should feel great. This should feel awesome, but for some reason, it doesn't feel awesome. We're not having the like-- The things you expect to be happening are not happening, um, despite this feeling of being so productive.

Uh, so that's to define that term. But I wanna tell a, a little story. Uh, [laughs] my talk is happening now. Uh,

I want to tell a little story about somebody-- like, to make this very real. Um, [laughs]

this is a story about somebody, uh, who's actually not an engineer, but I think it parallels our engineering workflows a lot. I-- Part of my job is I get to go find and talk to people who are really pushing the forefront and try and learn from them, and I love that part of it.

And so this is somebody, and I'm, I'm talking through their agentic workflows. Um, and it's somebody who writes a newsletter, and their workflow is around how do I-- I have my ideas, and then they're doing research and exploration and then, uh, like, cohesion between those ideas and editorial to make sure it's in their voice.

And they're, they're walking me through their system for how they, they manage this whole pipeline, um, and really scale out their, their efficacy. And this is, like, very, very much not slop.

This is somebody who is, is using agents to amplify their own voice, uh, in a way that's, like, very impressive. I'm like, wow, that's-- that is so cool. I'm, I'm like-- I'm soaking it in.

Uh, and then they're like: Yeah, I'm basically writing a book every week. I'm like: Oh, okay. Is, like, is your audience reading a book every week? And they're like: No, they're probably not, right?

They're not. They're, they're-- This is a person who's writing a lot, but those pages that they're writing are going unread. Um, and I think that's part of this experience of velocity sickness is we're, we're building things that are not mattering for the people we want them to matter for, the people we're trying to reach.

Uh, so what we-- Instead of unread pages-

Um, what we want is we wanna write words that matter. We wanna write words that connect with people. Um, and the parallel to us as, like, software builders and product builders is that we wanna write-- we wanna build products that connect with people.

We want, we wanna build products that change the way people live and work and make their lives better. And we have more ability to do that than ever with AI.

But we have this, like, feeling of velocity sickness where we're-- it feels like we should be doing that, but it's not quite landing.

So let's talk about how we got here.

Um, this is what the software engineering process used to look like before AI. We'd do some planning up front. We'd sit down and build, we'd implement. It, it'd be iterative, we'd be exploring, but largely we're sitting down building in isolation, implementing something, and at the end we'd sort of polish it up and ship it out the door.

And this was great. We all knew how to do this. We had a lot of systems for this, uh, and it was good. And then AI came along. Um, but at this time our, our tools were built for this.

Like all, all, all our history of coding tools were built for this style of work. Um, our IDE, our workhorse, um, it was built for implementation and polish to be done by an individual, to be heads down building as a software engineer writing code.

Um, and that's what-- That's a tool built for how we used to work.

Um, so let's look at how, how we work now. Our work looks a lot more like this, where you do some planning up front and you start thinking about w-what am I trying to do here?

You take this idea in your head and start to flesh it out. Um, at some point, an agent takes that idea and, like, implements it. This is like arguably should not even be on this slide 'cause it's not our human work anymore.

It's done by the agent. Um, and then in the end, we do some polishing where we take back that thing the agent has made for us, and we, like, hold it in our hands and we say, "Is this, is this what I wanted?"

Um, this is a very different shape of work, right? We're no longer doing this, like, heads down building. These are the two, uh, creative and collaborative parts of our work as engineers.

This is where we, like, express our craft as an engineer, and the one that's most different is the, the planning stage. So I wanna zoom in on that just a little bit.

Uh, that's the, like, exploratory, creative, collaborative part where we're, we're thinking about, like, I have this vague idea. I have this complex system. I need to understand the contours of this system, apply this idea and, like, really understand it.

And I need to pull out w-what's relevant and express my taste as an engineer as to, like, where do I want this system to go? Um, this is the kind of work that, uh, that's creative and, and needs to be done together.

I think the, the shape of engineering teams and product teams is changing with AI, but we're always gonna have this thing where we have a group of people responsible for managing a complex system and sort of deciding the future of that system, and that's this planning work.

And so we're, we're starting to see some of the hints of, like, okay, we had tools built for a certain type of work. Our work looks different now. Um, let's start to see-- think about that a little bit more.

So our-- We used to have the IDE. That's our main tool. It was used for implementation. But now we're doing this different kind of work. So at the very high level, we can start to think about solutions like, okay, we have a tool built for this type of work.

We have a new type of work. Let's think about, you know, what this new layer of our work is. This, this is the decision layer. This is where we're thinking through what are the key decisions, doing that, like, craft of engineering, um, and expressing our taste as engineers.

Uh, ultimately a different thing than implementation. Um, and it, it's a different gear as an engineer. It's, uh, the skill now is what gear am I in? Am I using the appropriate tools for the gear that I'm-- that what I'm trying to accomplish right now?

Um, so let's think about what a tool built for the decision layer would look like. Um, it'd be a tool built for docs and not chat. And there's-- that's, like, a short sentence.

There's a lot to unpack here though, uh, so I'm gonna spend a lot of time on this slide. Uh, the problem with chats

is that they are the relic of building for implementation. So they're, they're default isolated and ephemeral and, and brain off. Uh, they're, they're made to build things and get stuff done, and that's not really the same type of work we're doing at the decision layer.

We're doing this creative exploratory work. So being in this isolated environment where I'm working with an agent, uh, maybe I start with my vague idea and I'm exploring it and asking questions, but decisions are being made in that envi-- like, that chat that are, are not shared with my team, uh, that are gonna disappear as, as long--

I'm gonna result in some code being output where those important decisions are not being made clear and shared with the team. And you're also in this mode where the agent's saying,

"Okay, this is what I wanna do. Is, is that okay? Let's go." Or, or sometimes it'll say-- it'll ask you a question, and it'll be like, you know, "This is the recommended option."

And then you're like, "Great, I don't need to think about this. I'll just hit that one," and we keep going.

Uh, docs start to solve this problem. So when you're-- If you center your work around working in docs,

they're meant to be bring forward the key decisions. This is, this is what our work is now. Our work now is figure out what decisions matter and then make those decisions, and then get out of the way while the agents fill in the rest.

Um, working in docs is the, the classic way we would create alignment. Um, is it-- If you, if you think back to being a manager or a, a lead on a team before AI, if your team was having s-- struggling with alignment, you would not tell them, like, "Let's go all work in Slack DMs.

Let's, like, go direct message each other." You'd say, "Let's, like, bring forward key decisions, align on them, spend time on these. Like, find a way that we can really spend time getting our decisions right."

Um, so w-- There are two things you might be thinking looking at this that are not what I'm talking about here. The first one is plan mode. Um, that's a great tool.

The other one is, like, full-on factory spectrum and development. That's a great tool too. I'm talking about something in the middle.

Uh, plan mode is great, but it's largely a, uh, a rich chat message where the agent is saying, "Hey, here's a, like, better visualization of what I'm trying to express to you."

Yeah, that's great. But it's still in this isolated, ephemeral environment. And what I'm suggesting is something more, more durable, more shared, more long-lived that you and your team are spending time on.

Um, similarly, the spectrum and development where we just define the behaviors, we operate at the, like, product level, is a little far away from the engineering reality. The engineering reality is that I need to understand my system and have a tool that, like, helps me understand that system and lay out those key decisions in a, in a

technical sense. Um, the way I like to conceptualize this is as the portal to the software system, where you are like Tony Stark and you're like, "Show me what matters."

And you're like, "I'm working on this. Pull out the bits that are relevant." And AI is amazing at finding things that are related to other things, helping you find what's, what's relevant, and lay them out on the table in front of you.

Organize the pieces in the way you want to represent how you want the system to grow.

Um, but the big conceptual flip here is actually that we're pulling out the state. So when you're living and working in a, a long-lived session with an agent, there's this implicit context being built up, like, over that work, and that's great.

Um, but there's... You're also doing actions, and it's, it's not shared. What you want is to separate the, the agent as the action and the doc as the state.

And so you can spawn new agents that have the same context, that are starting from the same place, that are able to collaborate and work on the same, same piece of context and state.

You're ultimately doing context engineering in this doc so that every agent is largely stateless and starts from this place, um, the same place. And what that gives you is your team and yourself can look into this and understand what actually is in here, what are the decisions that are being made, um, and have a, a clear understanding

of what the key decisions are. So this is a, a different way of working, where your, your core atom of your work is a doc rather than a chat.

Um, what happens when you actually start to implement this?

Well, the first thing we see happen, actually, is that people start to plan and then not implement their plan. Um, and this is actually, like, a really good sign.

Because what that means is they're thinking through ideas. They're saying, "I have this idea. Let me explore it. Let me start to flesh it out. Like, I have this vague thought.

Don't just give me some code. Don't go off and, like, build it for me. But let me help-- help me understand the idea that I'm talking about." Um,

and then they have a bunch of these, and then some of them are getting built, and some of them aren't. So that means they're prioritizing the ideas that, after they've explored them,

are the ones that are worth building and, and going into the, to the next step with. Um, one way I like to frame this is that you're, you're shifting from code velocity to idea velocity.

So going back to our, our problem statement, like, how are we dealing with velocity sickness? The velocity sickness is we're shipping too much code that's not going anywhere. The solution is to shift that velocity to ideas so that rather than, you know, getting stuck in prototype gravity, where we, we build something and we're so excited to ship

that thing and we're going down, like, one path of the idea maze,

we can now, like, more, more effectively explore that whole maze and find that gold that's around the corner, um, and, and really impact the people we're trying to help.

Um, so let's go back. Here are those problems, those velocity sickness problems I talked about at the beginning. Let's see how this starts to address those.

First, too many PRs. We've moved the, the review point earlier into the process, so we're aligning on the key decisions up front. That means the code review's easier because the hardest part of any code review is, you know, what actually matters here?

That's the first step is like, "Well, what do I care about here?" If you move that earlier, we've aligned on that, the code review becomes much simpler.

Number two, moving in too many directions. Again, we're aligning early. As a team and individually, I'm, like, understanding what I'm working on across many agents. If I'm working on a large thing, I've, I've understood it initially.

So as a team, we're sharing these plans, and we're aligning. This is what we're trying to build, and it's easy. Before someone has spent even a day in AI going deep on some idea building a prototype, w- we can talk about it early and make sure we're aligned on where are we actually taking this system.

Um, declaring agent bankruptcy is just not a thing because you've made your agent stateless, so the result of their work is in this doc. If you need to rebuild your human context, you just read the doc.

Now you understand the state of this project, and you can pick up from there.

And the most important one, humans own the decisions. Like, that's what we're solving for. Humans need to own the decisions. That's how we retain ownership of our software and our product

and make it, like, a, a true expression of what we're trying to create in the world.

There are also some other benefits. So when you have this state extracted and you're working from a shared context, you get more parallel agents. It's easier to work with parallel agents.

Uh, you get this durable decision log. So something, uh, that's really powerful, I think a lot of people are thinking about how do we capture all the decisions going into these sessions?

A really s- great solution to that is let's pull out all the decisions up front and agree to them and put them in a place that's durable so that we don't have to have, like, some LLM summarizing it and maybe picking the wrong things later on.

We wanna bring that forward so we can save it and refer to it later. Um, and then, uh, my favorite one, um, is actually more collaboration. Like, this process, we want-- We're doing more work that is creative.

Which means we should be collaborating more as engineers. I think the future of engineering is multiplayer. It's gonna be multip- multiplayer by default sooner than we think. Um, and it's more important than ever because we're in this moment with AI where everything's moving faster than ever.

There's a pressure... Like, everyone's company feels existential, small or big. You need to deliver. And the way we get through that as humans is by working together, and we need tools that help us do that.

So here are three concrete things you can leave this room and do right now. The first one is to think of your work in terms of planning and polish.

So recognizing that there are two gears I'm working in. There's no longer this one focus of implementation. There's, uh, plan and then polish. Um, and notice when you're in a single session, and you're doing both of these in one session.

Notice when you drift from the planning phase into the polish phase, and is your tool serving you for what you're trying to do at that moment?

Uh, number two is to start to treat your plan as a portal to the software system. So really treating it as this powerful, malleable tool to say, like, what matters to, to me for what I'm working on right now, um, and asking it to show that to you so that you can make the best decisions possible.

And number three is share a plan. Like, don't just, you know, write the plan, give it to your agent, have them implement it. Give it to someone on your team.

This is, like, I feel like very unnatural for a lot of people. We always... We, we think we know what's going on, but it's always valuable. You have smart teammates.

They have great context in their heads. You should tap into that. They will give you good feedback. Uh, it's a really valuable thing to do. That's my talk. I'm Matt.

Um, I'm the CEO of Ref. If you want to talk about any of this stuff, this has all my, like, connection information. Ref is a tool built for the decision layer.

Uh, we work with all of your existing implementation tools. Um, if you want to see a demo, come... You can come by our booth or just see me out there, uh, and I'd love to talk about this stuff, so come say hi.

Thanks. [audience applauding] [upbeat music]