> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/guides/validate-code-changes.md).

# How to Review your Code Changes

### Introduction

Reviewing your changes is the day-to-day loop. You change some code, Kerno re-runs the baseline tests for the affected endpoints, and tells you whether their behaviour moved.

In this guide, you will trigger a review, read the result, and bring the tests along when a change was intentional.

### Prerequisites

Before you begin, you will need:

* Baseline tests already generated for the endpoints you want to review. See Capture a baseline.
* Your application running with your changes applied.

### Step 1. Triggering a review

After changing code, ask your agent to review the endpoints your change affected:

```
Use Kerno to validate the endpoints my changes affected.
```

Kerno maps your change through the call graph to every endpoint it reaches, so a change to a shared helper is reviewed alongside the obvious ones. For each affected endpoint, it re-runs the baseline tests already on disk against your current code and reports where behaviour moved.

You can also review a single endpoint:

```
Use Kerno to validate POST /users.
```

If an endpoint has no baseline yet, there is nothing to compare against, so reviewing it simply captures a baseline for the first time. Read through what it captured to confirm the responses make sense, and fix your code if something looks wrong.

{% hint style="info" %}
If you configure the Kerno hook for your agent, each commit surfaces the endpoints your change affected, and your agent reviews them automatically as part of its loop.
{% endhint %}

### Step 2. Reading the result

When a review finishes, Kerno re-runs each baseline test against your current code and checks whether the response still matches the one the baseline recorded.

A diff is a difference between the response the baseline recorded and what your endpoint returns now. Kerno matches values that legitimately change between runs, such as generated ids, tokens, and timestamps, by their shape, so a fresh id or timestamp never counts as a diff. A field that appears where the baseline had none does count, even without an explicit assertion for it, which is how an accidentally leaked field, like an internal flag or a password hash, gets caught.

Each test comes back as one of three outcomes:

* **Passed.** No diff was detected. The behaviour this test covers matches the baseline, so your change left it unchanged.
* **Blocked.** The scenario never ran, usually because a dependency it needs is not configured. Nothing was tested. Kerno tells you what is missing, so you can ask your agent to fix it and run the review again. See Connect your app to Kerno.
* **Failed.** A diff was detected. The behaviour moved from the baseline. Kerno reports every assertion that did not match, each with a clue explaining what it was checking and a diff of expected against actual, so you see every change from one run.

A diff does not always mean something is broken. It only tells you the behaviour changed, and it is up to you to decide:

* **The change is a bug.** Fix your code and review again.
* **The change is intentional.** Your endpoint genuinely changed and the tests need to follow, so update the baseline (Step 3).

### Step 3. Updating baseline tests

Ask your agent to update when a diff is intentional, or when you have added logic that no test covers yet:

```
Use Kerno to update the tests for POST /users. 
The response no longer includes the role field.
```

Kerno reconciles the suite with your change:

* It re-baselines the tests that diffed, so their expectations match the new behaviour.
* It adds tests for new logic your change introduced that nothing covers yet.
* It keeps every test that still applies, and removes one only when you tell it that test is obsolete.

{% hint style="info" %}
When you add logic that none of the existing tests exercise, the review shows no diff. Ask Kerno to update the tests for that endpoint and it adds coverage for the new logic:

```
Use Kerno to update the tests for POST /users.
```

{% endhint %}

### Conclusion

That is the loop. Change code, review the affected endpoints, and update the tests when a change is intentional, so your baseline always reflects how your app should behave. From here, see Custom rules to shape how Kerno tests, and Memory and learning to see how it improves over time.