Trust Is the Bottleneck, Not Typing · Morning Gist
Sunday, November 11 story · 4 min
Trust Is the Bottleneck, Not Typing
A single story today: Kent Beck says teams that produce code faster than they can check it end up limited by verification, which makes batch size a choice.
Picked from 67 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Kent Beck argues software teams are limited by how much change they can trust, not by how much code they can write. story 1 ↓
His one testable claim is that a change gets harder to trust as it gets bigger, so smaller batches deliver faster. story 1 ↓
If code arrives faster than review and testing can handle it, verification sets delivery speed. That's directly relevant to AI-assisted coding. story 1 ↓
Most of the post is an ad for his paid two-day class. The claim itself is worth testing on your own team. story 1 ↓
1/1Kent Beck (Tidy First?)· Kent Beck· Oct 30
Kent Beck argues trust, not code output, is what limits software teams
Kent Beck argues that teams now write code faster than they can come to trust it, and that this gap sinks projects. The post is mostly an advertisement for his paid class.
Why it matters · If code arrives faster than review, testing and shared understanding can absorb it, delivery is limited by verification, so batch size becomes a decision worth making on purpose.
Know this first
Context from the editor, not the article · 33 sec
1 · Who Kent Beck is
Kent Beck created Extreme Programming (XP) in the late 1990s, popularised test-driven development and co-wrote the JUnit testing framework. His newsletter, Tidy First?, is named after his book on making small structural cleanups to code before changing what it does.
2 · What Extreme Programming is
Extreme Programming (XP) is a software method built on short feedback loops. Its practices include writing tests first, pair programming, continuous integration, small releases, and a customer sitting with the team. It names five values: communication, simplicity, feedback, courage and respect.
3 · Why batch size matters
Lean and DevOps practice has long held that smaller changes are easier to review, test and roll back. When a small change breaks something, the cause is easy to find. When a large one does, the failure could come from many places and how they interact.
Image: Kent Beck (Tidy First?)
The news
Remember
Beck sees verified trust, not how fast code gets written, as what limits delivery, so faster output can make things worse.
His tweak paradox says trust falls with the square of change size. He offers it as a claim, not a measured result.
He argues XP's practices build trust only as a system. Adopting them one at a time gives you less.
Kent Beck, who created 1 (XP), is teaching a paid two-day live class called The Human Practices Behind Trustworthy Software. It runs on 2 Live on November 9 and 10. Each day is a two-hour lecture plus an hour of Q&A, and sessions are recorded. The post is mostly the announcement. Beck says the class "is not cheap" but doesn't give a price. The argument behind it is the part worth reading.
The thesis
"Teams accumulate code faster than they accumulate trust," Beck writes, and he says projects fail in that gap. His reasoning: trust builds slowly and disappears in an instant. Most of the work that builds it, such as collaboration, testing, review and shared understanding, produces nothing anyone can see. Faster code-generation tools speed up only the visible output, and Beck argues the trust-building work gets dropped so individuals can move faster on their own.
He separates trust in the product (customers believe it works) from trust in the process (the team believes its methods produce working software). He puts product trust in economic terms: customers who trust the software spend less effort guarding against it failing.
How trust gets built
The class covers XP's practices: testing, 3, 4, planning, a customer on the team, continuous deployment, refactoring and observability. Beck insists these work as a system, not a checklist. He presents XP's values (communication, simplicity, feedback, courage, respect) as the means of producing trust.
The 5
The one concrete claim is what Beck calls the tweak paradox: trustworthiness falls with the square of a change's size. He gives no data for it. One plausible reading, which is ours: a change touching n parts creates about n²/2 pairs of parts that could interact. With illustrative numbers, 5 parts give 10 pairs and 50 parts give 1,225. Code-generation tools favour big batches, while trust needs small, verified steps. Beck also warns that being pushed into "6" development with tools, instead of working with teammates, is "a huge mistake." His summary: "Slowing down in the right places is how you go faster."
Caveats
This is the outline of a sales pitch, not an argued essay. The quadratic claim isn't measured, "trustworthiness" isn't defined, and the post doesn't say how to tell which places deserve slowing down. The idea is still cheap to check yourself: compare change size against rollbacks and incidents in your own history.
What this post is
This is mainly an announcement. Kent Beck, who created 1, is teaching a paid live class called The Human Practices Behind Trustworthy Software. It runs on 2 Live on November 9 and 10. Each day is a two-hour lecture followed by an hour of Q&A, and every session is recorded. The post doesn't give the price. Beck says himself that it's "not cheap", and he notes that many people expense it through a training budget. Readers who skip promotions can stop here. The rest of the post sketches an argument Beck has been building in his newsletter for two years, and that argument is worth knowing.
The thesis: code piles up faster than trust
Beck's central claim fits in one line: "Teams accumulate code faster than they accumulate trust." He says projects fail in that gap, where code exists that nobody trusts.
He makes three supporting points:
Trust grows slowly and disappears fast. One bad incident can undo months of reliable work.
Most of the work that builds trust is invisible. Collaboration, testing, review and shared understanding produce no visible output. Code does.
Tools that speed up code generation speed up only the visible part. Beck argues that the trust-building practices get dropped in favour of working alone at speed.
He separates two kinds of trust. Trust in the product is the customer's confidence that the software works. Trust in the process is the team's confidence that the way they build software produces software that works. He frames product trust in economic terms. When customers trust the software, they spend less time guarding against its failures and more time using it.
The practices that build trust
The class covers the main XP practices: testing, pair programming, 3 (merging and testing everyone's work at least daily), planning, a customer on the team, continuous deployment, refactoring and observability. Beck stresses that these work "as a system", not as a checklist. In his view they reinforce each other, so adopting one alone gives you less than the sum.
Under the practices he lists principles: humanity, mutual benefit, improvement, flow and redundancy. He treats XP's five values (communication, simplicity, feedback, courage, respect) as a system that produces trust, "not a poster on the wall."
The 4
The one quantitative claim in the post is what Beck calls the tweak paradox: the trustworthiness of code falls with the square of the size of the change. He gives no data or derivation for it. One reasonable reading, which is ours and not Beck's, is that a change touching n parts creates roughly n(n−1)/2 pairs of parts that could interact. Illustrative numbers: a 5-part change has 10 possible pairwise interactions to check, while a 50-part change has 1,225. Testing and review effort may grow roughly linearly with size, but the space of possible surprises grows faster than that.
The paradox, as Beck puts it, is that code-generation tools favour big batches while trust needs small, verified steps. His conclusion is that "slowing down in the right places is how you go faster."
Working alone versus together
Beck's second claim about tooling is that engineers will be pushed toward "5" development, one person working with an automated assistant, and that this is "a huge mistake." He doesn't spell out the argument in this post. It fits his long-running case for 6 and on-site customers, which spread understanding of the code across several people. That shared understanding is part of what lets a team trust code it didn't personally write.
What the post leaves open
The post is an outline for a class, not an argued essay, so most claims come without support:
The quadratic relationship is asserted, not measured. Readers will want to know what "trustworthiness" means in practice, for example defect rate, how often changes are rolled back, or reviewer confidence, and whether the curve really is quadratic or just superlinear.
The post doesn't say how to tell the "right places" to slow down from the wrong ones. Beck says the class answers the "what do I do on Monday?" question with exercises teams run on their own code.
Batch size and practices like pairing cost throughput. The post doesn't weigh those costs against the benefits.
Beck adds his own caveat. A team that already trusts itself completely and has a smooth tooling workflow doesn't need the class. He adds, "I have never met that team."
Bottom line
The useful part here is a framing, not new evidence. Count verified trust as the limiting resource, and treat batch size as the setting that controls how much trust each change costs. If your team's merge requests have been growing, the tweak paradox is a cheap hypothesis to test against your own incident and rollback history.
