Critique–Optimizer Separation

Keep the feedback engine to criticism only; let a separate optimizer step propose the next variable value — do not conflate diagnose and rewrite.

TextGrad’s LLMCall backward prompt instructs the model to act as a gradient (feedback) engine: give intelligent criticism, do not invent a new variable version, and skip feedback when the current value already works. The TGD step then incorporates (possibly noisy) criticisms and must emit an improved value inside explicit tags (e.g. <IMPROVED_VARIABLE>…</IMPROVED_VARIABLE>) that replace the variable. The same rule appears in code evaluators: explain each failed local test and harder edge cases, but do not provide a revised implementation — leave rewriting to test-time code refinement’s optimizer step.

This separation is a harness pattern for any textual gradients / reflection and error correction loop: mixing “what’s wrong” and “here is the full rewrite” in one call conflates diagnosis with proposal and makes failures harder to ablate. Keep critique prompts stable across applications; specialize optimization variable role descriptions and the optimizer prompt instead. Parse optimizer tags strictly — the same discipline as action format enforcement.

---

Sources

• TextGrad (Yuksekgonul et al.), ch. 6