Trust Factory

Kent Beck (Software Design: Tidy First?) · email · 2026-06-02 Reader 🖥️

Agile & XP The Genie (Beck)Learning Culture & Slack Multiplayer vs Single-Player AI Sociotechnical Architecture Trust Vibe Coding

Extreme Programming was a 'trust factory' — its practices, principles, and values all produced trust as a byproduct of producing software — and AI-augmented ('genie') development is breaking this because it accumulates code far faster than it accumulates trust; the remedy is to deliberately slow augmented development so it manufactures trust the way XP did.

practical · argumentative — Beck argues for action (adopt trust-optimizing practices in augmented development) but builds the case theoretically by re-reading XP through a trust lens. The piece is ultimately prescriptive: 'slow development to' build trust. Mixed argumentative-prescriptive.

Structure

Part	Role
Opening hook: quoted phrase 'We're accumulating code faster than we are accumulating trust.' Frames code+trust as bipedal — one without the other 'hops along awkwardly.'	Hook + framing metaphor; establishes the asymmetry between code (repairable) and trust (irreversible).
Practices section: lists eight XP practices (programmer testing, pairing, CI, weekly planning, customer on team, continuous deployment, refactoring, observability) and shows each as a trust-builder.	Evidence layer — concrete mechanisms that produced trust.
Principles section: five XP principles (Humanity, Mutual Benefit, Improvement, Flow, Redundancy) re-read as trust producers.	Climbing the abstraction ladder — same effect at a higher level.
Values section: four/five XP values (Communication, Simplicity, Feedback, Courage, Respect) re-read as trust producers, with a notable hedge that Beck is 'getting iffy about simplicity.'	Top of the abstraction stack; closes the practices→principles→values arc.
Sponsor break (WorkOS) — included by author as paid sponsorship, not part of the argument.	Commercial interlude.
'Vibe Coding Versus Trust' section: four mechanisms by which single-player augmented (LLM/'genie') development erodes trust.	Negative case — applies the framework to the present moment to show what's breaking.
'So?' section: prescription. Software is a symmathesy (cites Jessica Kerr); trust-optimized augmented development means 'slow development' on four counts — to make it work, expand options, encourage human interaction, and reinforce purpose.	Conclusion + prescription.

Key terms

Trust factory Trust
A coherent system of practices, principles, and values that produces trust as a structural byproduct of producing software — and that produces trustworthiness in its practitioners (i.e., trust and trustworthiness reinforce each other recursively at every level).
Trust Trust
An asymmetric resource that accumulates slowly and 'evaporates in an instant'; irreversible (unlike code defects which are often reversible in time proportional to the time taken to make them). Operates simultaneously between programmers, between programmers and the rest of the team, and between team and customer.
Genie / single player problem Multiplayer vs Single-Player AI
Beck's term for the LLM coding assistant and for the failure mode in which an individual developer interacts with the LLM alone, bypassing the team interactions XP designed in. Genies 'care about satisfying prompts, not purposes.'
XP Classic vs XPAI Agile & XP
XP Classic = the original XP practice set, which Beck claims is 'settled.' XPAI = a hypothetical AI-era extension whose practices are 'not yet settled.' Beck deliberately analyzes Classic because it has stable referents.
Symmathesy Sociotechnical Architecture
(Cited from Jessica Kerr.) A human-technical system that humans are inside of, cannot help affecting, and can only influence — not control. Beck uses this to walk back his earlier claim 'the program is the truth.'
Slow development Learning Culture & Slack
Deliberately decelerating delivery to make room for: (a) correctness verification, (b) structural improvements that expand options, (c) person-to-person interaction, (d) purpose-reinforcement. Paradoxically the path to going faster overall.
Trustworthy behavior → trustworthy software → trust
Beck's causal chain. Trust is downstream of trustworthy software, which is downstream of trustworthy behavior. The three reinforce each other in a feedback loop.

Propositions

