Guide
Use AI to build a code-reading hypothesis, then verify it
An explanation is valuable when it points you to the next file, test or runtime check—not when it hides uncertainty.
By Cernalo · · 8 minute read
Begin with the boundary
Identify what enters the code, what leaves and which side effects are possible. Ask the assistant to describe only the visible path and to mark dependencies it cannot inspect.
For a handler, that may mean the request shape, authorization check, database call, response and error path.
Trace one example
Choose a concrete input and walk it through each branch. Examples reveal ambiguous conditions and conversions that a broad summary can miss.
If the explanation assumes a type or configuration, open the definition and verify it before continuing.
Look outward to callers and tests
A function's name rarely describes every contract. Call sites show how values are prepared and which outputs matter. Tests reveal expected boundaries and may expose intentional behavior that looks unusual in isolation.
Ask for search terms or file roles to inspect, but use your repository tools to confirm the result.
Use runtime evidence
Logs, stack traces and a reproducible input can disprove an attractive explanation. Ask the assistant what observation would distinguish each candidate cause, then collect that observation.
Avoid adding broad logging that exposes secrets or customer data.
Write down the verified model
After testing, summarize the behavior in your own words and link it to the relevant code or test. This leaves the team with verified knowledge instead of an untraceable AI answer.