t writing much code myself back then. I was mostly in meetings where a dev presented their approach and someone else, usually the person least invested in that particular solution, found the hole in it. Peer reviews weren't optional. If your merge request didn't get at least one real objection, that was suspicious, not reassuring.

The devs I worked with weren't natural debaters. A lot of them were the type who'd rather push a fix at 11pm than explain it out loud in a room. Making them argue their design decisions in front of peers was, for some of them, closer to a small ordeal than a fun Tuesday. I remember one guy who'd go quiet for a full 10 seconds before answering a challenge, visibly working through whether to concede or dig in.

But the pattern held across every team I ran. Projects with real friction in review shipped fewer regressions. Projects where reviews turned into rubber stamps, where everyone just approved everyone else's pull requests to keep the peace, those are the ones where I'd get paged on a Saturday. I didn't have a framework for why at the time. I just had the data from watching it happen, project after project.

Just Me and a Model That Agrees

Now it's just me and Claude Code, and the whole dynamic is gone. I describe what I want to build, it builds something close to that, I read it (or don't, depending on the day), and I ship it. There's no version of this loop where the model tells me my architecture has a problem it actually believes in. It tells me my architecture has a problem when I ask it to find one, and even then it usually finds the problem I was already hinting at.

That's a strange kind of quiet, and not the good kind where things run smoothly because they're well-built. It's the kind where you realize, a few weeks in, that a sensor you used to rely on just isn't there anymore, and you didn't consciously decide to remove it.

Why Disagreement Made the Code Better

There's a name for what I was doing without knowing it, and it comes out of decades of research that has nothing to do with software.

Charlan Nemeth, a social psychologist at Berkeley, spent about 40 years studying what actually happens to a group's thinking when someone in the room disagrees with the majority. Her finding, repeated across dozens of studies, is that authentic dissent (someone who genuinely believes the minority position) makes everyone else in the group think more broadly. People consider more alternatives. They search harder for information. They catch flaws they'd have missed under consensus. And critically, this holds even when the dissenter turns out to be wrong. The value isn't in the dissenter being right. It's in the fact that someone in the room actually means it.

Juries