An AI has written a function that looks plausible, but you can’t yet explain its fallback or failure behavior. Select that code in Yenpo, ask a model you choose to explain it, and check each claim beside the source before relying on it.

You need Yenpo, a local project, and access to a provider with a supported API. You can use a different model from the one that wrote the code.

1. Connect your model

Open Settings → “Models,” click the plus button to add a provider, and select it as the “Current provider.” Enter the API type, “Base URL,” “Sign-in method,” and the exact model ID your provider supports.

Yenpo offers three API types: “OpenAI Compatible” (OpenAI Chat Completions), “OpenAI Responses,” and “Anthropic Messages.” Match the API type to the service; a model name alone doesn’t identify the protocol. “Fetch List” is optional: you can enter a model ID directly if the service doesn’t publish a list.

Put API keys only in Settings. Start with code you’re allowed to send to that provider. A request can include relevant code the AI Reader finds beyond your selection; see data and permissions. The model connection guide covers endpoint paths and connection errors.

2. Attach the code you want explained

Open the file and select the function or a small block. Start a new AI Reader conversation and choose “Explain Selection.” Check that the attachment names the intended file and lines, then edit the prepared question before sending. Keep “Allow Edits” off for this reading session.

Use a question that asks for checkable details:

Explain this selection in execution order. For each branch, give the input or state that reaches it, the returned value, and any side effect. Cite the exact source lines for each claim. Read callers or tests where needed, and distinguish what the code shows from assumptions about runtime inputs. Do not edit files.

The selection gives the model a starting point. If you need to understand an older change, open the relevant Git comparison and ask about that comparison instead of assuming your current file still matches it.

3. Check each source reference

Click a reference in the answer to open the cited lines in “Quick Look.” Use “Open File” when you need the surrounding condition or caller. Work through the explanation one claim at a time:

  1. Check the path, line range, and code version.
  2. Read the condition before the cited operation.
  3. Follow the value into the caller if the answer makes a claim about what users see.
  4. Mark claims without enough code or runtime information as unresolved.

To support “this result always wins,” check which paths reach the cited assignment and whether anything can write the value afterwards.

4. Try a small line-by-line example

Suppose an AI wrote this JavaScript function in a teaching project:

function displayName(user) {
  if (!user) return 'Guest';
  const name = user.name?.trim();
  return name || 'Guest';
}

Numbering from the first line of this snippet, check an explanation against these locations. In your project, use the file’s actual line numbers.

Claim to check Lines to inspect What the code supports
A missing user gets the fallback 2 Any falsy user, including null or undefined, returns "Guest" before the name is read
Whitespace-only names get the fallback 3–4 Trimming a string of spaces produces "", then the fallback is returned
Every malformed input is safe 3 A non-string name such as 42 throws a TypeError because it has no trim method

That last claim needs correction. Optional chaining handles a null or undefined name here; it doesn’t validate all possible types. Read the caller or input validator to learn whether a number can reach this function.

5. Challenge the explanation and run a check

If the answer overstates what the snippet does, follow up with:

Recheck the claim that all malformed inputs are safe. What happens when the name is a number? Cite the operation that would fail, then find whether a caller or validator prevents that input. If you can’t find one, leave it unresolved.

For this example, check a missing user, a whitespace-only name, a normal name with outer spaces, and a numeric name. Run the smallest appropriate test in your project’s test runner and read its result.

Keep the file stable while checking references. If it changes, reselect the updated code and ask again so you aren’t matching an old explanation to new line numbers.

6. Save what you now understand

Write a short note with the function’s input assumptions, branch behavior, checked source locations, and tests you ran. Include unresolved questions such as where input validation happens. This is more useful for the next review than keeping an explanation you haven’t checked.

Apply the same method to a Claude Code turn or a Codex branch review whenever a changed block needs closer reading.