Code as the Source of Truth: In the Product and In the Team

For fifty years, the scarce thing in software was people who could write it. Every tool, team structure, and review practice we built assumes that scarcity. It's gone, and most of us are still optimizing the part that already works — buying faster generation for a bottleneck that moved somewhere else.

I'm going to argue that the interesting question is no longer "is this good code?" but "if this is wrong, what's the blast radius?" — and that this single substitution reorganizes code review, CI, what deserves rigor, what can ship on merge, and what an engineer's job actually is.

I'll show it from both sides: a platform being rebuilt so that the code is the real artifact its users own rather than an export of one, and an engineering org discovering it had to make the same move internally. These turned out to be the same bet, which was not the plan. I'll include what it cost, what we got wrong, and the conditions under which none of this applies to you.