Concept L2 · Context engineering informational

Ask for the Cause Before the Fix

What it is

A sequencing habit: ask ChatGPT to explain why the bug happens before it proposes a fix, and only accept the fix once the stated cause makes sense.

diagnose, then treatSymptomAsk: what's the cause?Confirm cause, then fix
A named cause prevents a fix that just moves the symptom.

Why it works

Jump straight to 'fix this' and you often get a change that suppresses the symptom — a try/catch around the crash, a guard that hides the null — without addressing why it occurred. Forcing a diagnosis first surfaces the real mechanism, so the fix treats the disease instead of the fever, and you learn something reusable.

When to use it

Bugs where the cause isn't obvious, recurring issues that keep coming back after 'fixes', and anything where a band-aid would mask a deeper problem.

When not to use it

Trivial, self-evident errors (a typo'd variable, a missing import) where the cause and fix are the same thing and diagnosis is ceremony.

Prompt

Here's the bug: <repro / error>. Before suggesting any fix, explain what's actually causing it and why it manifests this way. Once I confirm the diagnosis makes sense, then propose the fix.

Example

Asked for the cause of intermittent test failures, ChatGPT identifies a shared global mutated between tests — the real fix is isolation, not the retry-loop band-aid you'd otherwise have accepted.

Common mistakes

  • Accepting a fix that hides the symptom without understanding the cause.
  • Applying fix after fix to a recurring bug whose mechanism you never pinned down.
  • Skipping the 'does this cause make sense?' check and trusting a plausible story.

Related