Coverage and kill rate split on that withdraw example for a reason you can read off the control flow. The suite makes one call, `withdraw(100, 30)` [1]. That call satisfies both guards, so neither raise branch ever executes [9]. Change `<=` to `<` in the first guard, as the harness does [8], and no test reaches the edited line. Coverage still reports 47%, because the lines that ran, ran [2][6]. The mutation score reports 9.5%, which is 2 detections out of 21 injected faults and 19 mutants left standing [3][4][5]. On the same file, the coverage figure is roughly five times the detection figure [28].
That 9.5% is a claim about one operator catalogue applied to one small function [4]. Mutation scores move when the operator set moves. For the ratio to carry into your repo, the breakages would have to be of similar kind and the code of similar branch density; a module of straight-line plumbing generates different mutants and a different number. The transferable part is that the two instruments disagree at all, given which one sits in your CI gate.
The author's baseline is where his own premise gets awkward. Before any agent call, the harness ran against 12 maintained Python libraries, among them cachetools, toolz, boltons and tenacity [13]. It generated 455 mutants, and 133 survived the existing suites [14]. Only 53 of those survivors sat on a line the tests actually execute [15], leaving 80, about 60% of survivors, on code the suites never ran at all [16]. He then widened the test command per target, 6 to 40 times more test code, expecting the executes-but-does-not-assert bucket to grow [17]. It went from 54 to 53, and where widening changed anything it converted unreachable mutants straight into kills, skipping the middle category [17][18]. His conclusion is that in mature human-written Python the vacuous test is rare, and suites fail by not running the code [19]. So the high-coverage, low-detection shape he attributes to AI-generated tests [7] is still an assertion here. The measured corpus was human.
Which is why the eight bugs he found in his own harness matter more than the tool, built in about 30 hours for the micro1 Frontier Engineering Challenge and still incomplete [12][26][27]. Editable installs on src-layout packages resolve imports back to the original checkout, so mutations written to a temp copy never executed and three targets scored 0.000 [20]; that would have published cleanly as "the agent fails on src-layout packages," which is a finding, just not a true one [21]. Running mutants in parallel produced three different survivor sets across four runs on the one target doing real async I/O, after a 0.27 to 0.77 result had already been drafted from it [22]. Note the direction of the error: a spurious failure counts as a kill [23]. A classifier scoped to batches rather than tests would have marked all 69 tests in a batch strong on the strength of one [25].
The design I would copy is the gate. A generated test is kept only if it passes on clean code and fails on the mutant, ground truth is a subprocess exit code, and no model judges any outcome [11]. That is falsifiable, and it holds up against a model that writes confident nonsense. The reporting I would copy is the split: an unreachable survivor and an executed survivor are different defects, and one needs a test that imports the module at all while the other needs an assertion [15][18]. A single coverage percentage cannot separate them, and neither can a single mutation percentage.
