These decisions conflict with your team’s plans, past decisions, or goals.
1. New projects are now public by default, but the PRD and previous discussions say they should start private.
Conflicts with &
Impacts: Security / privacy, Customer UX
Why it matters
Every new project created after this ships will be visible to the whole workspace by default until its owner notices. The PR calls this a “simpler default,” but the PRD says new projects start private, and Monday’s product meeting reaffirmed it.
Should we approve this decision or request a change?
Librarian agents build a live graph of your team’s work and decisions as they unfold.
2.
Review agents read each pull request alongside the project context, identifying the most impactful product decisions.
3.
The engineer gets an impact report: the decisions to understand and the risks to resolve.
Catch Product Drift
Code review tools catch typos, type errors, and logic bugs, but costly mistakes still make it through. Saavi catches the product-level errors that other code reviewers don’t catch.
Unchecked AI Decisions
A coding agent made a product call on its own, and it has implications that a human should review.
1. The Japanese and Portuguese “Close” labels are not the word for close: “Looking forward to next time!” and “Bon voyage!”.
Impacts: Copy, Customer UX
Why it matters
These strings are the accessible name of the close button and the overlay-tap area, so screen-reader users in ja and pt hear a farewell instead of an action. The strings came from the automated translation step, and no person reviewed them.
2. The “Due today” payment amount shown to users uses Stripe’s total, but the expandable details show only list price and discount, with no tax line.
Impacts: Customer UX, Design / UI
Why it matters
If Stripe adds tax after Apple Pay returns the billing address, the line items won’t add up to the amount shown as due. Customers can see a total that doesn’t match the breakdown above it. The spec asked for the due-today line to match Stripe’s total; it never said how tax should be shown. I found no tax row anywhere in the new feature code.
Real production findings, anonymized
Deviation from Plan
These findings show places where the implemented code diverges from previous specs, PRDs, informal plans, and discussions.
1. The new premium benefit row is shown to every premium subscriber, including the experiment’s control group, instead of only the treatment group, as the plan specified.
Conflicts with
Impacts: Customer UX
Why it matters
The experiment spec says only the treatment group sees the row; control gets the same card without it. Showing it to both erases the difference the live experiment is measuring, so the clicks the spec uses to compare the groups stop meaning anything. No one recorded a decision to change the experiment, and the PR says Settings should “continue showing” the row, though control users never saw it.
2. User access to insights is now controlled by a feature flag added to every paid plan, not the Premium flag the ticket proposed, so Premium status alone no longer unlocks insights.
Conflicts with · Recorded only in
Impacts: Customer UX, Security / data
Why it matters
The ticket proposed gating on the Premium flag. The PR instead adds a key to the base paid feature list, which every paid plan inherits, so access now depends on each plan’s list. Any paying subscriber whose list misses the key, like a future plan or a child account, silently loses insights. The reason for the switch appears only in the PR description, and there’s no earlier record approving it.
Real production findings, anonymized
Missing test evidence
A risky change ships without proof it works.
1. Live checks that a free account sees only the snapshot and a paid account still sees the premium report haven’t been done.
Expected by · Deferred in
Impacts: Customer UX, Latency / reliability
Why it matters
The ticket’s definition of done requires free accounts to be blocked and premium accounts unchanged. The unit tests pass access tokens in by hand and never exercise the real path from a subscription to the access check, end to end. Both live confirmations are unchecked in the PR test plan, with no reason given.
2. The ticket asked for the new redirect to be checked in production, behind the CDN, and nothing shows it was.
Expected by
Impacts: Latency / reliability
Why it matters
The ticket said to test locally, then confirm the redirect in production, since the preview environment doesn’t run behind the CDN. The PR description is an unfilled template with no test notes or preview evidence, and no automated test covers the redirect. That doesn’t mean it’s broken, but nothing shows it works on the real domain.
Real production findings, anonymized
Ship faster with confidence and ownership of your product.
We’re opening Saavi to a small group of teams building with coding agents. Tell us about yours.
