Trust Factory

“We’re accumulating code faster than we are accumulating trust.” Sometimes a phrase just hits. Yes, we can create code faster now, but software is bipedal—code & trust go together. One without the other just hops along awkwardly.

Trust is as tricky as code. Both are asymmetrical. Code works or it doesn’t. One mistake in a long string of good decisions is the same as just a mistake. Trust accumulates slowly & evaporates in an instant. The difference is that in software sometimes you can repair the mistake in time proportional to the time it took to make the mistake. Trust is irreversible. Once gone it’s hard-to-impossible to get it back.

XP offered faster accumulation of functionality than folks were used to, but it didn’t suffer from the lack of trust we see among genie pioneers. I never thought of it this way before but XP manufactured trust. But how? What is a trust factory? We’ll go from practices to principles to values.

Practices

I’m going to go through XP Classic here, not that newfangled XPAI that folks are talking about, since the new set of practices is not yet settled.

Practices build trust:

• Programmer testing. Thorough automated testing demonstrates trustworthiness to the rest of the team. It also builds trust within the programmer.

• Pairing. Pairing builds trust between programmers. The reduced defect count & improved structure build trust with the rest of the team.

• Continuous integration. Integrating small sets of changes, optimized for safety, reduces gotcha moments for the rest of the team.

• Weekly planning. Demonstrating concrete progress to those who depend on it builds trust, as does honestly reporting hiccups.

• Customer on the team. All the little interactions during the day—asking domain questions, getting clarification, offering alternatives—build trust.

• Continuous deployment. Knowing that your code is running correctly in production adds to your own confidence. Knowing that everyone else operates under the same constraint adds to your confidence in each other. Customers seeing small changes appear nearly instantly builds their trust.

• Refactoring. When improving structure reduces defects or reduces future effort, it builds trust.

• Observability. Knowing that you’ll be alerted to malfunctions builds trust, as does the skin in the game of knowing that you’ll be alerted encouraging prudence so you avoid those malfunctions.

What I notice about this list that I didn’t expect is that each practice that creates trust also encourages trustworthiness. If I know I’m going to get paged in the night, I’ll do the work to reduce the chance that I’ll be paged in the night. If I know I’m going to be writing tests, I’ll do the work to make writing tests easier. I wonder if this is a general feature of the trust factory? We’ll find out

Principles

XP builds on a coherent set of principles aligned with producing value with software. Not surprisingly, given the topic of this essay, they also align with producing trust.

• Humanity. Acknowledging that we are all humans with needs creates trust, in part by encouraging folks to be more honest and clear about their needs.

• Mutual benefit. Looking for win/wins let’s everyone relax & quit trying to grab more than their share of the pie.

• Improvement. Acknowledging that today isn’t perfect but it’s better than yesterday & tomorrow will be better still encourages folks to trust each other.

• Flow. Seeing concrete progress frequently encourages trust, even when things are going slower than we’d like.

• Redundancy. When we address difficult problems several different ways we increase the chance that the problem won’t erode trust.

Sure looks like the same effect is at work. Trust encourages trustworthiness. I’ll be treated with human respect so I treat others with human respect. Others benefit me so I’m encouraged to benefit others.

Does the same process work at the level of values?

Values

Values are the vaguest level of describing XP but contain the most purpose. How do values encourage trust?

• Communication. Saying things that need to be said in ways that can be received builds trust.

• Simplicity. I’m getting iffy about simplicity as a value since successful systems always end up complicated, but having pieces that are easily described builds trust.

• Feedback. Knowing that you’ll be listened to encourages honesty, even when the topic is difficult.

• Courage. Acting from vision & purpose in spite of fears encourages the team to trust each other.

• Respect. Seems obvious to me.

Once again, creating trust creates the conditions for creating more trust.

---

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

---

Vibe Coding Versus Trust

Software development that focuses on trust as much as features has always been rare. We are now shifting to individuals interacting individually with the genie (I call this the single player problem. Trust, as the opening quote points out, lags features. This mismatch is unstable, unsustainable. When it corrects it’s going to be painful. How does single player augmented development as naively practiced erode trust?

• Genies “care” about satisfying prompts, not purposes. Generated software often doesn’t behave correctly in circumstances that are the least unusual. Thinking, “This works,” & then, “Oh no, it doesn’t,” erodes trust.

• Encouraging single player development eliminates most of the little chances to build trust.

• Purely reactive project management, the natural style when on the feature hamster wheel, risks tactical progress but strategic failure.

• The genie ignores optionality & future change. Walking off the end of the productivity pier is a big trust breaker.

So?

I’m not saying trust is all that matters. I’m saying trustworthy behavior resulting in trustworthy software resulting in trust is the path to effective augmented development.

I’ve been guilty of saying, “The program is the truth.” At one level this is true—whatever we think the system does, what the system actually does is what the system actually does. However, the software system is, as Jessica Kerr points out, a symmathesy, a human-technical system. We are in it, cannot help affecting it, we can only influence not control it.

What would trust-optimized augmented development look like?

• Slow development to ensure that the damn stuff actually works.

• Slow development to include structural improvements that expand options.

• Slow development to encourage frequent person-to-person interaction.

• Slow development to reinforce & update long-term purpose.

That’s how you go faster. More chances to build trust->more focus on trustworthiness->more trust.