"Trust Is What Constrains the Speed of Development" AI keeps multiplying the amount of code we write. But the basis on which a team feels "it's safe to ship this change" doesn't grow at the same pace. Kent Beck writes that this gap leads to project failure. If you push forward implementing alone with AI, it looks faster simply because you skipped the consultation and the reviews. But what if, through those conversations, your colleagues came to understand the intent behind the change, and next time they'd be able to make the call themselves? Then what you cut wasn't just waiting time. Details below. - For customers, trust saves time Beck separates trust in the product itself from trust in the process that builds and delivers it. Trust grows only gradually, yet it collapses in an instant. When customers trust the product, the time they used to spend guarding against defects can go toward what they actually wanted to do with it. - Tests and pairing each build a different kind of basis Beck views the practices of Extreme Programming (XP) as things that build trust in combination. With tests, you can check whether the expected behavior still holds. With pairing, there's one more person who knows why the code was implemented that way. Both give you a reason to take the next step with a change. - Generate big, verify small AI can produce large changes all at once. The larger the change, the harder it becomes to be confident that the whole thing works as expected. That's why Beck emphasizes breaking changes into small pieces and verifying each one along the way. Pausing a little mid-implementation is the thinking that gets you to a point where you can deliver with confidence faster. - What disappears when you move fast alone Beck strongly opposes everyone drifting toward developing one-on-one with AI. The code you wrote remains as a deliverable. Misunderstandings resolved by thinking something through with someone else, on the other hand, and the understanding that spreads through review, are much harder to count. This article also serves as a promotion for his own paid course on how to keep doing that kind of work in the AI era. If the only person who can explain "why it's safe to release" is the one who made the change, the team's work isn't done yet. When you look back at how many hours AI saved you, it might be worth also asking: "Did the number of people I can hand this change off to with confidence go up?"