Xtreme Vibing

Speakable draft, 2026-10-05.

There are two ways to drive. The commute is the road you have taken for five years. You can listen to a podcast, answer a message about who is picking up your son for his piano lesson, and think about the meeting you are walking into. The road is familiar. The attention is borrowed. The oval is the other drive. A pack of cars, two hundred miles an hour, a concrete wall if the attention slips. You are going fast, so the discipline has to be complete. If you are too tired, you pull over. If a teammate is not fit to drive, you take the keys. The oval is not a stunt, and it is not an invitation to a pace no person can sustain. The oval is the new drive. Faster than the commute. Still a human pace.

Xtreme Vibing (XV) is how we make that drive fast and keep it safe. Agents write the code. People rank the work, keep the one-page pitch for what the system is, sit with users, and decide the shape of the system. Some of the discipline is enforced by agents and the pipeline. The rest is owned by people. Two principles say how a person decides: two people over the same evidence, written down and binding, or one accountable person, from judgment informed by data. Three more hold them in place. Go and see: the evidence comes from real use. Ship at will: the harness sets the conditions and the person picks the moment. Own the result: a person is responsible for every change, even one made entirely by agents. The team trusts each other and the system they use to build the system. The people who fund the software trust the team with the product. Trust is earned, and speed needs it.

XV updates the disciplines described in Extreme Programming (XP) to reflect nearly three decades of new experience and the change agents bring. Vibe coding feels safe at commuter speed. It is only safe because the speed is held down or the stakes are low. Xtreme Vibing is what we need on the oval. The twelve XP practices were controls for uncertainty, change cost, and coordination. Uncertainty and coordination remain. Change cost is lower than it has ever been. In its place is change risk: the data, security, usability, functionality, and regression risks that come from speed without discipline. The XV practices are controls for uncertainty, change risk, and coordination.

Who we serve, and why

We exist to serve the people who use the software, and we know who they are. The mission says why we are here. The vision says what the solution is becoming. Both exist before the work starts. The team is responsible for knowing them. They tell us which work is worth taking, and what a change is allowed to do to the product. The business's goals enter there and stop there. The business does not decide details.

We build for users. Value is the experience of the user. It is the whole team's responsibility. Anyone who takes the next task is expected to know who it is for, and to refuse work that is not for the good of the user.

A stakeholder is not a user. The product owner Scrum created is one user, at best. More often it is a proxy, and the proxy lets the team say customer value is not their job. Sitting with the stakeholder is not sitting with the users. Often sitting with the product owner is not either.

The return on investment for the shareholders was set by the people who funded the software, before this team existed. It does not affect the ranking of work. We follow Denning's Law of the Customer and focus on creating value for the customers of the software - its users. With Xtreme Vibing we build software with discipline; not only in how we do it, but in why we do it.

We keep a current understanding of those users, of what the system is right now, and of ideas for how it can better represent the vision. Yesterday's change is part of today's shared operating picture. It is written down, enough for a new person or an agent to find their footing, without repeating the code. While agents build, that understanding is the team's lasting value.

We decide from evidence of real use, not from what we expect. A decision about what the user experiences is void without a recent session with users or evidence gathered from real use. Prototypes are run and compared, not argued. The process itself is a hypothesis: we start with the best we know and refine it as we work.

Work tends to come in bursts. Before a burst we rethink the shape of the system, and as it ends we ask what the burst left behind. Between bursts we are with users, because nobody knows what they want until they have used it. Once a change is in production nobody stands watching it. When it raises its hand, the person who set the work going answers first.

How we serve

XP offered values and twelve practices. XV uses them as one source of inspiration. Read more in the map.