Code review that knows what your team already decided

Code review has a context problem that nobody talks about because everyone treats it as normal.

A new engineer opens a PR that touches the auth middleware. The reviewer looks at the diff. The diff is fine — clean code, good structure, tests pass. What the reviewer can't see in the diff is that six months ago, the team made a binding architectural decision: session tokens must not be stored server-side, full stop, compliance requirement. The code in the PR stores a session token server-side. The decision isn't in the diff. It's in the head of whoever was in that meeting in February.

If that person is still at the company and happens to be on the review rotation, the PR gets caught. If they left in March, the PR might ship.

This isn't a people problem. It's a context problem. The review process has access to the current state of the code. It doesn't have access to the accumulated decisions, principles, and constraints that should govern how the code changes.

What loads in a review session

When Memory Stack is connected to your engineering workflow, each code review session loads the context that's relevant to what's changing.

A PR touching the auth middleware loads:
- Architectural decisions that reference the auth module by path or tag
- Principles the team has extracted from prior auth-related work
- Any standing rules flagged for the module (compliance constraints, review requirements)

A PR adding an async write path loads:
- The team's async write discipline (timeout + single-flight gate — extracted from prior incidents and commits)
- Any latency targets or SLA principles attached to the write path

A PR editing the billing module loads:
- Architectural context: this module feeds the billing pipeline, changes require billing integration tests
- The team's track record of what breaks when this module changes

None of this requires manual curation per PR. The context is tagged at capture time; it loads at review time based on what the PR touches.

Where the context comes from

The context is built by two systems running in parallel.

The first is explicit capture: architectural decisions logged directly to Memory Stack when they're made. The February compliance decision should have been logged then — "session tokens may not be stored server-side (auth module)" — tagged arch:auth and compliance:required. That memory surfaces in every subsequent review that touches auth. The decision outlives the meeting.

The second is extracted capture: the Skill Transfer system, which identifies recurring patterns in your team's engineering sessions and formalizes them as structured skills. The async write discipline described above wasn't manually written as a principle. It was observed across a series of incidents and PRs, recognized as a recurring pattern, extracted by the LLM pipeline, and promoted by a team lead reviewing the extraction output.

The two systems compound. Explicit capture gets the high-stakes decisions logged at the moment they're made. Extracted capture catches the patterns that emerged from practice — the things nobody wrote down because they seemed obvious, until someone new joined and didn't know them.

What the reviewer sees

The reviewer isn't replaced. The context surfaces alongside the diff — same review surface, additional signal.

For a PR touching a module with rich context: the reviewer opens the review, sees the relevant principles and decisions listed, and works through the diff with that context in mind. "Here's what your team decided about this area" is the frame. The reviewer still exercises judgment; they just start with the accumulated decisions of the team instead of whatever they happen to remember.

For a PR touching a module with sparse context: the reviewer sees what's there — maybe a compliance tag, maybe nothing. Sparse coverage is honest. It means either the module hasn't generated many decisions worth capturing, or capture hasn't been prioritized there yet. Either is useful to know.

The context that doesn't expire

The compounding value is in the decisions that outlast the people who made them.

A team member who made a critical architectural decision three years ago and has since left the company is still effectively in the review loop — through the memory they left behind. The decision is attributed, dated, and available. The reviewer doesn't need to know the person; they need to see the constraint.

This changes the economics of turnover and team growth. New engineers joining a team with rich engineering memory don't need 6 months to absorb the accumulated context of prior decisions. The context is available at the tooling layer. The ramp-up is shorter, the error surface is smaller, and the institutional knowledge doesn't evaporate when someone leaves.

The honest version

Context quality depends on capture discipline. A team that hasn't logged architectural decisions into a memory layer — that relies on meeting notes in Notion and tribal knowledge in Slack — will start with sparse coverage. The extractor has more to work with as the memory builds, but it doesn't retroactively surface decisions that were never captured.

The extraction pipeline isn't infallible. Extracted skills go into a review queue — a team lead reviews them before they're promoted to the active rule set. Some extractions are accurate and useful; some are over-generalized patterns that shouldn't apply universally. The review step exists because the pipeline is a first pass, not a final judgment.

And code review that loads context is still code review. A reviewer with full historical context can still miss things. The context improves the starting point; it doesn't substitute for attention.

The decisions your team made six months ago should still be available when someone writes code that touches the same area today. That's not a new principle — it's just not been operationally achievable until the tooling made it possible.