AI code review catches mistakes after the PR is opened.
Tenure prevents them before the PR exists.
Most AI code review tools assume the problem happens at review time. Tenure assumes part of the problem happens earlier: at generation time, when the model is missing the conventions, decisions, and unresolved questions your team already discussed.
Review the PR after it's opened
The PR opens with naming inconsistencies, wrong folder placement, an abstraction your team already has, and error handling that doesn't match your patterns. A bot flags some of it. The reviewer flags the rest. The author fixes, pushes again. Cycle repeats.
Align the code before the PR exists
Your team's naming conventions, folder structure, existing abstractions, error handling style, testing expectations, and explicit architecture decisions are in context when the code is generated. If something is unresolved, Tenure can preserve it as an open question instead of letting the model silently guess. The PR opens closer to how your team would have written it. Less avoidable rework. Fewer round-trips.
Some review comments require human judgment. Tenure is not trying to eliminate those. It targets the avoidable comments: convention violations, missed architecture decisions, rejected approaches, and places where the AI guessed instead of carrying forward an unresolved question.
Your team uses getUser not fetchUser. handleError not onError. Service files are *.service.ts, not *Service.ts. Tenure stores this. Every AI request that touches these files gets it injected automatically.
Auth logic belongs in /services/auth/, not /utils/. Shared hooks go in /hooks/shared/. Tenure tracks where things live so AI stops generating files in the wrong place.
You already have a withRetry wrapper. You already have a parseApiError utility. Reviewers spend time pointing this out. Tenure stores it once. AI uses it every time.
Factory functions over classes. Repository pattern for data access. No direct DB calls from route handlers. These are not just patterns inferred from code; they can be explicit decisions someone stated once in an AI session. Tenure stores the decision with scope, confidence, and provenance, then injects it when future generation touches the relevant project.
Your team throws structured errors with { code, message, context }. Always. Not bare strings, not generic Error objects. Tenure knows. The AI you're using knows, because Tenure tells it.
Vitest, not Jest. Unit tests in __tests__/ adjacent to the module. Integration tests in /tests/integration/. Mocks using vi.mock(), never manual stubs. All stored. All injected.
An engineer says, Use the raw MongoDB driver here; do not add Mongoose. That does not need to appear three times in the codebase before it matters. Tenure can capture the statement as a high-confidence decision and apply it to future AI requests in the same project.
If the team has not decided between Redis and Postgres for a queue, Tenure can preserve that as an open_question. The next AI session can surface the uncertainty instead of generating code that assumes the answer.
There are two different kinds of context that affect code review. Tenure handles both, and it treats unresolved context as first-class instead of forcing the model to invent an answer.
Naming, folder placement, imports, error handling, test layout, and repeated coding patterns. These can be extracted from demonstrated code patterns or config artifacts and injected before generation.
Business rules and architecture commitments the user explicitly states, like do not persist PII in logs or raw driver only. A single explicit statement can become a high-confidence project belief.
Tenure distinguishes direct statements, config artifacts, and inferred patterns. That matters because an explicit decision should carry more weight than a weak pattern inferred from one generated file.
When something is unresolved, Tenure can store the uncertainty. The value is not only remembering what the team decided; it is also remembering what the team has not decided yet.
You do not have to wait for a rule to appear in the codebase. Tenure can capture a direct statement from the user, a config artifact in the workspace, or a repeated pattern in generated code. Each belief carries scope, confidence, epistemic status, aliases, and provenance, so future requests know what to apply and why.
When you tell your AI we use factory functions, not classes or do not use Mongoose, raw driver only, Tenure can extract that as a project-scoped decision. It does not need to infer the rule from historical code first.
The MongoDB convention for your API project does not bleed into your data pipeline project. Tenure also distinguishes an explicit decision from an inferred pattern or config artifact, so the model is not treating every hint as equally authoritative.
Before the request reaches the model, Tenure injects the relevant beliefs and unresolved questions automatically. The AI generating your code sees the team's conventions, the decisions it must respect, and the questions it should not guess around.
Same AI tool. Same task. Different outcome when the AI has both conventions and explicit decisions in context.
They sit at the end of the pipeline, after the code exists, after the PR is open, after the review clock has started. They're useful. But they're reactive.
Tenure sits at generation time, before the code is written. The reduction in PR review time is a consequence of better-aligned output: fewer convention misses, fewer ignored decisions, and fewer guesses where the team had not decided yet.
PR review still requires judgment. Tenure reduces the avoidable part: re-explaining context the AI should have carried forward.
When one engineer captures we use Zod for input validation, not Joi, every other engineer's AI knows it too. When another engineer captures queue backend is still undecided, future sessions know not to assume one. Shared memory propagates decisions and uncertainty without a style guide meeting, without a Confluence page nobody reads, without a linting rule that fires after the fact.
Monorepo structure, layer boundaries, forbidden patterns, approved libraries. Stored once. Injected for every engineer on the project.
Function prefixes, file naming, event naming, prop naming. The kind of thing that lives in a Notion doc nobody opens. Now it's in context automatically.
The utilities, hooks, and services that already exist. AI stops reinventing them and starts using them because Tenure tells it they're there.
"We evaluated Prisma and ruled it out." That decision lives in Tenure too. Not just what you chose, but what you rejected and why.
Self-hosted shared memory for AI coding tools. Start with Tenure Community, or choose a team plan for shared workspaces, segmented memory, and support.
Helm chart · OIDC / SCIM · No call-home telemetry
fetchUser→getUserper our conventions.{ code, message, context }shape. SeeAppErrorin/lib/errors.