When AI goes wrong: a practical recovery guide
Choose the problem you see, collect useful evidence and try a bounded recovery for invented facts, missing files, broken code or repeated failures.
The next useful move is usually more specific than “try harder.”
A failed result is information. Save the request, the expected behavior and the actual outcome before asking for another attempt. The recovery picker below gives you a starting request; the steps that follow explain how to use it without repeating the same mistake or discarding work that was already useful.
Describe the mismatch, not just your frustration
Write one sentence about the expected result and one about what happened. “The filter should show two records for gardening, but it shows all five” is a reproducible problem. “The app is bad” might be a reasonable feeling, but it does not identify the next change.
Preserve the exact error text where available. Include the input, the step that triggered the problem and whether it happens consistently. For a writing task, quote the sentence that violates your intended meaning and explain what the reader should understand instead.
For factual work, isolate the claim that appears wrong. Ask for the supporting passage and inspect it yourself. Do not let the assistant replace a fabricated detail with another unsupported detail merely because the revised prose sounds more careful.
Keep the repair smaller than the whole project
Ask for one observable correction while naming the parts that should remain stable. Broad rewrites can remove details you already checked and introduce new problems. If the underlying design really must change, ask why the smaller repair is insufficient and what evidence supports the larger change.
When instructions conflict, resolve the conflict explicitly. An example may imply a different format from your written request. An old project note may name a command that no longer exists. The useful repair is to correct the conflicting source, not to keep adding louder instructions at the end of every message.
For code, reproduction comes before confidence. Repeat the action that failed after the change. Then check the neighboring behavior that could reasonably have been affected. Do not demand an unrelated exhaustive test run for every small edit, and do not call the task complete while the original failure remains.
Separate a missing input from a product limitation
If the assistant cannot find a file, confirm how the file was supplied. A filename in a message is not the same as an upload. A connected source may be unavailable to the current conversation. Ask what was actually opened and what access step is missing.
If you hit a limit, identify what is limited: usage, upload size, the current conversation, a tool or an account feature. Changing models does not necessarily remove the limitation. Export useful work before resetting a conversation or moving to another environment.
Do not purchase another subscription in the middle of an unclear failure. First determine whether the missing capability is documented for the plan you are considering. A short, harmless trial with your actual kind of task is more informative than a general promise of greater intelligence.
Decide whether paying would help
Stop a loop when it stops producing evidence
Ask for the distinct attempts and their observed outcomes. If the next proposal repeats an unchanged action against the same failure, pause. A different source, a smaller test case or direct human knowledge may be needed.
Leave a recoverable state: keep originals, name the last usable output and record the unresolved issue. Stopping an unproductive approach does not mean losing the entire project. A good handoff makes it possible to resume with a better question or another person.
A request you can adapt
Summarize the distinct attempts, their observed outcomes and the unresolved cause. Identify one new piece of evidence that would change the next decision. Preserve the last usable output and give me a short handoff.
Take this into your next task
A better retry changes the evidence or the approach. If neither changes, pause and narrow the problem.
Sources and editorial notes
Reviewed 2026-09-06. Product capabilities depend on the app, plan, region and workspace settings. Workflows and prompts are authored teaching material, not recorded model results or measured time-saving claims.
Keep going
- AI Essentials: Context, Memory, Sources and Finished Work
- Debugging and Testing with Codex
- AI Mission Control: From Idea to Verified Result
Find your next useful step
The answer invents facts
Separate the claims from the prose. A confident correction is still another claim until you check it.
Request: List the decisive claims in your answer. For each, give the source and relevant passage, or mark it unsupported. Do not replace a missing source with a plausible one. Revise the answer to match only checked evidence.
Check it: Open the decisive sources yourself. If access fails, keep that limitation in the result.
It ignores what I asked
Check whether the goal, constraints and examples disagree. Reduce the next request to one observable change.
Request: Keep [UNCHANGED PART] exactly as it is. Change only [SPECIFIC PART] so that [OBSERVABLE RESULT]. Before editing, identify any conflict with the instructions already supplied. Do not broaden this task.
Check it: Compare the actual change with the original. Confirm the protected part stayed intact.
The code does not work
Collect the exact error and the shortest steps that reproduce it. A screenshot of an error may omit useful text.
Request: The expected result is [RESULT]. I did [STEPS] and got [EXACT ERROR]. Inspect the relevant code, explain the cause and make the smallest fix within the approved workspace. Reproduce the original failure, then check the fix and report anything you could not run.
Check it: Repeat your original action. A successful build alone does not verify the interaction.
It cannot find my files
An attachment, a connected source and a folder on your computer are different access arrangements.
Request: Before proceeding, list the material available to this task and distinguish files you actually opened from names or links you can merely see. If [FILE] is unavailable, explain the specific access step needed. Do not invent its contents.
Check it: Compare the inventory with what you intended to share. Avoid widening access to unrelated folders.
I ran out of usage or context
A usage allowance and a full conversation are different limitations. Preserve the work before changing environments.
Request: Prepare a compact handoff: objective, exact current files, decisions, completed checks, known failures and next action. Mark anything not verified. Do not describe planned work as completed.
Check it: Save actual output files too. In the next conversation, confirm which files the assistant can open.
It keeps trying without progress
Another identical retry usually adds little evidence. Pause and identify the repeated blocking condition.
Request: Pause repeated attempts. Summarize the last distinct approaches, the observed failures and what new evidence would distinguish their causes. Propose one bounded diagnostic step. Ask me only for information or authority that actually blocks that step.
Check it: If the next step repeats an unchanged failure, stop and seek different evidence or human help.
Related Power of AI pages
Keep reading with Start here, everyday uses, the tool guide, the writing workshop, and sources and standards.