Brain ScannerCodebase impact analysis · Worked example
Before changing a shared helper, find the callers.
An AI agent proposes a validator change. Which public behaviors need another look? Follow one small example from a saved graph back to the source.
This exercise uses p-limit v7.3.2 at a fixed revision. We inspected an owner-controlled test map through Brain Scanner in Codex, then checked the recorded relationships against the source. It is a product demonstration, not a customer result.
Start with one behavior question.
p-limit limits how many asynchronous operations run at once. Its validateConcurrency helper checks the requested limit. Before changing that check, ask where an invalid value could enter.
limitFunction()creates a limiter throughpLimit()checks its input withvalidateConcurrency()validates the requested limit
The first impact query for validateConcurrency returned its immediate caller, pLimit. A second query for pLimit exposed the wrapper and related test nodes. One query did not enumerate every transitive impact.
Check the source: initialization · function wrapper
Check the individual call sites in source.
The source also calls the validator from the concurrency setter, before changing an existing limiter’s limit. The saved map records a call from pLimit to the validator, but does not distinguish initialization from the nested setter call site. That function-level relationship may represent both calls.
Turn the paths into a review checklist.
- Review limiter creation through both
pLimitandlimitFunction. - Review changes to an existing limiter’s
concurrency. - Check zero, negative values, fractions, missing values, positive integers, and infinity.
- Compare the intended behavior with the existing invalid-concurrency tests, then run the relevant tests before accepting a change.
In our later checks of this unchanged revision, 23 upstream runtime tests, the type tests, and 47 supplemental assertions passed. The combined npm test command failed at its lint stage. That is a mixed result, not a fully passing test suite. Read the commands, environment, and full results.
Try one helper in your own project.
Choose a small public project or one you are permitted to inspect. Create a beta account, confirm your email, and connect a compatible coding agent. Website sign-in and the agent’s authorization are separate steps.
Open the project in your agent and replace the bracketed text in this prompt:
Map this project in Brain Scanner, starting with [function or file]. Show its recorded callers and relevant tests, then inspect the callers of its immediate caller. Compare the relationships with current source. Identify one affected public behavior, one relevant test, and any missing call sites. Report the saved graph version and open the saved graph. Leave source code unchanged. Save project metadata only; exclude source-file contents, raw diffs, logs, and secrets.
Judge the result by whether it gives you a useful, source-checked review checklist. Mapping and local access depend on your agent’s supported tools and permissions. This example reused existing Codex authorization; it does not establish a fresh setup time or compatibility with every client.
Stuck? Ask for help with your first map. Tell us your client and the step you reached. Keep private code and credentials out of the message.
Inspect the evidence.
The complete demonstration also documents partial retrieval of earlier review context, including a withheld field and a missing next action. We have not measured time savings or shown that every dependency is captured.