The session arrives attached to a branch, with one line of commentary: "context's in there if you want it, looks good to merge." Now you have to review a teammate's AI session cold, before its conclusions quietly become the project's defaults. You have none of what they had live: the files that were open, the error they had just hit, the three attempts that failed before the one in the transcript, the reason they said "no, do it the other way" without typing why.
Reviewing your own assistant's work is a different job. There you know what you asked for, so you can check the diff against your intent, which is most of what reviewing assistant changes before you commit is about. With someone else's session you are checking a decision whose intent you have to reconstruct first.
The failure modes below are specific and they repeat. Most of them look like agreement at the time you read them.
A kept session is not a reviewed session
Keeping a session is a judgment about whether the conversation is worth storing. It says "this is where the retry behaviour got worked out." It does not say "the retry behaviour is correct." Those two claims get collapsed the moment the file lands in .prjcontext/sessions/, because a transcript that someone deliberately saved reads as endorsed.
It usually isn't. The criteria for which sessions are worth keeping are about reasoning density: does this conversation explain something the code can't. A session can be worth keeping precisely because the reasoning in it is contested.
So separate the two acts explicitly. The author vouches for provenance: this is where X was decided, and this is the real transcript. You are the one deciding whether X holds. If nobody takes that second role, the session becomes project history by default, and six weeks later the assistant quotes it back at you as settled.
How to review a teammate's AI session without replaying it
Reading a long transcript top to bottom, message by message, is the slowest possible way to do this and it biases you toward the end. By message forty you have absorbed the framing and you agree with the conclusion because you've been walked there.
Read it for decisions instead, and write them down as you go. Four or five lines is normally enough:
From session 2026-10-14 (auth refactor):
- Decided: session tokens verified in middleware, not per-route.
- Alternative that appeared: per-route guards. Dropped after one exchange, no reason given.
- Assistant asserted: the library's `verify` call caches JWKS internally. Not checked.
- Constraint invoked: "we can't add another dependency." Whose rule is that?
- Left open: token refresh during a long request.
That list is the review artifact. It takes ten minutes on a long session and it turns a transcript into something you can actually respond to. Notice what the format forces: separating what was decided from what was merely stated, and marking which factual claims rode in unverified.
The one thing worth reading closely in full is the end. Mid-session pivots are common, and a transcript where the approach changed at message thirty contains thirty messages of reasoning for an approach nobody is using. If you skim the first half and trust it, you'll argue against a position your teammate already abandoned.
Three places a shared AI coding session quietly goes wrong
The confident factual claim nobody opened the docs for
Assistants state library behaviour in the same tone they state arithmetic. "The client already retries with exponential backoff on 5xx" is plausible, specific, and either true or not. When it appears mid-session and the teammate builds on it, the claim gets load-bearing without ever being checked. These are the easiest findings in the whole review: pull every factual assertion about a dependency's behaviour out of your notes and verify the two that the design rests on.
The constraint that came from one machine
A decision shaped by the author's local setup travels badly. They were on an older Node version, or a stale branch, or their editor was reformatting on save, and the assistant adapted to that. In the transcript it reads as a project constraint. Watch for reasoning that only makes sense given a specific environment, especially anything about versions, paths or build timing.
The silent "no"
The assistant proposes an approach, the teammate replies "no, do B", and the session continues. No reason recorded. That unexplained rejection is the most durable thing in the file, because the next session reads B as the established pattern and the rejected option never comes back up for discussion. When you spot one, flag it. It's the only part of the session you cannot reconstruct by reading harder.
While you're in there: a transcript written for one person's eyes may carry a key, a token or a production hostname that was fine in a chat window and is not fine in a shared repository. Checking that is a two-minute pass, and finding and redacting secrets in session transcripts covers what to look for.
Ask three questions, not for a re-explanation
The reflex is to message the author with "can you walk me through this?" That gets you a fresh summary built from their current memory, which is a different artifact than the session and usually a tidier one. It smooths over the uncertainty you were trying to find.
Ask narrow, anchored questions instead. "Where you switched to middleware verification, was that a constraint or a preference?" "Did you check that the JWKS caching claim is real, or did we take the assistant's word for it?" "Is the no-new-dependency rule ours or was that about that week?" Three questions, each pointing at a specific moment. They're fast to answer and the answers are the parts that were never in the transcript.
Folding it in without inheriting an assumption nobody checked
Once you're satisfied, the session shouldn't be the thing future sessions rely on. A transcript is evidence, not a rule, and no assistant is going to read forty messages and extract the right constraint. Write the decision record, with the provenance and the open questions intact:
### 2026-10-16 - Token verification in middleware
Decision: Verify session tokens in middleware; no per-route guards.
Why: One place to change when the token format moves.
Source: session 2026-10-14 (auth refactor), reviewed 2026-10-16.
Unverified: assumes the client caches JWKS. Re-check before adding a second issuer.
Status: Active
The Unverified line is the part that matters here, and it's the part that disappears when you turn someone else's session into memory the way you'd turn your own into memory. Your own sessions don't need provenance because you are the provenance. The session to decision record workflow handles the shape of the entry; reviewing someone else's just adds those two lines.
This is easier when the session is something you can open in context rather than a transcript pasted into a thread. We built PrjLab so kept sessions sit in the repository next to the code and the project memory they produced, versioned, so you can see what the files looked like at the time and what memory already said before the session changed it. Reading a decision against the state it was made in is most of the review. If your team is still trading context by hand, sharing AI coding context with your team covers the setup, and the getting-started guide walks through the first push.
The habit worth keeping is small: before a teammate's session shapes anything, spend ten minutes turning it into a list of claims, and mark the ones you took on faith.
