The pull request is the spec review

I review pull requests. Not as an approver, and not to check anyone's work. I read them because a diff is the only honest account of what was actually built.

A specification is a claim about the future. A pull request is a statement of fact. Between the two there is always a gap, and the gap is where the product I described stops matching the product that ships. Nobody hides it. It just accumulates, one reasonable decision at a time, in places where the spec was silent and the engineer had to choose something.

If the only place the spec and the code meet is a demo, you will find out about the gap in front of a customer.

The objection is that a PM reading diffs is a PM who does not trust their team. In practice it reads the other way round. The engineers I have worked with would rather I found the ambiguity in their code than sent it to a partner with my name on the specification. It also shortens the conversation: instead of "the provisioning flow feels wrong", I can point at the line where the contract says one thing and the implementation reasonably assumed another.

I started as a software engineer, which makes this cheap for me and probably harder for a PM who did not. But the underlying habit does not require reading code. It requires picking one artefact that cannot lie about what was built and looking at it regularly. A diff. A production log. A live dashboard. Something that was not made to persuade you.