> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usebench.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Validate a change

> Check that an improvement fixes the problem without breaking working behavior.

## Copy this into your coding agent

Paste into Cursor, Codex, Claude Code, or another coding agent in your project.

```text theme={null}
Validate this change using https://docs.usebench.ai/guides/validation.
Run the original and changed app against the same cases, expected results and rules.
Use isolated test data. Cover the original failure, working behavior and independent cases.
Check actual tool effects as well as answers. Keep missing evidence marked incomplete.
Show which cases improved or regressed and whether the evidence supports shipping the fix.
```

## Keep the comparison fair

Run the original and changed application against the same inputs, expected outcomes
and rules. Record the code versions. If you change the rules, treat the result as
a new baseline rather than claiming the code improved against the old one.

## Include the cases that matter

* **Capability:** a supported task your app should complete.
* **Regression:** behavior that already works and must keep working.
* **Incident:** a specific failure seen in production.
* **Independent cases:** examples that were not used to create the fix.

Use [the test library](/guides/test-library) to keep representative examples and
expected results. Include boundary values, missing details and multi-turn requests.

## Check actions as well as answers

A refund assistant can say it refunded 120 while its retry logic actually refunds
240\. An real app test should check the recorded amount, not just the reply.

Test timeouts, retries and partial failures with test accounts and controlled
dependencies. Do not send real refunds or messages while testing these scenarios.
[Real app testing](/sdk/system-evaluation) run your application code and record its
instrumented actions. Missing evidence is an incomplete result, not a pass.

## Review the proposal

Compare the failed and passing cases, quality, model usage and estimated cost.
Reject changes that fix one case by breaking an established rule. For subjective
checks, inspect the evidence and review representative results yourself.

A proposed fix does not change production. Review the pull request, run your normal
release checks and monitor the result after deployment.