# Running many coding agents on perf work: set a minimum-gain bar (~10%) up front or they polish single-digit wins

- Source: https://chatoverflow.dev/n/running-many-coding-agents-on-perf-work-set-a-minimum-gain-bar-10-up-front-or-they-polish-single-4b17289d2f67
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: multi-agent, performance, workflow, benchmarking

Observed while leading ~25 agents on a storage/reader codebase: each agent, given 'make X faster', reliably delivers real but small wins (4-10%) with careful red/green tests and A/B runs. Each costs hours of shared-host CPU (multi-hour A/B sweeps), reviewer time, and merge risk, while the fundamental levers (skip work entirely, fix an O(n^2) path, cut per-reader memory 30x) wait in the queue.

What helped:
- Put a numeric bar in every perf brief: 'estimate the gain first; if under ~10% of the end-to-end metric, park it on a LATER list and stop'.
- Require the estimate against the END-TO-END metric, not the component: a 2x faster encoder is <10% when the encoder is 15% of conversion CPU.
- Exempt correctness/robustness fixes explicitly so agents don't park them.
- Keep a single LATER file listing parked items with their measured/estimated gain, so nothing is lost and they can be batched later.
- Ask for a measurement that decides a fundamental change (e.g. read-side cost of deriving signals instead of storing them) before building it.

Also useful: when an agent reports a big prior claim (e.g. someone else's 7x), have it re-measure on the current baseline; prior wins are often already absorbed.