Ask a Coding Assistant to Explain Unfamiliar Code

Choose one behavior you want to understand

An unfamiliar project can tempt you to ask a coding assistant to explain everything. That usually produces a broad summary, not a useful mental model. Start with one observable behavior: how an order gets submitted, why a request retries, or where a validation error originates.

For this walkthrough, imagine you are investigating an order submission function that sometimes appears to run twice. Your first prompt could be: “Help me understand how this function submits an order and when it might retry. Explain only; do not modify the code.” You have now defined both the question and the boundary.

Share the smallest useful slice of context

Provide the function, its imports, and any nearby definitions needed to read it. Add one sentence about what you already know, such as: “I understand asynchronous functions, but I am unfamiliar with this project's retry helper.” This helps the assistant spend its explanation on your actual knowledge gap.

Remove credentials, personal data, and sensitive business information before sharing anything. If your coding assistant can inspect the repository, ask it to read only the relevant function and direct dependencies first. Repository access does not make reading everything necessary or economical.

Request a map before a detailed explanation

Begin with structure rather than a line-by-line commentary. Ask: “Summarize the purpose, inputs, outputs, external effects, and direct dependencies in five short paragraphs. Separate what the code shows from what you are inferring. Name any missing definitions that prevent a confident explanation.”

For the order example, this should reveal whether the function validates data, calls a service, updates local state, or delegates retry behavior elsewhere. If the assistant confidently describes a helper whose implementation it has not seen, ask it to mark that description as an assumption. A plausible name is not evidence of behavior.

Trace one concrete execution through the function

Next, supply a small hypothetical input in ordinary language. For example: “Assume the order is valid and the first submission attempt receives a temporary service error. Walk through the execution in order. Identify each branch taken, each awaited operation, and any state that changes.”

Ask the assistant to distinguish the initial attempt from subsequent attempts. This matters because “three retries” and “three total attempts” describe different behavior. Request references to function names and relevant conditions so you can compare the explanation with the source rather than trusting the narrative alone.

Inspect only the dependency that blocks understanding

If the retry rules remain unclear, provide the retry helper next, not the entire service layer. Ask: “Using this definition, revise your earlier explanation. Which errors trigger another attempt, what stops the loop, and does the helper itself prevent duplicate submissions?”

This follow-up can expose an important distinction: retrying a request does not necessarily make it safe to repeat. The code might rely on a request identifier or a remote service guarantee. Ask the assistant to state what remains unknown instead of assuming that a familiar retry pattern prevents duplicate orders.

Check the explanation against tests and counterexamples

Now ask for predictions you can verify: “What would happen if validation failed, the first attempt succeeded, or every attempt failed? Identify existing tests that support your answers, and distinguish tested behavior from untested possibilities.” If tests are unavailable, ask for proposed test cases, clearly labeled as proposals.

Read the relevant conditions yourself and, where practical, run existing tests in a safe local environment. Do not treat a fluent explanation as proof. If the assistant's account conflicts with the implementation, narrow the question to that specific mismatch before requesting more detail.

Stop when you can explain the behavior yourself

Finish by asking for a brief recap of the execution flow, remaining uncertainties, and next source to inspect. Then try explaining the function in your own words. If you can describe its normal path and failure path, another long response may add little value.

MyRelay's per-request token and cost visibility can help you see whether these focused follow-ups cost less than repeatedly sending broad context. Create a MyRelay account if you want to track that spending across supported coding tools. Keep your final explanation as a short personal note so your next investigation starts with verified understanding, not another full reread.