How to use AI to understand your code (not just write it)

Most people use AI tools to write code. Ask it to build a feature, it builds it. Ask it to fix a bug, it fixes it.

That's useful. But there's a more valuable use that most people working outside a traditional development background miss entirely:

Using AI to understand what you're looking at.

Not to fix it. Not yet. Just to understand it.

This one shift - from "AI as code writer" to "AI as code explainer" - changed how I build more than any tool or workflow I've found. It's the thing that turned the terminal from intimidating to readable, SQL errors from panic-inducing to diagnosable, and TypeScript from a wall of red lines to something I could follow.

The problem with asking AI to fix things you don't understand

When something breaks and you paste the error into Claude and say "fix this," one of two things happens:

The fix works and you learned nothing. The next time the same type of error appears, you're back to zero.

The fix doesn't work and now you're in an infinite loop of pasting errors and getting fixes that break other things, because neither you nor the AI has properly understood what's actually wrong.

The diagnosis-first rule I've written about before applies here: understand before you fix. And the way you understand is by asking AI to explain, not repair.

The three-step pattern

For almost any situation where I'm confused by my code, I follow the same pattern:

Step 1 Show it, don't describe it. Paste the exact error, the exact file, the exact output. Don't summarise. Don't paraphrase. Copy and paste the raw thing you're looking at.

Step 2 Ask for explanation, not fix. Explicitly say: "Explain what this means. Do not suggest a fix yet."

Step 3 Confirm understanding before acting. Once Claude explains it, ask: "Does that mean [your interpretation]?" Get confirmation that you've understood it correctly. Then, and only then, ask for the fix.

This pattern takes longer. It's worth it. After fifty iterations of it, you start recognising error patterns, understanding why they happen, and sometimes fixing them yourself before you even ask.

Specific prompts for specific situations

When you have an error message you don't understand

I'm seeing this error in my terminal / console / browser:

[paste the full error]

Explain what this error means in plain English. 
Tell me which part of my code is causing it and why.
Do not suggest a fix yet.

When a file confuses you

Here is a file from my React/Supabase project:

[paste the file]

Explain what this file does, what its purpose is in the project, 
and how it connects to other parts of the app.
Use plain English — I'm not a developer.

When a SQL query returns unexpected results

I ran this SQL query in psql:

[paste query]

And got this result:

[paste result]

I expected [describe what you expected].
Explain why the result might be different from what I expected.
What might this tell me about my data or my database setup?

When you don't understand what changed in a diff

Here is a git diff showing what changed in my code:

[paste diff]

Explain in plain English what changed, why it might have been changed, 
and what effect this change would have on how the app behaves.

When Chrome DevTools shows something unexpected

I'm looking at this network request in Chrome DevTools:

URL: [paste URL]
Status: [paste status code]
Response: [paste response body]

I expected [describe what you expected].
Explain what this response means and what might be causing it.

When TypeScript shows red lines you don't understand

TypeScript is showing this error in my code:

[paste error]

This is the code it's pointing at:

[paste code]

Explain what TypeScript is complaining about in plain English.
Why does TypeScript care about this? What is it trying to prevent?

When you want to understand a pattern or concept

I keep seeing this pattern in my codebase:

[paste code pattern]

Explain what this pattern is, why it's used, and what it's doing.
Give me an analogy that would make sense to someone who isn't a developer.

When something works but you don't know why

This code is working correctly but I don't fully understand why:

[paste code]

Explain step by step what this code is doing.
What would happen if I removed [specific part]?

The "teach me, don't fix me" prompt

This is the single most useful prompt I've developed. When I'm genuinely lost, when something is broken and I have no idea where to start, I use this:

I'm trying to debug an issue with my app.

Here's what's happening: [describe the symptom]

Here's what I've already checked: [list what you've looked at]

Here's the relevant code: [paste files or sections]

I don't want you to fix this yet. I want you to help me understand 
what might be causing it. Walk me through the likely causes, 
explain what each one means, and tell me what I should look at 
next to narrow it down.

This prompt forces structured diagnosis. Claude works through the problem systematically, explains each possibility, and points you at specific things to check. By the end you usually have a clear picture of what's wrong and often you've already found it.

How to use it with your actual tools

With psql output — copy the exact output from your terminal. Paste it. Ask what it means. The raw output is always more useful than your description of it.

With git diff — when Claude Code or Codex makes changes and you're reviewing the PR, paste the diff and ask for a plain English summary of what changed and why it matters. This teaches you what the code was doing before and after.

With Chrome DevTools — when a network request looks wrong, right-click the request, copy as cURL or copy the response. Paste it and ask what it means.

With error messages — never summarise error messages. Always paste the full thing, including the stack trace. The stack trace tells Claude exactly where in the code the error originated, which makes the explanation much more accurate.

What this actually builds

Using AI as an explainer rather than just a fixer builds something that prompting alone never does: a mental model of your own codebase.

After six months of asking Claude to explain things before fixing them, I understand:

• What TypeScript errors are actually telling me

• Why RLS policies cause silent failures

• What a Promise is and why it can be undefined

• Why async/await matters

• How React's component lifecycle affects data fetching

• What a foreign key constraint does and why it matters

None of that came from Claude writing code for me. It came from Claude explaining code to me over and over, in plain English, connected to things I was actually looking at in my actual project.

That's the difference between having an AI that codes for you and having an AI that teaches you while it codes. The TNDD workflow is built around the second one.