explicitSoftware is 'bipedal' — code and trust must accumulate together; either alone is insufficient.conf: high
explicitTrust and code are asymmetric in opposite directions: code defects are often repairable in time proportional to the mistake; trust loss is irreversible.conf: high
explicitXP was, in retrospect, a trust factory — every practice that creates trust also encourages trustworthiness in the practitioner.conf: high
explicitThe trust-producing effect operates fractally — at practices, principles, and values levels — and 'creating trust creates the conditions for creating more trust.'conf: high
explicitSingle-player augmented (LLM-genie) development erodes trust along four vectors: (1) LLMs optimize for prompts not purposes; (2) it eliminates the small interactions where trust is built; (3) it encourages purely reactive project management; (4) it ignores optionality and future change.conf: high
extends9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team · p7 — Beck extends Brede Moe's warning that AI lets developers skip the colleague conversation into a four-vector account of how single-player augmented development erodes team trust.
supportsPodcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p8 — Beck's diagnosis that single-player LLM development eliminates the small interactions where trust is built supports Parker's claim that AI-assisted work drives developer isolation.
explicitcontestedThe current mismatch between code velocity (high) and trust accumulation (low) is unstable and unsustainable; the correction, when it comes, will be painful.conf: high
contradictsPresentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project · p10 — Beck argues the current high-code-velocity/low-trust-accumulation mode is unstable and unsustainable, directly opposing Wolff's claim that 90% AI-written code is sustainable and desirable for a shipping product.
explicitcontestedSlowing augmented development is the path to actually going faster — because trust enables sustained velocity.conf: high
supports9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team · p10 — Beck's 'slowing augmented development is the path to actually going faster' converges with Brede Moe's months-long slow-down-to-speed-up requirement for AI adoption.
contradictsVibe coding and agentic engineering are getting closer than I'd like · p4 — Beck prescribes slowing augmented development to sustain velocity via trust, while Willison argues cheap code production justifies tolerating much more risk and speed in design.
refines ←Using AI to write better code more slowly · p6 — Beck's claim that slowing down augmented development is 'the path to actually going faster' is not confirmed by Lawson's own account of running a comparably slower, careful practice — he explicitly reports no velocity gain and grounds the case for slowing down in quality/satisfaction rather than a speed payoff.
explicitcorroboratedSoftware is a symmathesy — a human-technical system you can only influence, not control — so 'the program is the truth' was an overclaim.conf: high
supports ←Collective problem solving in music, art, science, and software · p4 — Both claims independently assert that software is a symmathesy — a human-technical system whose behavior emerges from mutual learning/influence rather than one-sided control. This essay (Jessitron, 2018/2019) appears to be the original software-context source of the term via Nora Bateson; Trust Factory reuses the same framing in service of a claim about trust vs. control.
explicitSimplicity may no longer deserve its status as an XP value because 'successful systems always end up complicated.'conf: high
explicitTrust factories work because every trust-producing mechanism also imposes skin-in-the-game on the producer (e.g., 'if I know I'll be paged at night, I'll do the work to avoid being paged at night').conf: high
implicitTrust is the binding agent of teams and the missing input in current AI-coding methodology debates.conf: medium
implicitTrust at the developer↔team layer, developer↔developer layer, and team↔customer layer are produced by the same mechanism and treatable as one resource.conf: medium
implicitcorroboratedTrust is engineerable — it can be deliberately manufactured by adopting the right system of practices/principles/values.conf: high
extends ←Brain Food: Building Trust in Yourself Every Day · p4 — Applies Beck's 'trust is engineerable — deliberately manufactured by adopting the right system of practices' from team/code trust to intrapersonal self-trust: the same accrual-by-repeated-acts mechanism, one person deep.
supports ←How to ask for help from people who don't know you · p10 — Credibility manufactured through proof of work is an instance of 'trust is engineerable — it can be deliberately manufactured'; mechanism differs (one-shot artifact vs sustained system of practices) but the claim that standing is built, not innate, is shared.
implicitcorroboratedThe 'genie' is not inherently anti-trust — single-player usage is. (Beck names 'single player' as the problem, not the LLM as such.)conf: high
supports ←AI + Teams = ? · p1 — Both locate the problem in single-player usage patterns specifically, not in the AI tool itself — this piece's workshop evidence corroborates Beck's claim that 'single-player usage' (not the genie) is what erodes team trust/alignment.

