Agent-agnostic hill-climbing loops inspired by Karpathy's autoresearch: define a metric, let the agent propose a change, measure, keep it only if the number improved, and repeat.
Iterative optimization loops (inspired by Karpathy's autoresearch): define a metric, agent proposes change, harness measures, keep if improved, repeat. Works with Claude Code, Codex, Cursor, Gemini CLI. Cap the run at 25 iterations; leave remaining work for the next session.
claude-code
Implementation note
When to use: optimization problems with a measurable number — latency, benchmark score, model accuracy, query cost — where you want hill-climbing automated rather than hand-tuned. Inspired by Karpathy's autoresearch pattern. How it works: you define a metric; each iteration the agent proposes a change, the harness measures the metric, and the change is kept only if the number improved — otherwise it is discarded — then the cycle repeats. The keep-only-if-improved rule makes progress monotonic by construction, and because the harness does the measuring, the agent cannot grade its own work. It is agent-agnostic: Claude Code, Codex, Cursor, or Gemini CLI. Safety: measurement-gated acceptance is the rail — no change survives on plausibility alone. The classic residual risk is metric gaming, where the number improves while something unmeasured degrades, so pair the target metric with guard checks (tests still pass, correctness holds) and cap total iterations to bound spend.
Improve the frame-rate stability of [game or interactive build]. Before editing, define one repeatable benchmark with the same scene, inputs, hardware, build, resolution, and settings. If no scenario or targets are supplied, propose representative values and state them before proceeding. Record frame-time distribution, average FPS, minimum FPS, CPU use, GPU use, and memory behavior. Identify the largest measured bottleneck and make one focused optimization. Rerun the complete benchmark under the same conditions. Keep the change only if it improves the target without regressing another metric or changing expected behavior. Repeat until [FPS target] holds for [stability period] with no dip below [FPS floor], memory remains below [memory target] without an upward trend, and CPU stays below [CPU target] across two consecutive runs. Stop on success, two rounds without measurable progress, a blocker, or [iteration budget]. Finish with the benchmark setup, before-and-after measurements, retained changes, reverted attempts, and remaining bottlenecks.
Shrink the production JavaScript bundle under a hard budget by attacking the largest modules with code-splitting, lighter imports, and dead-weight removal.
/goal the main production bundle is under 250 KB gzipped — run the build with the bundle analyzer, address the single largest contributor each turn (code-split it, replace it with a lighter import, or drop it), and confirm the build and tests stay green; stop at the budget or after 10 turns
Pull the slowest PostgreSQL statement, optimize its query plan with an index or rewrite, verify the improvement, and repeat until all captured queries run under 100ms or hit eight iterations.
/loop pull the 10 slowest statements from pg_stat_statements, take the single worst one, and EXPLAIN ANALYZE it. Fix only that query this iteration — add the missing index, rewrite the predicate, or batch the N+1 — then re-run EXPLAIN ANALYZE to verify the plan improved and run the test suite to prove behavior is unchanged. Only touch indexes and query shape, never application behavior. Continue until every statement in the captured set runs under its 100ms budget — stop after 8 turns, then propose the accumulated index changes as a single PR for review and report any remaining offenders.