# AI built the feature. How do you check it works?

A good-looking screen can still behave badly. If AI added bookings, try booking twice, picking a time that was just taken, and opening the booking from another account. You can describe these checks in everyday language and ask your coding AI to trace the relevant files. You don’t have to review every line yourself, but you should know what it checked and what it could not test.

The method below also applies to human-written changes. The useful difference is the evidence you collect, not who typed the code.

## Begin with one changed path

Imagine a fictional export service. A worker sends a completion callback and the new handler inserts a downloadable file record. The visible test sends one callback and passes. Nearby code says the worker retries after an acknowledgement timeout.

The review question is now specific: what happens when the same completion callback arrives twice? Read the storage operation, uniqueness rules and response handling. If the store already makes the operation idempotent, inspect its conflict path before declaring a bug. A duplicate insert might be a credible hypothesis; it is not a reproduced failure until a check establishes it.

![A behavior-first review reads the requirement, traces the path, tries a failure, records evidence, fixes the behavior and reruns the check.](/art/review-evidence-flow.svg)

## Write a finding a teammate can use

| Part | Useful detail |
| --- | --- |
| Starting condition | One synthetic export job has completed |
| Trigger | Deliver the same completion callback twice |
| Expected result | One durable file record for that job |
| Evidence | A reproduced fixture result, or a labeled code-derived hypothesis |
| Customer impact | Duplicate records or inconsistent download state |
| Regression | Same job remains single; a different job still creates a record |

Keep the location and relevant callers beside the finding. “Possible race condition” without a path or triggering sequence gives the author little to act on. Conversely, do not invent a race if the system contract and store operation prevent it.

## Look outside the edited function

The important behavior may sit in a caller, a serializer, an ownership check or a queue consumer that was not changed. A local diff cannot show a compatibility problem with an older worker unless you read that worker’s contract.

For private resources, examine the actual delivery paths, including the storage object or server-rendered page. A button hidden from another user is not the same as a server rejecting their request. Use known synthetic resources in a local or sandbox environment; do not enumerate customer IDs in production.

Existing CI results are useful evidence, but they have a scope. A mock-based adapter test is not a real payment transaction. A skipped browser test is not successful browser coverage. Keep those distinctions in the review instead of flattening every result into “tests passed.”

## Copy a review request

```text
Review this diff against its base revision and the supplied intended behavior.
Read the relevant callers, contracts and tests.
Prioritize concrete behavior, access and compatibility failures.
For each finding, provide starting conditions, a trigger, expected vs observed behavior and a focused regression case.
Label unrun reproductions as hypotheses.
Separate policy violations from style preferences.
Do not change code, post comments or merge unless that is part of my request.
```

## Check that the test can catch the problem

For the duplicate-callback example, the test should observe the durable result after both deliveries. An assertion that the handler calls a helper twice does not establish that duplicate fulfillment is prevented.

In an isolated fixture, demonstrate the check failing against the defect and passing with the correction. If that demonstration is unavailable, record it as untested. You can still provide a useful code review without overstating what the environment allowed you to verify.

Use [Code Check](/abilities/change-review) for the reusable finding workflow and [Change Tests](/abilities/regression-plan) to turn the observed risk into tests. For a review specifically about exposed access, the free [Privacy Check](/abilities/production-security-check) provides a scoped ownership and payment matrix.

---
SkillStall · 2026-10-04
OWASP: Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
GitHub: Secure use of Actions: https://docs.github.com/en/actions/reference/security/secure-use