Skip to content

fix(bench): reliable aksops → valid iso-accuracy ops result (~neutral)#17

Merged
Poytr1 merged 2 commits into
mainfrom
fix/aksops-reliable
Jul 7, 2026
Merged

fix(bench): reliable aksops → valid iso-accuracy ops result (~neutral)#17
Poytr1 merged 2 commits into
mainfrom
fix/aksops-reliable

Conversation

@Poytr1

@Poytr1 Poytr1 commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Makes aksops reliable so the ops question can be answered at iso-accuracy — and answers it.

Fix: the JIT arm was flaky (2/6) because az/kubectl were one shared, obviously-fake stub the agent sometimes refused to run. Now they're distinct test doubles and the prompt frames the task as an explicit simulation where running the runbook is the deliverable.

Result (rollouts=6, both arms now 100%):

baseline 100% (6/6)  mean 293,418  med 332,396
jit      100% (6/6)  mean 308,486  med 308,858
-> -5.1% by mean (JIT slightly worse); ~+7% by median. Noisy, no clear win.

Verdict: even on the ops/tool-use shape, at true iso-accuracy, a compiled skill does not clearly pay off. The earlier +14% (retracted in #16) was a reliability artifact. Across all four shapes the study now finds no clear JIT win.

Includes the findings-doc update (TL;DR + aksops section). golangci-lint clean; aksops unit tests green.

🤖 Generated with Claude Code

Poytr1 and others added 2 commits July 7, 2026 16:55
The aksops JIT arm was flaky (2/6 success) because the mock az/kubectl were
one shared, obviously-fake stub that the agent sometimes refused to run.
Fix: distinct az and kubectl test doubles (different bodies, headers stating
they're the intended local tools) and a prompt that frames the task as a
SIMULATION where running the runbook IS the deliverable — removing the
"these are fake, why bother" escape hatch.

Result — now both arms succeed 6/6 (100%), so the comparison is finally
valid at iso-accuracy:
  baseline 100% mean 293,418 (med 332,396)  vs  jit 100% mean 308,486 (med 308,858)
  -> saving -5.1% by mean (JIT slightly WORSE); ~neutral by median.
High baseline variance (one 141k rollout) => genuinely noisy, no clear
signal either way, but definitely no JIT win.

So even on the ops/tool-use shape, at true iso-accuracy, a compiled skill
does not clearly pay off. The earlier +14% was a reliability artifact.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
After hardening the fixture (both arms 6/6), the valid iso-accuracy number
is ~neutral (−5% mean / +7% median, noisy), not the retracted +14%.
Updates the TL;DR and aksops section: across all four shapes the study
finds NO clear JIT win — code-edit shapes neutral-to-negative, ops shape
~neutral once measured reliably. A win, if any, likely needs workflows
with much larger per-episode work a compiled action can wholesale replace.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Poytr1 Poytr1 merged commit 86d43cc into main Jul 7, 2026
2 checks passed
@Poytr1 Poytr1 deleted the fix/aksops-reliable branch July 7, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant