Someone tries an AI model, asks it to do something useful, and doesn't like the answer.
Maybe the writing is bland. Maybe the code doesn't compile. Maybe the model misunderstands the assignment, ignores an important instruction, or gives an answer that sounds confident but doesn't hold up.
The person gives it another try or two, gets more of the same, and reaches a perfectly understandable conclusion:
This thing isn't ready for what I need.
That may have been a fair conclusion on the day they reached it.
The mistake is treating it as a permanent one.
Traditional software teaches us to think that way. If a program couldn't perform a particular job last month, there usually wasn't much reason to try the exact same job again this month. Unless we installed an update, the program was still the same program.
AI doesn't work that way.
The models are changing. The systems around the models are changing. Their access to tools is changing. The way they reason through a problem is changing.
And while all of that is happening, we're changing too.
Failure has an expiration date
A failed AI experiment doesn't tell us what AI can do.
It tells us what one model, using one set of instructions, under one set of conditions, could do at one particular moment.
That's useful information, but it isn't a final answer.
A task that fails today may succeed a few weeks from now because the model has improved. It may also succeed because the system has gained a new tool, a better way to inspect files, a larger working context, or a better method of testing its own work.
Sometimes nothing changes except the person using it.
The second time around, we may describe the job more clearly. We may provide better examples. We may define what success looks like. We may explain the constraints that were obvious to us but invisible to the model.
The AI may have improved.
We may have improved.
Usually, it's some combination of both.
What actually failed?
When an AI doesn't produce the result we wanted, it's tempting to reduce the whole experience to a simple verdict:
The AI couldn't do it.
But several different things might have gone wrong.
The model may not have had the capability.
The request may not have contained enough information.
The model may have understood the destination but chosen the wrong method.
The conversation may have grown too long and accumulated too much unrelated context.
The model may have needed access to files, code, search tools, testing tools, or some other part of the job that wasn't available.
The task may also have been too large to perform reliably in a single pass.
Those are very different failures. They shouldn't all lead to the same conclusion.
If we don't understand what failed, we don't know what to change when we try again.
Retry the test, not your memory of it
People aren't very good at remembering exactly how an earlier experiment went.
We remember that the result was bad, but not always why it was bad. We remember that the model missed something, but not necessarily what instructions we gave it. We may compare a current result from one model against a vague memory of another model's result from six months ago.
That's not much of a test.
When a task matters, save enough of the original experiment to repeat it later:
- The material you gave the AI
- The instructions you used
- The model and settings you selected
- The answer it produced
- The specific reasons the answer failed
- An example of what a successful result would look like
This turns disappointment into a reusable evaluation.
A few weeks or months later, run the same task again.
Start with the original instructions. That shows whether the model itself has improved.
Then run it a second time with what you've learned since then. Add the missing context, clarify the requirements, break the work into stages, or give the model a way to test the result.
The first retry measures the model.
The second measures the model and your improved method together.
Both are worth knowing.
Define success before you start
It's hard to decide whether an AI has improved when we haven't clearly defined what a good result looks like.
“Write better code” isn't a test.
“Return the first 200 search results without waiting for the complete result count, then continue calculating the total without blocking the user” is a test.
“Make this sound more professional” is open to interpretation.
“Rewrite this for a customer who already understands the product, keep it friendly, remove unnecessary technical detail, and keep it under 300 words” gives the model something it can actually aim at.
A useful retry begins with a simple question:
What would the model need to do for me to call this successful?
That doesn't mean we need a complicated scoring system for every prompt. It means we should be able to identify the difference between a result we can use and one we can't.
Try another method, not just another wording
Retrying doesn't mean repeatedly asking the same vague question and hoping the AI guesses differently.
Sometimes the task needs a different structure.
Instead of asking for the finished result immediately, ask the model to inspect the problem first.
Ask it what information is missing.
Ask it to explain the approach it intends to take.
Give it a small example and let it prove the method before applying it to the entire job.
For programming work, ask it to build a realistic test case instead of reasoning only from the code. Ask it to compile the project, run the tests, examine the failure, and revise the solution.
For writing, provide samples of your voice. Explain what you don't want as clearly as what you do want. Let the model produce a section, review it, and establish the direction before it writes the entire piece.
A better prompt can help, but a better process is often more important than clever wording.
Know when the conversation is part of the problem
A model can be capable of doing the job and still perform poorly because the conversation carrying the job has become overloaded.
Long threads collect decisions, abandoned ideas, old versions, corrections, side discussions, and instructions that may no longer apply. Eventually, the model has to sort through all of that every time it answers.
Sometimes the right way to try again is to start a new conversation with a clean handoff.
That doesn't mean throwing away everything you've learned. It means carrying forward the decisions and context that still matter while leaving the clutter behind.
People who work with AI regularly learn to ask questions such as:
- Are we still working with enough clean context to continue?
- Are old instructions beginning to conflict with current ones?
- Should we finish this stage and move the next stage to a new thread?
- What needs to be included in the handoff?
Those aren't tricks for manipulating the AI. They're part of managing the working environment.
Don't turn model preference into model loyalty
It's reasonable to prefer one AI over another.
One may be better for your kind of programming. Another may fit your writing style. One may be faster, less expensive, more thorough, or easier to work with.
What's less reasonable is assuming that the comparison will remain true forever.
When someone says, “I tried ChatGPT, didn't like it, and moved to Claude,” that tells us something about the models they tested at that time. It doesn't necessarily tell us which one will perform better on the same task today.
The same is true in the other direction.
Model loyalty is especially risky in a field moving this quickly. We can spend months defending a conclusion that was perfectly accurate when we reached it but is no longer relevant.
Use the model that works best for you today.
Just don't stop checking.
Trying again isn't the same as trusting blindly
None of this means that the newest model will always be better at every task.
A model can improve overall and still become worse in a specific area. It can solve more difficult problems while developing a new habit that gets in the way of your workflow. It can produce a more polished answer that still needs to be verified.
Trying again doesn't mean lowering our standards.
It means refusing to let an old test become a permanent belief.
Run the task again. Compare the results. Test the answer. Decide based on what the model can do now, not what it couldn't do six months ago.
Keep the door open
When an AI disappoints us, it's reasonable to put it aside.
It may not be ready. It may not be the right model. The task may still require more human judgment, better tools, or a different approach.
But keep the experiment.
Keep the material, the instructions, and the reasons it failed. Come back to it later and see what happens.
With AI, failure has an expiration date.
The next model may be better. The current model may have gained new capabilities. The system around it may have changed. And by then, you may know how to ask a much better question.
Related field note
In the companion field note, Try, Try Again, I look at what I've seen changing in ChatGPT and Claude, and at the 10,000-row search test that showed me just how different today's AI development process has become.