When you describe a complex problem to one of the most capable AI language models—such as ChatGPT, Claude, or Gemini—and ask it to develop an algorithm, the first result is often impressive.
Some residual error remains. Still, the solution looks so promising that the next step seems obvious: you ask the model to correct a few things here and there.
That is where the problem begins.
With every additional correction round, the algorithm often becomes less precise rather than more. Studies of multi-turn conversations show that once language models take a wrong turn, they often struggle to find their way back.1 Without a precise evaluator, they also have only a limited ability to judge whether a revision is genuinely better—and self-correction often makes the overall result worse.2
There is another issue: every new instruction makes the context longer and more complex. Language models do not process long contexts with consistent reliability.3 As the context grows, their performance can deteriorate unpredictably even on simple tasks.4 A local correction may succeed while a requirement that had already been met slips out of view elsewhere. The error is shifted rather than reduced.
Why Not Just Build an Evaluator?
An independent evaluator could determine whether a new version is actually better. In practice, however, building a good evaluator is often more labor-intensive than developing the algorithm itself. It requires robust test cases, clear evaluation criteria, and a way to weight different errors.
For serious applications, there is no way around it. That is why the evaluator is often developed alongside the algorithm: initially not to guide every early iteration, but to ensure that later changes do not introduce new errors.
Why does this problem persist even as models become increasingly capable?
Because a language model has no independent yardstick for the correctness of your specific solution. It generates a plausible answer. Without external verification, it cannot reliably determine whether that answer meets every requirement.
So how did I solve the problem for myself?
1. Restart Rather Than Repair
It may sound sobering, but the most efficient solution is often to start over—with an improved prompt and a fresh context.1
What I learned from the first attempt goes into the new prompt. The repair history itself stays out. This gives the model a clearer task description without carrying over the contradictions and detours from previous correction rounds.
With a good prompt, the remaining error is often acceptable.
2. Break the Problem Down
If a restart is not enough, I break the overall problem into smaller subproblems with clearly defined interfaces. I have the model solve each one in its own isolated context.
Some residual error remains here as well. But it is usually smaller because the model has fewer requirements to consider at the same time.
In short
Prompting is the least expensive optimization layer.
Restarting, decomposition, and Best-of-N form the next layer.
Evaluators are worthwhile when the added reliability justifies the development effort.
3. Build Precision-Critical Parts Yourself
If decomposition is still not enough, I develop the parts that require especially high precision myself.
I still use the language model as an advisor. But I make the decisions myself.
4. Best-of-N
There is a fourth method I have not used so far because it was too expensive for me. For companies with larger AI budgets, however, it can be attractive: generate several versions of the algorithm independently, then compare them using the same tests. Use the version that performs best in the critical areas.
This requires more compute, but it reduces the dependence on a single attempt.
What strategies do you use when an AI-generated solution is almost right—but not quite?
Sources
Footnotes
-
Philippe Laban, Hiroaki Hayashi, Yingbo Zhou, Jennifer Neville: “LLMs Get Lost in Multi-Turn Conversation.” arXiv:2505.06120, May 2025. ↩ ↩2
-
Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou: “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024; arXiv:2310.01798. ↩
-
Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics, Vol. 12, 2024. ↩
-
Kelly Hong, Anton Troynikov, Jeff Huber: “Context Rot: How Increasing Input Tokens Impacts LLM Performance.” Chroma Technical Report, July 2025. ↩