Show, don't tell

There’s a faster way to communicate a problem to Claude than describing it in prose: hand Claude the actual artifact.

If you can show the bug, show it. Description is the slow lane.

This is the move that turns 30-minute debugging sessions into 30-second ones — when you stop translating the problem into English and just paste the evidence.

The three artifacts worth pasting

In order of how often they pay off:

1. Error messages — full text, full stack trace.

Don’t summarize. Don’t paraphrase. Copy the whole error message, including the file paths and line numbers in the stack trace. Those are clues. Claude can read them.

Bad: “I’m getting some kind of null error.”

Good: paste the actual error.

TypeError: Cannot read properties of undefined (reading 'name')
    at UserCard.render (src/components/UserCard.tsx:14:32)
    at processChild (react-dom.js:2841:18)

The line number alone is sometimes the whole fix.

2. Failing test output.

If a test is failing, paste what it says. Test output usually includes both the expected and the actual values — both are critical context Claude can’t otherwise know.

Bad: “the user test is failing”

Good: paste the assertion and the diff between expected and actual.

3. Screenshots — for anything visual.

Layout broken? Spacing wrong? Color off? Words don’t help here. Screenshots do. Claude Code accepts images — drag one into the terminal or reference its path.

Bad: “the sidebar looks weird on mobile”

Good: a screenshot of the broken sidebar.

Why descriptions fail

When you describe a bug, you’re doing two translations: code → your understanding → your words → Claude’s reading → Claude’s understanding → fix. Each step loses fidelity. By the time the prompt lands, “the button is offset slightly” could mean a hundred things.

When you paste the artifact, you skip all of that. Claude sees what you see.

The mindset

If you find yourself writing a paragraph that begins with “it looks like…” or “I think the error is…” — stop. Don’t think. Don’t theorize. Paste the thing.

Save your descriptions for what an artifact can’t show: intent. “I want this to fail gracefully instead of crashing” — that’s a description worth writing, because no artifact in your terminal contains that idea.

What’s next

Everything so far has been about single changes — one file, one feature, one fix. The next lesson is the unlock: changes that span the whole codebase. The kind humans dread and Claude eats for breakfast.