How PMs use read access to GitHub repos

A PM asked how others use read access to the GitHub repos — feature backlogs, summarizing PRs into release notes, and one line that's the whole game: baselining a new feature's PRD against what already exists in the codebase, "so your spec starts from reality, not assumptions."

That line deserves more attention than it got. Most specs are written from a mental model of the product, and the mental model is always a little wrong. Read access closes the gap between what you think the product does and what it actually does.

What repo access actually unlocks

• Baselining the spec against reality. Before writing requirements for a change, you (or an AI working from the code) describe what currently exists in that feature area. Now your spec modifies a real thing instead of an imagined one — and you stop specifying behavior that already exists or contradicting behavior you forgot about.
• Finding the half-built. Codebases are full of helpers that exist but aren't wired up, flags that are half-implemented, endpoints with no UI. Reading the repo surfaces capability you already paid for and can ship cheaply.
• Release notes from PRs. Summarizing merged PRs into human-readable release notes is mechanical and high-value, and it keeps your user-facing communication tied to what actually changed.
• Honest feasibility. Seeing the structure of the code makes "is this a small change or a rewrite" a question you can partially answer yourself, instead of guessing and getting surprised in sprint planning.

The non-programmer's version

You don't need to read code fluently to get most of this. The pattern that works: point an AI at the relevant part of the codebase and ask it to describe, in plain language, what exists today — the actors, the triggers, the effects. You're not reviewing code; you're getting a grounded description of current behavior that your spec can build on. That's the same move as reverse-spec, just applied to a feature area instead of a whole app.

Why this is the anti-slop move

Every complaint about AI-generated specs comes back to missing context. The codebase is context — the most authoritative context there is, because it's literally what the product does. A spec baselined against the repo can't invent a feature that doesn't exist or ignore one that does. Starting from reality instead of assumptions isn't a nice-to-have; it's the difference between a spec engineering trusts and one they have to fact-check.