Evaluator-Optimizer Workflow

Why it matters

Feedback loops earn their cost only when the criteria are clear and the feedback actually improves the result. This cookbook makes that condition concrete.

What to practise

Build a generator prompt that returns <thoughts> and a <response>, and an evaluator prompt that judges correctness, time complexity and style and returns PASS, NEEDS_IMPROVEMENT or FAIL with <feedback>. Run the loop on a stack with constant-time push, pop and getMin, and feed the previous attempts and the latest feedback back to the generator. Watch how many rounds it takes, and note that the loop stops only on PASS: it has no iteration limit.

How it fits

This is the evaluator-optimizer shape of 1.3.2, chosen when the criteria are clear and the feedback is usable. 1.3.2 also asks for an application-owned iteration limit and a terminal outcome for unresolved criticism, which this loop lacks. Weigh the extra rounds against a single call in 1.3.4’s record.