Kody Tips #7 – Memories vs Kody Rules

Stop using Review Rules for things that should be Memories

Most teams using AI code review reach for custom review rules first.

That makes sense when the goal is enforcement.

If your team has a standard that every PR must follow, a Rule is the right tool.

But not every bad AI code review suggestion means you need another rule.

Sometimes Kody is not missing a standard.

It is missing context.

That is where Memories come in.

Memories help Kody understand how your codebase works, so future pull request reviews get better over time. They are especially useful when Kody keeps making the same low-value suggestion, misunderstanding a pattern, or creating false positives because it does not know the reasoning behind the code.

For example:

• this repo mirrors a third-party API, so some payload fields intentionally stay snake_case
• tests in this service live next to the implementation files
• the billing module is mid-migration, so prefer incremental fixes over broad refactors

That kind of information should not be a Review Rule.

It belongs in a Memory.

Why?

Because the goal is not to flag a violation.

The goal is to teach Kody the missing codebase context so it stops making the wrong assumption in future AI code reviews.

Rules do the opposite job.

Kody Rules are for standards you want Kody to explicitly enforce during pull request review.

For example:

• every new endpoint must include tests
• domain code must not import infrastructure
• changes to shared exports require a changeset

A simple way to think about it:

Use Memories to teach context.
Use Rules to enforce standards.

If Kody keeps giving the wrong suggestions, do not start by adding another Review Rule.

Teach Kody one Memory in your next PR:

@kody remember: this repo mirrors a third-party API, so some payload fields intentionally stay snake_case

Prefer the UI? Create it directly in Kodus.