"We're accumulating code faster than we are accumulating trust."
Kent Beck lands that line like a diagnosis. Software is bipedal. Code and trust have to move together, and one without the other just hops along awkwardly until it falls over.
Trust is as tricky as code, and in one way it's worse. Code works or it doesn't. A single mistake buried in a long string of good decisions is still just a mistake. But trust accumulates slowly and evaporates in an instant. The asymmetry is the whole problem: in software you can often repair a mistake in time roughly proportional to how long it took to make. Trust offers no such deal. Once it's gone, getting it back is hard, sometimes impossible.
Here's the claim worth sitting with. Extreme Programming gave teams faster functionality than they were used to, yet it never carried the trust deficit you see among today's AI-tooling pioneers. Beck says he never framed it this way before, but XP manufactured trust. The practices were the assembly line. The headline was always velocity, which is exactly why the real product went unnoticed.
How? Run it from practices to principles to values.
Each practice that built trust also built trustworthiness
Beck is walking through XP Classic here, not the unsettled XPAI variant people are starting to argue about. Daily work is where trust gets built:
- Programmer testing. Thorough automated tests show the rest of the team you're trustworthy. They also build the programmer's confidence in their own work.
- Pairing. It builds trust between two programmers directly. Fewer defects and better structure carry that trust outward to everyone else.
- Continuous integration. Small changesets optimized for safety cut the gotcha moments.
- Weekly planning. Concrete progress, honestly reported, hiccups included, builds trust with the people depending on you.
- Customer on the team. Domain questions, clarifications, alternatives offered in passing. The little daily interactions add up.
- Continuous deployment. Knowing your code runs correctly in production builds your own confidence. Knowing everyone operates under the same constraint builds confidence in each other. Customers watching small changes ship almost instantly build trust at the product level.
- Refactoring. When better structure reduces defects or future effort, it earns trust.
- Observability. Knowing you'll be paged for malfunctions builds trust, and the skin in the game pushes the prudence that prevents them.
Beck flags a pattern across that list he didn't expect. Each practice that creates trust also encourages trustworthiness. Know you'll get paged at night and you'll do the work to make that page less likely. Know you'll be writing tests and you'll make tests easier to write. The two feed each other.
The principles work the same way, one level up. Humanity: admitting everyone has needs pushes people to be honest about them. Mutual benefit: win/win lets everyone relax and stop grabbing for more than their share. Improvement: accepting that today isn't perfect, but beats yesterday, gives people permission to trust through the gaps. Flow: frequent concrete progress holds trust even when the pace disappoints. Redundancy: solving hard problems several ways means no single failure torches the whole relationship.
Values are the vaguest layer and carry the most purpose. Communication means saying what needs saying in a way that can actually be received. Feedback means knowing you'll be listened to, which encourages honesty on the hard topics. Courage is acting from purpose despite fear. Respect is, in Beck's words, obvious. He's gone iffy on simplicity as a value, since successful systems always end up complicated, but pieces that are easy to describe still build trust.
Same dynamic at every level. Creating trust creates the conditions for creating more of it.
Vibe coding strips out the loop XP depended on
Software development that values trust as much as features has always been rare. It's getting rarer fast. The shift toward individuals working alone with the genie, what Beck calls the single player problem, produces a specific kind of trust deficit:
- Genies care about satisfying prompts, not purposes. Generated software often misbehaves in the least unusual circumstances. "This works" followed by "oh no, it doesn't" erodes trust on every cycle.
- Single player development kills off most of the small daily chances to build trust between people.
- Purely reactive project management, the natural mode on the feature hamster wheel, risks tactical progress alongside strategic failure.
- The genie ignores optionality and future change. Walking off the end of the productivity pier is a big trust breaker.
The mismatch between how fast code stacks up and how slowly trust does is unstable. Unsustainable, even. When it corrects, Beck warns, it's going to be painful.
You can't control a system you're standing inside
Beck cops to a line he's used before: "the program is the truth." At one level that holds. Whatever we think the system does, what it actually does is what it actually does.
But as Jessica Kerr points out, a software system is a symmathesy, a human-technical system. We're inside it. We can't avoid affecting it, and we can only influence it, never fully control it. That reframing changes what good development should optimize for, because the people in the system are as much its output as the code.
Going slower is how you go faster
The prescription is counterintuitive. Slow down.
- Slow down so the damn stuff actually works.
- Slow down to fold in structural improvements that expand future options.
- Slow down to make room for frequent person-to-person interaction.
- Slow down to reinforce and update long-term purpose.
That's the path to going faster. More chances to build trust, more focus on trustworthiness, more trust. Trust isn't all that matters. But trustworthy behavior producing trustworthy software producing trust is the route to augmented development that actually compounds. Speed alone just hops awkwardly, until it doesn't.
