Understand the code your coding agent wrote: 6 questions to ask it

Your coding agent built the app, the screen works, and you can't explain what happens after someone taps the button. When it breaks or a client asks for a handoff, that gap can leave you stuck. These questions help you turn the code into something you can explain, check, and maintain.

Start with one feature and ask the agent to trace its path, explain the changed files and dependencies, identify assumptions and errors, and quiz you. Then read the cited code and test the answers yourself. Save what you learn in a short NOTES.md so the next person has a starting point.

Start with the request path

"It works" tells you what you observed under the conditions you tried. It doesn't tell you where to look when a different input fails, what to tell a client about an integration, or which file to hand to the next developer.

Pick one action: submitting a form, saving a setting, or loading a page. Give the agent the feature's name and ask it to use the actual project files, not a generic explanation.

Question 1: What happens from the user's action to the result?

"Walk me through what happens when a user submits this form. Start at the button, follow the data through each function and file, and end at what the user sees. Cite the relevant paths and lines. Say when you can't verify a step."

Ask for a plain-language answer first. Then follow the path yourself: find the button, the function it calls, and the next step. Depending on the app, the path might stay on the device or include a network request. Don't assume there's a server just because the explanation mentions one.

This works best in a harness that can open the whole project and cite real paths. If you don't have one yet, you can try the zcode agent harness free.

Find the changes and their dependencies

Question 2: Which files changed, and why?

"List every file changed for this feature. For each one, explain what changed, why it was needed, and which part of the feature uses it. Separate files you changed from files you only read."

If the project uses Git, check the answer against the actual changes. git status --short --untracked-files=all lists tracked changes and individual untracked files. git diff HEAD shows tracked, uncommitted changes against the latest commit; it does not show untracked file contents. The official docs cover both: git status and git diff.

If the work was already committed, compare the appropriate earlier commit with the current one instead. Confirm that starting point before treating the diff as the complete feature. Open any relevant untracked files separately.

Question 3: What does this code depend on?

"List the dependencies used by this feature, including imported packages, project modules, configuration, and external services. For each, show where it is used and what would fail or change without it. Mark anything you can't confirm."

Check the imports and configuration the agent cites. Ask it to distinguish a package the feature calls directly from a dependency it merely found in a manifest. If a service is involved, note what the app sends and what response it expects, without copying credentials into your notes.

Expose assumptions and failure paths

Question 4: What is the code assuming?

"List the assumptions this feature makes about its inputs, configuration, and environment. For each, cite the code and give an example that could challenge it. Identify which examples have tests and which do not."

For a form, look at empty input, unexpected characters, and missing fields. For a saved setting, ask what happens when no previous value exists. The goal isn't a long list of scary possibilities; it's a short list tied to the code you're shipping.

Question 5: Where are errors handled?

"Show me where this feature detects and handles errors. Trace what happens to the error and what the user sees. Point out paths where you found no handling, and cite the relevant code."

Read both the operation that can fail and the code that handles the failure. A message on screen, a log, and a retry are different outcomes. Check which ones the app actually has rather than accepting "errors are handled" as an answer.

None of these questions cost much to ask, so ask them every time a feature lands, not only when something breaks. If you're picking a plan for that kind of daily use, there's 10% off GLM coding plans.

Let the agent quiz you

Question 6: Can I explain it back?

"Quiz me on this feature without giving the answers first. Ask about the request path, changed files, dependencies, assumptions, and error handling. After each answer, tell me what I missed and cite the code."

Answer in your own words. If you can explain where the input goes and where you'd look when it fails, you have a useful starting map. If you can't, ask the agent to narrow the explanation to the part you lost.

A useful follow-up is: "Give me a client-friendly explanation of this feature, then list what that explanation leaves out." Compare it with the code before using it in a handoff. Don't promise behavior that you haven't checked.

A quiz checks your understanding of the explanation; it does not prove the explanation is correct. That still takes a look at the code and a relevant test.

Check the answers against the app

An agent can give a confident answer that is wrong. The US National Institute of Standards and Technology calls this "confabulation": "the production of confidently stated but erroneous or false content" (NIST AI 600-1).

Pick a claim you can check. If the agent says an empty form shows an error, read the cited condition and try that input in a safe test environment. Run the relevant existing test, if there is one, and read what it actually checks. A passing test is evidence for the behavior it covers, not every possible case.

If the path is still unclear, add a temporary log at the point you're investigating and trigger the action. In a Node.js app, a console.log line does the job (Node.js console docs).

Log a harmless marker or sanitized value, not passwords, tokens, or client data. Remove the temporary log afterward and check your diff so you know it's gone. If the result differs from the agent's answer, show it the evidence and ask it to explain the mismatch.

Leave a map in NOTES.md

Write down what you verified, what remains uncertain, and how someone can repeat the check. Keep paths specific to your project. Don't put secrets in the file.

Copy and fill in this template:

# Feature notes

Feature:
What the user does:
What should happen:

Request path:
- Start:
- Important files and functions:
- Result:

Dependencies and configuration:
- Name, purpose, and where used:

Assumptions and edge cases:
- Assumption:
- What happens if it is false:
- Tested or still unknown:

Error handling:
- Where to look:
- What the user sees:

How I checked:
- Code read:
- Test or action run:
- Result:
- Remaining questions:

Use "unknown" when you haven't checked something. That gives the next person a useful boundary instead of a polished guess.

There's more on our blog about working day to day with coding agents.

Checklist

• Can I trace the feature from the user's action to the result?
• Did I check changed and untracked files against the agent's list?
• Can I explain the dependencies and the assumptions that matter?
• Did I find what happens when the feature fails?
• Did I read the cited code and run a relevant safe check?
• Does NOTES.md separate verified behavior from open questions?

If this saved you a confused afternoon, a small tip on the post keeps these guides coming.