The download includes the before, intentionally buggy and fixed JavaScript versions, their tests, a local verification script and recorded results. The CI workflow is a template; it has not been run in hosted CI.
Download verification examples (ZIP)Start with the behavior you need to preserve
Before reading the implementation, write down an observable outcome. For our designed example, two basic items priced at nineteen dollars each must produce an invoice total of 3,800 cents. Unknown product identifiers and negative quantities must be rejected. Those statements are a better starting point than asking whether a function looks clean.
Choose a boundary small enough to inspect: the changed module, its callers, an API handler and its authorization boundary, or a single state transition. Record what remains outside the exercise. If a change affects billing units, retry behavior or tenant ownership, name that risk explicitly rather than treating every edit as equally important.
Step 1: inspect the actual change and its consumers
Read the diff together with the surrounding code. Follow exported values into callers, inspect tests that describe the existing contract, and check configuration that changes how the code runs. A plausible implementation can be wrong because another file still expects the old return value, unit or error behavior.
In our example, the catalog changes from returning dollars to returning cents while retaining the name getUnitPrice. The unchanged invoice module still multiplies the result by one hundred. Both modules parse successfully. The failure appears only when the producer and consumer are considered together.
Step 2: run fixed checks and understand their scope
Use the project’s established parser, linter and type checker before adding a model. These checks are useful because the same rule and input can produce a repeatable diagnostic. Review the selected rules, exclusions and environment assumptions; a configuration intended for browser code may interpret a server-specific global differently.
AI Code Verify checks a pasted JavaScript, TypeScript or Python snippet locally in your browser. It does not upload the source, call an LLM, inspect a repository or execute your program. Use it for the checks shown by the tool, then continue in your own project for type checking, dependency analysis and behavior tests. A successful snippet report cannot resolve the catalog’s cross-file unit contract.
Step 3: derive test expectations independently
Write assertions from the requirement, not by copying the new implementation’s output. In the example, the expected 3,800 cents comes from nineteen dollars times two items times one hundred cents. If the same agent changes the calculation and rewrites the assertion to 380,000, the test can pass while the requirement has been lost.
Include at least one boundary or negative case that would expose a consequential mistake. Our fixture includes a second product price, an unknown product and a negative quantity. These are a focused demonstration, not a claim of complete invoice coverage. Real billing systems also need decisions about rounding, currencies, taxes, quantities and retries.
Step 4: reproduce a failure before accepting a fix
The companion example contains before, buggy and fixed versions. We ran the same four contract tests against each with Node.js v24.16.0 on 25 October 2026. Before passed four tests; buggy passed two and failed the two amount assertions; fixed passed all four. Each JavaScript module also passed a separate syntax check.
This result establishes that the designed defect is observable under these assertions and that the proposed repair satisfies them. It does not estimate any scanner’s accuracy, show that a model found the bug, or prove a production payment system safe. Preserve the failing output instead of hiding it in a screenshot of the final green run.
FIXTURE_VERSION=before node --test examples/cross-file-units/contract.test.mjs
FIXTURE_VERSION=buggy node --test examples/cross-file-units/contract.test.mjs
FIXTURE_VERSION=fixed node --test examples/cross-file-units/contract.test.mjsStep 5: check dependencies, external APIs and data boundaries
An import that parses may refer to a nonexistent API, an unsupported package version or a function with different error semantics. Check the official documentation for the version in the lockfile and inspect how credentials and user-controlled inputs reach the call. A dependency vulnerability scan answers a different question from whether your integration is correct.
For a change involving external effects, examine authorization, idempotency and cleanup. Ask what happens after a retry, partial failure or cancelled request. Our invoice fixture performs no network request and models none of those conditions; do not expand its result into a guarantee about them.
Step 6: ask for review findings that can be investigated
A reviewer should receive the original requirement, actual diff, relevant callers and current test evidence. Request a concrete trigger, affected location, consequence and suggested reproduction for each finding. Keep the first review read-only so a proposed fix cannot silently change the evidence before it has been assessed.
Separate a confirmed failure from a plausible hypothesis. In our fixture, an amount multiplied by one hundred twice is demonstrated. A claim that negative quantities are accepted is refuted by the existing guard and its test. Both conclusions need context; a confident sentence from a reviewer is not enough.
Step 7: make an explicit acceptance decision
After a repair, rerun the original assertions and relevant project checks against the same revision. Review changes to test assertions, scanner exclusions, CI configuration and acceptance criteria separately. A green result produced by disabling a required check is different from completing that check successfully.
For each accepted change, record the requirement, revision, completed checks, unresolved findings and approving owner. Authentication, destructive migrations and other consequential changes may need specialist review. The purpose is an auditable decision about a defined change, not a universal AI-verified badge.
Match each claim to its evidence
| Layer | Useful evidence | What remains outside it |
|---|---|---|
| Fixed static checks | Named rules and diagnostics for inspected input | Unmodelled behavior and missing project context |
| Behavior tests | Assertions executed against a specified revision | Inputs, integrations and assertions not exercised |
| AI-assisted review | Candidate findings with supporting context | A guarantee that all relevant defects were found |
| Formal verification | A machine-checked property under explicit assumptions | Unspecified properties or an unverified link to deployed code |
What to do when the report is clean
Read “no findings” as a statement about completed checks. A parse error, unsupported input or interrupted analysis is not a clean result. Identify which layer addresses your actual risk and add evidence there. For a unit migration, that means consumer contract tests; for an access-control change, it means identity and ownership tests at the relevant boundary.
Use the review checklist while making the decision. For changed code produced in Cursor or Claude Code, follow the independent-review guide. When the checks are useful and stable, move them into your own CI pipeline. The browser snippet checker remains a small starting layer of that workflow.
Our single-snippet static checker runs local fixed rules. It does not connect a repository, execute your tests, perform cross-file analysis or prove a program correct. Use it as one layer of the workflow.
Sources and editorial notes
Product capabilities can change. Links below are primary references used for this guide; examples are demonstrations unless explicitly stated otherwise. Suggest a correction.