Use cases PR Review
Use case

Shorter PR reviews start
with better code generation.

AI code review catches mistakes after the PR is opened.
Tenure prevents them before the PR exists.

The difference

Two different theories of where time gets lost.

Most AI code review tools assume the problem happens at review time. Tenure assumes it happens earlier: at generation time.

AI code review

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.

Catches problems. Doesn't prevent them.

AI memory (Tenure)

Align the code before the PR exists

Your team's naming conventions, folder structure, existing abstractions, error handling style, and testing expectations are in context when the code is generated. The PR opens closer to how your team would have written it. Less to debate. Fewer round-trips.

Prevents problems. Doesn't just catch them.
The fastest review is the one that doesn't require fixing avoidable problems.
Where review time goes

Reviewers spend most of their time on things AI already knows. If you tell it.

The comments that slow review cycles aren't logic bugs. They're convention violations. Things that should have been obvious from context but weren't, because the AI generating the code didn't have that context.

01 Naming

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.

02 Folder placement

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.

03 Existing abstractions

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.

04 Architectural patterns

Factory functions over classes. Repository pattern for data access. No direct DB calls from route handlers. These decisions were made in a planning doc two months ago. Tenure remembers them.

05 Error handling

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.

06 Testing expectations

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.

How it works

Conventions go in once. They're in context forever.

You don't configure rules or maintain a linting config for Tenure. You capture decisions as they happen, in the same chat sessions where you already work. Tenure extracts them, stores them locally, and injects the right ones on every AI request, before the prompt reaches the model.

01
Capture

Decisions land in Tenure automatically

When you tell your AI "we use factory functions, not classes" or "don't use Mongoose, raw driver only", Tenure extracts that belief from the conversation. No extra step. It just works in the background.

// You say it once. Tenure remembers it forever.
02
Scope

Beliefs are scoped to projects, not globally polluted

The MongoDB convention for your API project doesn't bleed into your data pipeline project. Tenure scopes beliefs to workspaces, so every project gets exactly the context it needs. Nothing more.

03
Inject

Every AI request arrives pre-loaded with your conventions

Before the request reaches the model, Tenure injects the relevant beliefs automatically. The AI generating your code already knows your team's patterns, so PRs arrive closer to correct.

Before & after

What changes in code review.

Same AI tool. Same task. Different outcome when the AI has your conventions in context.

Without Tenure AI generated, no convention context
+ import UserService from '../../UserService'
+ export class UserController {
+ async fetchUser(id: string) {
+ try {
+ return await UserService.getById(id)
+ } catch (e) {
+ throw new Error(e.message)
+ }
+ }
+ }
reviewer We use factory functions, not classes. Also fetchUsergetUser per our conventions.
reviewer Errors need { code, message, context } shape. See AppError in /lib/errors.
reviewer This should import from the repository layer, not directly from the service. Check the architectural pattern doc.
3 review cycles. Fixed on third push.
With Tenure AI generated, conventions in context
+ import { makeUserRepository } from '../repositories/user'
+
+ export function makeUserController(db: Db) {
+ const users = makeUserRepository(db)
+ return {
+ async getUser(id: string) {
+ return users.findById(id)
+ }
+ }
+ }
reviewer LGTM. Factory pattern, correct naming, proper layer separation. Approved.
1 review cycle. Merged same day.
What Tenure actually is

Not a code reviewer. The memory layer that makes AI-generated code look like your team's code.

AI code review tools say:
"We'll catch the mistakes in your PR."

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 says:
"PRs move faster when AI already knows your conventions."

Tenure sits at generation time, before the code is written. The reduction in PR review time is a consequence of better-aligned output, not a bolt-on review step.

PR review time becomes a consequence of better code generation.

For teams

Shared memory means every engineer's AI starts from the same baseline.

When one engineer captures "we use Zod for input validation, not Joi", every other engineer's AI knows it too. Conventions propagate through the team without a style guide meeting, without a Confluence page nobody reads, without a linting rule that fires after the fact.

🏗️

Architecture decisions

Monorepo structure, layer boundaries, forbidden patterns, approved libraries. Stored once. Injected for every engineer on the project.

📐

Naming conventions

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.

🧩

Existing abstractions

The utilities, hooks, and services that already exist. AI stops reinventing them and starts using them because Tenure tells it they're there.

🚫

Rejected approaches

"We evaluated Prisma and ruled it out." That decision lives in Tenure too. Not just what you chose, but what you rejected and why.

Get started

Teach AI how your team writes code.

Free, open source, fully local. Works with VS Code, Cursor, Windsurf, Continue, Cline, and any OpenAI-compatible client.

Helm chart · OIDC / SCIM · MIT licensed · No call-home telemetry