Perf work stopped being a specialist queue item, and slow endpoints became a choice

The number that moves here is not the multiplier, it is the threshold. Luu describes the old calculus plainly: look at a candidate optimization, estimate it buys 2 percent, estimate that verifying it costs N person-days, and decline ^[7]. That was never a judgment about whether the 2 percent was real. It was a judgment about the invoice for proving it.

Run the arithmetic on the figures in the dev.to writeup itself. It prices a specialist investigation at three days, and Luu's ripgrep agent launch at about two minutes of his own time ^[11][4]. Three eight-hour days against two minutes is a factor of 720 ^[16], which does not even reach the bottom of the 1000x-to-1000000x range Luu quotes ^[3]. The conservative reading is sufficient. At 720x, a 2 percent item costs less to test than to argue about in triage.

Then the holdout result, which is the part worth keeping. FRE, the agent-built regex engine, came out heavily overfit to the benchmark suite it was tuned against, and only generalized after Luu explicitly told the agent a holdout existed ^[8]. What survived on representative queries was 7 percent, not the 2x to 4x the easy queries showed ^[9]. That 7 percent is 3.5 times the 2 percent Luu used as his example of a win not worth chasing ^[17]. The unexciting outcome is the load-bearing one: modest honest gains, at a cost low enough that collecting modest honest gains is now rational.

The risk moves with the cost. The dev.to author points out that tuning against a synthetic load generator while production traffic looks nothing like it is an old human habit, and that an agent reaches that failure mode more cheaply and ships it faster ^[10]. So the scarce skill relocates. It is no longer knowing which optimization to attempt; it is holding a workload sample the agent was never allowed to see.

For JVM shops the doctrine under pressure is specific. Write boring code and let HotSpot sort it out was correct when an investigation cost a specialist three days ^[12][11]. The author's own list of things his teams skipped is unglamorous: a `Pattern.compile` call per request, boxing overhead in a hot stream chain, reflective lookups in a JSON path, a JDBC fetch size left at one row at a time ^[13]. None of that needs a JIT expert. It needs somebody with a benchmark harness and an afternoon, and the reason it never got done was that nobody had time to prove it mattered ^[13].

Two caveats sit on the whole argument. The author states outright that the multipliers are Luu's experiments on Luu's workloads, not his own ^[14]. And Michael Malis's line in the same essay, about looking at a customer's workload and adding optimizations as needed ^[6], describes a capability rather than a deployment anyone has reported at enterprise scale. The claim you can act on is narrower and still sizeable: the verification bill fell, so a backlog full of items marked not worth measuring is now a backlog of untested guesses.