Validate code changes
Learn how to validate a code change with Kerno, understand the results, and keep your baseline current as your code evolves.
Validation is the day-to-day loop. After every change, Kerno checks which endpoints were affected, runs the relevant scenarios, and reports what changed against the baseline. When you confirm the results, your agent updates the baseline to reflect the new behaviour, adds scenarios for new endpoints, and removes ones that are no longer relevant.
Prerequisites
Before you begin, make sure you have:
A baseline captured for the endpoints you want to validate. See Capture a Baseline.
Step 1 — Run validation
After making a change, ask your coding agent to validate it:
"Use Kerno to validate the changes we made."
Kerno uses your git diff to detect which endpoints were affected, runs their scenarios against your live stack, and compares the results to the baseline. By default, only the endpoints touched by your changes are re-run.
If you want to validate a single endpoint, just specify it:
"Use Kerno to validate POST /users."
The default scope uses your working tree diff. If you have already committed your changes and there is nothing uncommitted, validation will return no endpoints. In that case, target the endpoint or file directly instead.
For a full breakdown of targeting options, see Scopes reference.
Step 2 — Review the results
For each scenario, Kerno seeds real test data, makes authenticated calls against your live stack, and validates the full response contract including field presence, types, and structure against the baseline. It catches things basic status checks miss: a field that silently changed type, an auth rule that stopped being enforced, a response that looks right on the surface but breaks a downstream consumer.
After running, Kerno reports whether a diff was detected. A diff is not necessarily a problem — it just means the endpoint's behaviour changed. You decide whether that was intentional.
No diff detected. The endpoint behaves exactly as the baseline recorded.
Diff detected. Your agent will summarize what changed in plain language, for example "the role field was removed from the response" or "the status changed from 200 to 401".
If an endpoint has no baseline yet, Kerno captures one automatically. You will see the current behaviour of your code with no diff as there is nothing to compare against yet
Note: Kerno ignores differences that don't affect behaviour: key ordering, array element ordering, and numeric precision differences. Dynamic values like tokens, UUIDs, and timestamps are also ignored since they change on every run.
Resources
Last updated