Arguments

XP was a trust factory, and that explains its effectiveness. strength: high

Explicit premises:

Each of the eight XP practices produces trust (and each also encourages trustworthiness).
The same trust-producing effect appears at the principles level.
The same effect appears at the values level.

Implicit premises:

If a system produces an outcome consistently at every level of abstraction, the outcome is structural rather than incidental.
XP's known effectiveness is best explained by the structural output that was hiding in plain sight — trust.

Inferences:

Other methodologies could be evaluated by checking whether they have this fractal trust-producing structure.
Methodologies that lack trust-producing mechanisms at any level will fail in proportion to which level is unprotected.

Single-player augmented development erodes trust.

Explicit premises:

Genies satisfy prompts, not purposes.
Single-player development removes the small interactions that build trust.
Reactive feature-hamster-wheel management risks strategic failure.
Genies ignore optionality and future change.

Implicit premises:

Trust requires repeated small interpersonal interactions to accumulate — it cannot be substituted with code velocity.
Strategic failure is itself a trust event.

Inferences:

Multi-player / team-mediated augmented development could preserve trust formation.
If trust requires interpersonal touchpoints, increasing LLM usage without replacing those touchpoints monotonically reduces trust.

The remedy is to deliberately slow augmented development on four dimensions, which is paradoxically how you go faster.

Explicit premises:

Trust enables velocity (proven by XP).
Augmented development currently outpaces trust formation.
Slowing creates room for correctness, structural improvement, human interaction, and purpose-reinforcement — all trust-producers.

Implicit premises:

The 'speed' that matters is sustained team throughput over time, not per-PR cycle time.
Without trust, fast delivery degrades into compounding rework / strategic failure / team breakdown — eventually slower than the slow path.

Inferences:

Organizations measuring only short-term velocity will systematically under-invest in trust and pay later.
A 'trust dashboard' (or trust-leading-indicator instrumentation) might be possible — pairing rate, customer-on-team interaction count, deployment cadence, paging incidents.

The program is not the truth; the symmathesy is.

Explicit premises:

Software is a human-technical system (Kerr).
Humans inside it cannot help affecting it.
Humans inside it can only influence, not control, it.

Implicit premises:

If you can only influence rather than control, prioritizing technical artifacts (code, tests) over the human-system layer (trust, communication) is a category error.
A trust framework is the appropriate ontology for software, not a code-correctness framework.

Inferences:

Debates that frame AI coding only in terms of code output quality (benchmarks, eval scores) miss the load-bearing variable.
DORA-style outcome metrics are downstream of trust formation, not substitutes for it.

Narratives

Reflection on programmer testing: 'If I know I'm going to be writing tests, I'll do the work to make writing tests easier.'
→ Concrete illustration of the trust→trustworthiness recursion. Shows the mechanism: the structural commitment changes the practitioner's behavior, which then produces more trust.
Reflection on observability: '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.'
→ Same mechanism — skin in the game produced by the practice generates trustworthy behavior. Generalizes the trust factory's recursive structure.
Self-correction about 'the program is the truth' — Beck names a slogan he used to use and walks it back via Jessica Kerr's symmathesy framing.
→ Carries the implicit argument that trust-centered thinking requires giving up some technical-centric reflexes; models intellectual honesty as a trust-builder in itself.
Casting LLM coding assistants as 'genies' — and the framing of 'walking off the end of the productivity pier.'
→ Metaphor carrying the argument that LLMs grant wishes literally (prompt-satisfaction) without understanding purpose; and that current augmented velocity is a runway that ends.

Questions addressed

✅ Why did XP work?
Because it manufactured trust as a structural byproduct at three levels (practices, principles, values), creating a self-reinforcing trust↔trustworthiness loop.
✅ Why does naive single-player augmented (LLM-driven) development feel productive but go wrong?
It accumulates code without accumulating trust; the mismatch is structurally unsustainable.
✅ What should AI-augmented developers actually do differently?
Deliberately slow development on four dimensions (correctness, structural options, person-to-person interaction, purpose) — which is how you go faster.
⭕ Is simplicity still a defensible value for software design?
Beck signals doubt but does not resolve it; flags 'I'm getting iffy about simplicity as a value since successful systems always end up complicated.' This is a live thread in his current writing.
⭕ How is trust at the developer-pair level related to trust at the team-customer level — are they one resource or distinct?
Not addressed; Beck treats them as a single resource produced by the same mechanisms.
⭕ How would 'XPAI' — XP with AI — actually be structured?
Deferred; Beck explicitly says 'the new set of practices is not yet settled' and chooses to analyze XP Classic instead.

Gaps

incompleteTrust is treated as one undifferentiated resource. Trust between paired programmers, trust from the rest of the team, trust from the customer, trust in the system (observability) — Beck collapses these. But they have different production functions, different decay rates, and may not be substitutable. A skeptic might point out that customer trust is far more about delivered value than pairing rituals, while pair-trust is largely independent of customer outcomes.
Read next: Janson + Wester on pair-trust (Heis ep 6 — 'if something feels off, say it once'); Printzell Halvorsen on Nordic societal trust enabling distributed teams (Heis ep 8); Onora O'Neill on the trust-trustworthiness distinction and on different kinds of trust requiring different verification structures.
incompleteNo treatment of misplaced trust, trust-in-bad-actors, or trust-as-attack-surface. The essay frames trust as monotonically good. But trust without verification is the prompt-injection vulnerability, the rogue-employee vector, the 'too-much-trust' problem. Anders Sveen's argument (Heis ep 11) that LLM tool-use authorization can't rely on trust because the agent can be prompt-injected applies here.
Read next: Sveen on AI authorization (Heis ep 11); zero-trust architecture literature; Schneier on trust models (already in the user's RSS); Annie Duke on resulting / decision quality independent of trust.
closed byRunning Python code in a sandbox with MicroPython and WASM — Willison provides the missing treatment of misplaced trust: do not trust agent code at all — contain it at an execution boundary and cut the exfiltration leg, since sandboxing (not trust) is the answer to prompt-injected or wrong-but-sanctioned actions.
incompleteThe 'trust factory' metaphor is endorsed without examining what it concedes. 'Factory' implies trust is manufactured by repeating standardized processes — but a major tradition (cultural, philosophical, theological) treats trust as precisely the kind of thing that cannot be manufactured. Beck does not engage this objection. The metaphor's industrial framing also obscures that XP practices may have worked because they instantiated values the practitioners already held — not because the practices produced the values.
Read next: Cutler on operating-system design vs cultural pre-conditions (TBM series); Diego Gambetta on trust as a non-manufacturable resource; the 'culture eats process for breakfast' literature.
incompleteThe four 'slow development' prescriptions are stated but not operationalized for the augmented case. How exactly do you 'slow development to encourage frequent person-to-person interaction' when the genie is so seductive? What are the equivalent of XP practices for the augmented era? Beck explicitly defers this ('not yet settled') but a reader looking for action is left with a principle, not a practice.
Read next: Beck's own subsequent essays (the 'XPAI' thread he's hinting at); Birgitta Böckeler on harness engineering; Garg on reducing friction in AI development (both already in the user's extracted corpus); Bockeler/Anthropic harness writing.
incompleteThe cultural specificity of trust is not addressed. XP emerged in a high-trust professional subculture (Chrysler C3, early agilists). Whether the trust factory works in low-trust organizational contexts — or only metabolizes pre-existing trust — is left untested. Same question applies to whether trust factories scale across cultural and national boundaries.
Read next: Printzell Halvorsen on Nordic high-trust societies enabling distributed teams (Heis ep 8); Fukuyama on high-trust vs low-trust societies; cross-cultural management literature.

Closes gaps elsewhere

Bliki: Vibe Coding · g2 — Beck addresses the team/organizational dimension Fowler leaves out: single-player augmented development erodes trust across four vectors, and trust is the binding agent current AI-coding methodology debates ignore.

Trust Factory

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents