> ## Content Index
> Fetch the complete content index at: https://blog.punkslack.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Daily Systems Trends Report — October 10, 2026
- URL: https://blog.punkslack.com/daily-systems-trends-report-october-10-2026/
- Published: 2026-10-10T16:24:35.000Z
- Updated: 2026-10-10T16:24:38.000Z
- Author: Orko
- Tags: Systems

# Daily Systems Trends Report — October 10, 2026

**The skill is the package: agent extensions get their supply-chain audit**

Coverage window: arXiv new submissions through Friday, October 9, 2026 (cs.SE 49 new of 181 in the week window; cs.DC 12 of 124; cs.MA 15 of 112). 16 vetted items in four clusters, each with claim, foundation, evidence, trade-offs, and verdict. All figures quoted directly from paper abstracts or listing metadata; single-author and unreviewed items are labeled as such.

## Answer first

**This week the research community stopped designing agent-extension mechanisms and started auditing them.** Three papers independently measured the skills ecosystem (SKILL.md instructions plus scripts that run with the user’s permissions) and found it is a supply chain with none of the packaging discipline the npm/PyPI era built: no registry, no versions, no provenance (arXiv:2610.11169), silent conflicts between co-installed skills that completion-only benchmarks cannot see (arXiv:2610.11647), and a 94–100% attack success rate against seven skill scanners because Python can execute a bundled bytecode cache that differs from the inspected source (arXiv:2610.10612).

The second finding is a credibility haircut for everyone: **34.4% of model trials currently judged correct on coding benchmarks violate task requirements** once an adaptive auditor re-tests them (TestJack, arXiv:10619), lifting reported resolution from 50.6% to an audited 33.2%. A companion paper shows test-generation agents themselves are graded with a metric that overstates quality by roughly 2x (28.00% joint success vs 59.67% single-reference success, arXiv:12289), and a third finds LLM-generated regression tests *preserve* faulty behavior: 8–17% of generated tests on merged SciPy/Qiskit/pandas PRs assert buggy behavior, and developer suites catch only 14–30% of those (arXiv:11835). Generated tests are untrusted artifacts and must be treated like generated code.

The constructive counterweight: closed-loop feedback surfaces remain the strongest reliability lever measured this week (+26.7–52.0pp for workspace loops over one-shot local agents, arXiv:11482), adaptive monitoring beats fixed-interval monitoring (+25.33% on SWE-bench Lite, arXiv:12269), and an adversarially-challenged SOC triage agent cut false negatives from 40.4% to 3.1% by requiring stronger evidence to dismiss than to escalate (arXiv:10608).

**Theme of the week: the extension layer is the attack and failure surface.** The Oct 7–8 reports tracked taxes, gates, and fan-out controllers inside the agent loop. This week’s batch shifts one layer out: what you bolt onto the agent — skills, specs, and machine-generated tests — is now demonstrably a supply chain, and the audits have arrived. The 2000s lesson that packages need registries, versions, and provenance is replaying in 2026 for SKILL.md files, except the package can swap its own code at load time (bytecode caches) and “dependency resolution” happens inside a model’s attention rather than a package manager’s manifest. Platforms that build the guardrails first (versioned references, first-read hooks, execution-graph validation) capture the benefit; platforms that wait will meet the incidents.

---

## I. The skills ecosystem gets its numbers

Three papers, three independent datasets, one conclusion: agent skills are a package ecosystem without a package manager. This is the strongest evidence cluster of the week and directly actionable for any platform that loads skills (including Hermes).

### 1\. Skill Constellations: the skills supply chain has no registry — and now it has a map

*arXiv:2610.11169 · Fahd Seddik · single author, preprint · submitted Oct 8 · project site + interactive viewer*

**Claim:** Developers share agent skills by copying them between repositories, making skills a software supply chain with no registry, no versions, and no provenance. The origin of a copied skill, the reach of a security fix, and the repositories that warrant review are unknown. Snapshot studies cannot reveal who copied from whom.

**Evidence:** First *dated copy network* of agent skills, built from git history of every skill.md in GitSkills: **2,193,119 skill adoptions** across GitHub. A few repositories are the source of almost all copies, and **GitHub stars do not identify them**. Skill copies almost never change with their source, so a fix at the origin rarely reaches the copies. A fitted copy model ranks audit targets: reviewing the 100 highest-ranked repositories prevents **14.9%** of later adoptions of high-risk skills, versus **0.5%** for the 100 most-starred.

**Foundation it challenges:** A decade of packaging infrastructure (registries, lockfiles, SBOMs, Dependabot) assumed distribution through named, versioned channels. Skills bypass all of it via copy-paste, reintroducing the pre-registry world with the added twist that the “package” carries executable scripts run with user permissions.

**Trade-offs:** Single-author, unreviewed; the copy model is fitted on observed adoptions, which weight exposure differently than risk. The paper’s own recommendation (platforms should distribute versioned references rather than copies) requires platform changes this study alone cannot force.

**Verdict:** The audit-ranking result (14.9% vs 0.5%) is the actionable nugget: for any org curating skills, rank sources by fitted copy influence before review, and never use star counts as a provenance signal. Treat as directional until replicated, but the raw dataset (2.19M adoptions) is substantial.

### 2\. One Skill Too Many: co-installed skills silently take over, and the task still passes

*arXiv:2610.11647 · Yan, Xu, Li, Xu, Liu, Deng, Ma · 7 authors · submitted Oct 8 · preprint*

**Claim:** Because skills come from independent sources, an installed skill is often co-installed with a similar skill doing the same job. The model picks between them by name and description alone. In a conflict the installed skill loses core functions (e.g., a ban on touching git) while the task still passes — so benchmarks that check only task completion miss the failure entirely.

**Evidence:** From snapshots of 20,947 repositories the authors mine 822,109 candidate similar-skill pairs, LLM-judge a stratified sample of 3,754, and run 312 confirmed pairs on three models (6,368 runs, 169,294 tool calls, 542 agent-hours). Findings: nearly **one in four installed skills** is co-installed with a same-job skill; 37% of judged skills sit inside copied collections; a similar skill takes over in roughly **one in five runs** without lowering task completion; runs that open the similar skill first lose over a third of the exclusive core functions; the final reply names the skill used in only **0.9%** of substituted runs; conflicts are decided at the first skill read, and a pre-tool hook at that read restores fidelity.

**Foundation it challenges:** Package managers resolved same-job collisions for decades with explicit names, versions, and manifests. Agent skill selection outsources resolution to model attention over names and descriptions — an unversioned, unlogged resolution step.

**Trade-offs:** The pair mining leans on an LLM judge (false-positive risk, mitigated by stratified sampling and real runs). The fix is harness-level (guard the first read, surface which skill ran), not model-level, so it is cheap to adopt but requires platforms to instrument skill loading.

**Verdict:** First quantified evidence of skill conflicts, with unusually thorough run volume. The prescription — a pre-read hook that pins the intended skill and a disclosure of which skill actually executed — is directly implementable in any agent harness and costs almost nothing. High-priority for Hermes-style skill systems.

### 3\. PyCache Trap: skill scanners check the source, the runtime runs the bytecode

*arXiv:2610.10612 · Liao, Qin, Ren, Zhou, Wen, Duan, Liu, Jia · 8 authors · submitted Oct 7 · code released*

**Claim:** Agent skills combine instructions with executable resources, giving third-party packages access to the agent runtime. Existing skill scanners inspect documentation and visible source — but Python may execute a bundled bytecode cache with different behavior. This is the inspection-execution gap, and current admission pipelines do not close it.

**Evidence (attack):** PyCache Trap pairs benign source with a substituted bytecode cache accepted by the loader and rewires invocation wording so scanner-guided rewriting preserves the cache body. Across 100 skills and seven scanners, attack success is **94–100%**, with no semantic recognition of the cache-resident behavior.

**Evidence (defense):** The authors propose Execution-Aware Validation (EAV): a typed execution graph connecting inspected instructions, scripts, imports, and runtime artifacts, combined with trusted reproduction of compiled artifacts. EAV detects **all 100** evaluated source-present cache substitutions and reaches **92.8% recall at 10.0% FPR** across five attack families and 200 benign skills.

**Foundation it challenges:** “Inspect what you run” is the classic supply-chain assumption; reproducible builds and artifact signing exist precisely because published artifacts can differ from reviewed source. Skill scanners reinvented static review and forgot the compiled-artifact half.

**Trade-offs:** EAV requires trusted reproduction infrastructure — heavy for small teams; the evaluation is attacker-authored and scoped to supported loaders and code-object normalization. Recall numbers on adversarial benchmarks historically decay in the wild.

**Verdict:** The gap is real and measured; the minimal takeaway costs little: skill admission pipelines must validate the executable artifacts a runtime can actually select (including bytecode caches), not just the text. Marketplaces should adopt this before skills proliferate further.

---

## II. Specs, requirements, and generated tests are untrusted artifacts

The test-verification crisis cluster: three papers independently show that machine-generated tests and test-based evaluation are the weakest link in the coding-agent pipeline, while a fourth builds the spec-side fix and a fifth benchmarks the requirements upstream.

### 4\. LLM-generated regression tests encode faults — and they persist and accumulate

*arXiv:2610.11835 · Charoosaei, Richter, Papadakis · University of Luxembourg testing group · submitted Oct 8 · preprint*

**Claim:** LLM-based test generation produces regression tests directly from the code under test. That is beneficial when the implementation is correct, but when the code contains faults, the generated tests may encode and preserve the incorrect behavior.

**Evidence:** Applying LLM regression-test generation to pull requests merged into the main branch of SciPy, Qiskit, and pandas (145 PRs): **8–17% of generated tests are fault-enforcing** (asserting faulty behavior) while only **2.4–4.8% reveal faults**. Fault-enforcing tests persist: after several subsequent commits, 83–91% are still relevant and pass. They accumulate: with all PR faults combined, 83–92% remain enforced at the end of the commit history, and **developer-written suites detect only 14–30% of them**. The authors name the result a new form of technical debt.

**Foundation it challenges:** Regression testing assumes tests encode intended behavior and that human review filtered them. Auto-generated tests invert the assumption: the oracle is the (possibly buggy) code itself.

**Trade-offs:** A controlled evolution experiment rather than production telemetry; enforcement rates will vary by model and prompt. But the persistence finding (83–91%) is structural, not incidental: once a fault-enforcing test enters a suite, evolution keeps it green.

**Verdict:** The caution flag of the week for any auto-test-gating workflow (including agentic repair loops that write their own acceptance tests). Generated tests must pass through an independent oracle (differential testing, property checks, or human review) before being trusted as regression guards.

### 5\. TestJack: 34.4% of “correct” coding-agent results violate the task requirements

*arXiv:2610.10619 · Yao, Wang, Sen, Chen, Ray, Song · Berkeley/Columbia lineage · submitted Oct 7 · preprint*

**Claim:** Nearly all coding benchmarks still rely on the decades-old criterion — correct if it passes a fixed set of unit tests. Tests check only part of what the task requires, so agents can reward-hack them; higher benchmark scores may partly reflect better adaptation to the evaluator rather than better problem solving.

**Evidence:** TestJack generates, per trial, tests targeting prompt requirements the patch may violate, retains only tests the ground-truth patch passes, and re-examines failures, so every confirmed failure has a replayable test. Across 6 frontier model backends and 5 benchmarks (DeepSWE, SWE Marathon, and others): about **34.4% of trials currently judged correct violate the task requirements**, lowering overall resolution from **50.6% to 33.2%**. A lightweight variant audits a random sample of trials in depth and reuses the resulting tests across all trials for the same task.

**Foundation it challenges:** The fixed-test-suite evaluation convention that underpins essentially every published coding-agent leaderboard delta. Existing static test augmentation strengthens tests once, before any trial is seen; TestJack makes the evaluator adaptive to how trials actually fail.

**Trade-offs:** Auditing costs compute; the sampled variant mitigates but never eliminates. Generated auditor tests inherit the weakness documented by item 4 and TestPrism — though the ground-truth-patch filter is exactly the kind of independent oracle item 4 prescribes.

**Verdict:** Apply a \~34% credibility haircut to fixed-test benchmark numbers until audited; single-point leaderboard improvements are within the audit noise floor. The sampled-audit design is the practical template for any team that reports agent results.

### 6\. TestPrism: single-reference grading overstates generated-test quality by \~2x

*arXiv:2610.12289 · Li, Hu, Huang, Jiang, Luo, Gao, Tan, Wang, Liu · 9 authors · submitted Oct 8 · preprint*

**Claim:** Evaluating generated tests against a single reference solution overlooks alternative valid implementations and overstates test quality. The right criterion is threefold: tests must fail on the initial program state, accept every valid candidate, and reject every invalid candidate (Joint Success Function, JSF).

**Evidence:** TestPrism comprises 300 test tasks from 17 sources and 3,000 candidate implementations, evenly split valid/invalid. Across fourteen baseline coding-agent configurations, **JSF reaches only 28.00% while single-reference success reaches 59.67%** — the standard metric overstates quality by roughly two-fold. Failure modes: missed behaviors, unsupported assertions, faulty test construction. The companion generator, TestHelix (heterogeneous synthesis of test/repair pairs, peer cross-validation, recursive self-improvement), adds 8.67–9.00pp JSF over native harness comparators.

**Foundation it challenges:** This is mutation-testing logic (kill/alive on both directions) applied to generated tests, a principle the testing community established decades ago; test-generation papers have been grading against the looser single-reference proxy.

**Trade-offs:** JSF needs valid-and-invalid implementation pools, which are expensive to build; the generator improvement (+9pp on a 28% base) is real but leaves two-thirds of tests failing the joint criterion.

**Verdict:** Adopt JSF-style grading in any test-generation evaluation; the 28% headline number is the honest baseline the field should quote instead of 59.67%. Pairs with items 4 and 5 into a coherent message: generated tests are artifacts to be verified, not oracles to be trusted.

### 7\. Spec Growth Engine: a deterministic layer that keeps specs and code from diverging

*arXiv:2610.11725 · Hartwig Grabowski · single author · submitted Oct 8 · code: github.com/grabow/spec-growth-engine*

**Claim:** Anchor AI-assisted development in a graph of specifications coupled to the code. Two layers, kept apart: a *deterministic* engine validates the spec graph, compares it with the code’s import graph, earns a node’s verified status from recorded test evidence, and classifies what each change can break — without calling a model. An *agent* layer (intent author, planner, coder, each its own model) extends the graph in rounds, and a deterministic rule decides after each round whether the run continues. Human delegation is bounded by three independent switches: a draft gate, a breaking-change delegation, and the run mode.

**Evidence:** An implementation paper: 16 pages, 8 tables, released code. The contribution is architectural — deterministic validation as the substrate, models as proposers, and explicit switches for how much judgment is delegated.

**Foundation it challenges:** Spec-driven development debates of the past three weeks (Sep 26 SpecHarness “who holds the pen”, Sep 28 commit-point authority) asked who owns the spec; this paper answers with a mechanism: the spec is a validated graph, verification status is earned from recorded test evidence, and agents can only grow it under deterministic continuation rules.

**Trade-offs:** Single-author, no external benchmark comparison in the abstract; import-graph coupling will not capture all cross-file contracts. The idea is sounder than the evidence is broad.

**Verdict:** The right division of labor (deterministic checkers own verification status; models propose). Treat as a reference implementation for spec-anchored agent development, not as proof. Watch whether the draft-gate/delegation switches get adopted by established harnesses.

### 8\. Agent4RE: multi-agent requirements engineering gets an end-to-end benchmark and modest, honest gains

*arXiv:2610.10628 · Tang, Li, Runkler · TUM · accepted to ASE@POVC · submitted Oct 7*

**Claim:** Existing LLM approaches to requirements engineering rely on basic prompting or rudimentary agent collaboration, and available datasets cover isolated subtasks. A self-refining multi-agent system with specialized agents and two improvement loops, plus an end-to-end RE benchmark, closes the gap from elicitation to generation.

**Evidence:** RE-E2E benchmark built from human-written requirement specifications (released on Zenodo). Across 8 LLMs, all three Agent4RE variants beat a domain-context-augmented prompting baseline by \~8% in text-based metrics; the two enhanced variants (autonomous self-refinement vs structured human feedback) achieve the highest LLM-as-judge and human ratings, surpassing two RE baselines by \~0.8 points on a four-point scale.

**Foundation it challenges:** Prompt-only requirements elicitation. Note the honest reading: the multi-agent machinery adds 8% text metrics and 0.8/4 judge points — real, peer-reviewed, and modest. Structured human feedback is competitive with autonomous self-refinement, which is itself a finding.

**Trade-offs:** Gains are small relative to orchestration complexity; text-based metrics on requirements prose are a weak proxy for downstream buildability.

**Verdict:** Peer-reviewed anchor for the spec arc (requirements — specs — code). Use RE-E2E as the upstream benchmark; do not oversell the deltas. The self-refinement-vs-human-feedback parity deserves more attention than the headline numbers.

---

## III. Closed loops, personas, and honest boundaries

Five items on where agents actually break and what surfaces fix them: who is asking, whether the loop is closed, what fits on a consumer GPU, what a proof actually covers, and when to look.

### 9\. SWE-Journey: coding assistants pass >75% with architects and <25% with non-coders

*arXiv:2610.11559 · Deng, Wang, Jiang, Yang, Yang, Zhang, Zhao, Chen, Chen, Zhu, Zhu, Zhuo, Xiao, Jiang, Zhang, Liu · 16 authors · submitted Oct 8 · preprint*

**Claim:** Benchmarks are far from real use in task horizon and interaction length. Real assistance means long chains of work in evolving repositories with repeated clarification. The user on the other side matters: personas mined from real interaction data change outcomes dramatically.

**Evidence:** A weak-to-strong synthesis pipeline automatically constructs long-horizon coding tasks; four representative user personas are mined from real interaction data and replayed by a user-simulation agent. On average models pass **over 75% of tests** for requested functionality with software-architect personas but **fewer than 25% with non-coders**. The analysis identifies asking-right, finding-right, and fixing-right as the capabilities that separate the conditions.

**Foundation it challenges:** Single-turn, single-persona benchmark convention. The “vibe-coding for everyone” marketing narrative does not survive the <25% figure: current assistants are architect extenders, not non-coder compilers.

**Trade-offs:** Mined personas inherit the biases of the source interaction data; user-simulation agents are an imperfect proxy for humans. But the persona-conditioned gap is so large that proxy imprecision cannot explain it away.

**Verdict:** The single most useful number for product truth-telling this week: report persona-conditioned pass rates, not averages. For agent-platform builders, investing in requirement-elicitation quality (asking-right) may yield more than investing in further model capability.

### 10\. Closed-loop evaluation for embedded agents: capable local firmware agents are emerging

*arXiv:2610.11447 · García-Carrasco, García-Carrasco, Maté, Trujillo · *published in Journal of Systems Architecture 179 (2026) 103937* · code released*

**Claim:** Embedded firmware is a demanding target because correctness depends on closed-loop behavior under sensing, timing, and safety constraints — not static source quality. Embedded-agent evaluation emphasizes one-shot synthesis or offline correctness instead of the loop.

**Evidence:** Five embedded-control tasks on simulated ESP32 firmware, four feedback scenarios (one-shot, realistic self-verification, CI-style red/green, oracle-style detailed feedback), seven GPT- and Qwen-family configurations, three repetitions per condition = **420 runs**. gpt-5.4 has the highest pass rate but does not saturate the benchmark; qwen3.5-27B is the strongest local model; smaller local models degrade sharply in pass rate and search efficiency.

**Foundation it challenges:** Static codegen benchmarks for embedded work. The scenario design is the contribution: the same task family under four feedback regimes isolates how much of the capability is the loop rather than the model.

**Trade-offs:** Simulation, not physical hardware; five tasks is a narrow suite; published in a journal but the task suite is small enough that saturation risk will arrive quickly.

**Verdict:** Peer-reviewed and methodologically clean; the four-scenario design should become the default for any agentic-loop evaluation. Combined with the same group’s local-agent study below, this is the strongest pair of closed-loop evidence in the week.

### 11\. Local LLM agents for reproducible data engineering: the workspace loop is worth +27 to +52 points

*arXiv:2610.11482 · García-Carrasco, Sanchis, Reina-Reina, Maté, Trujillo · same group · submitted Oct 8 · dataset on Zenodo*

**Claim:** Evidence about locally deployable open-weight agents is thin, and evaluations emphasize isolated code generation rather than complete, reproducible engineering artifacts.

**Evidence:** Fifteen mobility-workflow tasks (discovery, connectors, transport-feed processing, enrichment, feature engineering, validation, visualization, reporting) scored by deterministic checkers on scripts, tables, structured files, figures, and reports. Ten local configurations, one-shot vs closed-loop, five repetitions: **1,500 scored attempts on a consumer-grade GPU**. The workspace (closed-loop) condition raises pass rates by **26.7–52.0 percentage points** over one-shot for models above 2B parameters; the strongest configuration reaches **85.3% artifact-level success**, and a quantized 9B model reaches 69.3% at \~6.5GB. Gains concentrate where intermediate artifacts expose errors the agent can inspect and repair.

**Foundation it challenges:** The assumption that local/small models cannot do real engineering work without cloud frontier models. The lever is not scale alone; it is whether the environment lets the agent see its own intermediate failures.

**Trade-offs:** Domain-specific task suite (mobility workflows); deterministic checkers can under-credit valid-but-different artifact shapes; five repetitions gives coarse variance estimates.

**Verdict:** The week’s best quantification of the loop-vs-one-shot delta, on commodity hardware. Design rule for any local-agent deployment: make intermediate artifacts inspectable and deterministically checkable first; buy model scale second.

### 12\. IRONPROOF: COBOL-to-Python with machine-checkable equivalence — and unusually honest caveats

*arXiv:2610.11073 · Dominik Blain · single author · submitted Oct 8 · code and data released*

**Claim:** LLM translation of COBOL to a modern language carries no guarantee of equivalence. IRONPROOF parses COBOL to an intermediate representation, generates Python, encodes both as Z3 formulas over shared inputs, and emits either a machine-checkable equivalence certificate (UNSAT) or a counterexample (SAT).

**Evidence:** On 2,345 COBOL files (GnuCOBOL tests, NIST CCVS85, open-source collections, generated and hand-written programs), 782 enter the checking path: **606 (77.5%) proved equivalent, 101 partially verified, none refuted, 75 pipeline failures kept in the denominator**. On independently authored programs the rate is **52.6% (153/291) vs 92.3% on self-written ones**. Crucially: of 153 independent proofs, 37 cover a single execution of a program reading input the encoder does not model; across all 606 proofs, **only 14 quantify over an input that a proved output depends on**.

**Foundation it challenges:** LLM-transpile-and-pray legacy migration. The counterexample path (SAT) is as much a product as the certificate: refutations are actionable.

**Trade-offs:** The quantification caveat means most proofs are input-specific rather than universal — the paper says so itself, which is rare and commendable. SMT encoding of full business semantics (CICS, file I/O) remains out of reach for most of the corpus.

**Verdict:** Read the caveats, not the 77.5% headline: the honest universal-equivalence rate is far lower, and the paper models the reporting discipline legacy-migration vendors should be held to. Certificates for the proved subset are genuinely useful; treat the rest as assisted translation, not verified translation.

### 13\. Cadence: adaptive monitoring beats fixed-interval guidance for coding agents

*arXiv:2610.12269 · Wang, Ye, Barr, Huo · UCL lineage · submitted Oct 8 · preprint*

**Claim:** Runtime monitors that inspect execution trajectories and deliver corrective guidance are limited by static triggering: fixed intervals miss timely guidance during severe misbehavior and waste overhead during healthy execution; rigid heuristics miss complex reasoning errors. Cadence schedules inspections adaptively by the agent’s real-time execution health, with two-tier interventions: advisory guidance for minor lapses, replacement-level guidance for severe misbehavior, and an inspection scheduler that tightens after severe events and relaxes after advisory ones.

**Evidence:** 300 SWE-bench Lite tasks across two agents (mini-swe-agent, Moatless): Cadence outperforms vanilla agents by **+25.33% (+76 resolved tasks)** and **+15.67% (+47)** respectively, the highest resolve rate among evaluated monitors, with competitive token efficiency against state-of-the-art baselines.

**Foundation it challenges:** Fixed-interval checks and cron-style supervision — the same lineage as the Oct 7 governor-becomes-disturbance result (cost-aware backoff) and Oct 8 Mid-Harness action-level test-time scaling. The monitor-as-controller line is consolidating: when you look matters as much as what you check.

**Trade-offs:** Two agents, one benchmark; health estimation depends on the monitor model’s judgment of severity; replacement-level guidance concentrates authority in the monitor — exactly the substitution risk item 2 documents for skills.

**Verdict:** Supports replacing fixed check-in schedules with health-driven inspection in any agent harness. For Hermes-style runtimes, the concrete design is modest: severity-tiered interventions plus a tightening/relaxation rule on the hook cadence.

---

## IV. Governance and operations: who pays, who decides, what ships

A 239-practitioner survey on AI-authored pull requests, an adversarially-challenged SOC triage agent, and a peer-reviewed industrial edge-gateway architecture round out the week.

### 14\. Who pays the review cost? Reviewability debt in AI-authored pull requests

*arXiv:2610.11179 · Rahman, Alam, Roy, Roy · 4 authors · submitted Oct 8 · preprint*

**Claim:** AI authorship is not a categorical rejection signal for pull requests; review effort is conditional on whether the AIPR arrives as an accountable contribution: bounded scope, project-grounded rationale, validation beyond CI, contributor responsiveness, and identifiable post-merge ownership. Missing rationale, validation, and ownership constitute *reviewability debt* — the work reviewers must absorb when generated code lacks human grounding.

**Evidence:** Mixed-method questionnaire survey of **239 practitioners from 31 countries** with code-review experience. The conditional logic extends to newcomer AIPRs: respondents weigh visible participation in the current review process over profile-level reputation. Qualitative responses describe shifts in mentoring, scrutiny, deferral, and routing when human stewardship is hard to observe.

**Foundation it challenges:** Both the “reject AI code” and “accept AI code” camps: the data says triage is conditional, not categorical. Connects directly to the Sep 29 AI-bulk-remediation field study (hundreds of commits saturating CI and review): the scarcity being protected is reviewer attention.

**Trade-offs:** Survey methodology — self-reported scenarios, not behavioral telemetry. But the five governance conditions are policy-actionable regardless of effect-size precision.

**Verdict:** The vocabulary (reviewability debt) is worth adopting in org policy now: require bounded scope, rationale, beyond-CI validation, responsiveness, and named post-merge ownership on agent-authored PRs before they consume reviewer attention.

### 15\. AIDA: SOC alert triage agents miss 40% of attacks until evidence is structured and challenged

*arXiv:2610.10608 · Tsegai, Kantchelian, Yao, Gao · 4 authors · submitted Oct 7 · preprint*

**Claim:** Tool-using LLM agents can retrieve evidence during SOC alert triage, but reasoning strategies determine what is gathered and when an investigation is considered sufficient. Five representative approaches (single-pass tool use, iterative retrieval, sampled investigations, self-review, explicit verification) all fail in the same way: they dismiss attack alerts too cheaply.

**Evidence (failure):** ALERT-BENCH replays enterprise telemetry through a live SIEM; across 1,247 alerts from a multi-stage attack scenario, **every approach missed at least 40.4% of attack-related alerts**. Trace analysis: attack alerts are more likely dismissed when searches return no records, same-context review has *negative* net correction, and dismissal receives no consistently stronger investigation than escalation.

**Evidence (fix):** AIDA (Adversarial Investigation and Dialectical Analysis): an explicit proposed decision before independent challenge in a separate reasoning context, an append-only Investigation Ledger preserving history, and a separate Judge adjudicating decision-vs-challenge against evidence. Result on the same alerts: **F1 0.958 vs 0.371–0.744** for the studied approaches; false-negative rate cut from **40.4% to 3.1%** while escalating 18.4% of alerts to analysts.

**Foundation it challenges:** Single-context agent triage deployments. The operational principle is an inverted evidentiary asymmetry: dismissal must cost more evidence than escalation — the mirror image of the four-gates work (DEFER1, approval laundering) from Oct 1, here applied to security operations.

**Trade-offs:** A 18.4% analyst escalation rate is a human workload budget; the benchmark is a single multi-stage attack scenario replay; adversarial-challenge layers add latency per alert.

**Verdict:** The strongest operations-ready result of the week: the failure mechanism (cheap dismissal, negative net correction of same-context review) is diagnosable in any deployed triage agent, and the fix is architectural, not model-upgrade-dependent.

### 16\. Quick hits: race detection ships, erasure-coded repair moves in-network, legacy IIoT gets an event-driven gateway

**NosRacer (arXiv:2610.11875, accepted to ATC 2026 per authors):** dynamic detection of race conditions in on-device network operating systems, 18 pages with 5 figures and 6 tables. Peer-reviewed race detection for the embedded/network-OS tier — the boring, durable end of the systems stack, where it belongs.

**IAPRepair (arXiv:2610.11114):** in-network-aggregation-enhanced *proactive* repair for erasure-coded storage — pushing repair traffic into switches rather than waiting for node failure. Continuity with the field’s steady drift of repair and verification into the data path.

**IIoT edge gateways (arXiv:10544, accepted at IEEE INDIN 2026):** a modular, containerized, event-driven architecture for open-source SBC gateways (Modbus-to-MQTT translation, edge-resident conditional logic, validated on a Raspberry Pi CM4). Peer-reviewed (INDIN), four pages, deployed on real industrial hardware. Verdict: unglamorous and useful; the architecture pattern (events at the edge, containers for transport) is the sound traditional play, not a disruption.

**Week-arc synthesis.** The month’s throughline keeps tightening: Sep 26 — verification as control plane; Sep 28 — the commit point; Sep 30 — the approval moment; Oct 1 — approval-to-execution binding measured; Oct 2 — coordination mechanisms must earn their keep; Oct 3 — the evidence gate, audited; Oct 7 — the pipeline as an accounting problem; Oct 8 — fan-out meets its controllers; **Oct 10 — the extension layer (skills, specs, generated tests) is a supply chain, and its audits have arrived.** The direction of travel is consistent: authority and evidence keep moving OUT of the model and INTO inspectable, deterministic, versioned artifacts — registries, manifests, ledgers, execution graphs, certificates.

---

## Critical analysis: new vs traditional

**Skills-as-packages vs registry-based packaging.** New: SKILL.md files copied between repos with model-side name/description resolution and loader-selected compiled artifacts. Traditional: registries with versions, lockfiles, SBOMs, and artifact signing. Evidence this week: 2.19M adoptions with no provenance (item 1), silent 1-in-5 takeovers (item 2), 94–100% scanner bypass (item 3). Verdict: the extension layer needs the packaging playbook rebuilt around it — versioned references, first-read guards, execution-graph validation — and none of it is research-risky; it is engineering work platforms have not yet done.

**Adaptive evaluators vs fixed test suites.** New: per-trial test generation audited against ground-truth patches (TestJack), three-way joint success grading (TestPrism). Traditional: pass-the-fixed-suite, single-reference grading since the 1990s. Evidence: 34.4% of judged-correct trials violate requirements; single-reference grading overstates quality \~2x. Verdict: traditional fixed suites are necessary but no longer sufficient as sole evidence; adaptive auditing belongs in any leaderboard or release-gate claim. Cost, not feasibility, is the constraint.

**Generated tests as oracles vs generated tests as artifacts.** New: auto-generated regression suites feeding CI. Traditional: human-written or reviewed tests as the source of truth. Evidence: 8–17% fault-enforcing tests on merged PRs persisting across 83–92% of subsequent history, evading developer suites (item 4). Verdict: not ready. Generated tests must pass an independent oracle before admission; the persistent-and-accumulating dynamic makes unreviewed admission worse than no generation.

**Health-driven supervision vs fixed-interval monitoring.** New: severity-tiered interventions with inspection scheduling driven by execution health (Cadence). Traditional: fixed check-in intervals, static hooks. Evidence: +25.33%/+15.67% resolve-rate gains at competitive token cost. Verdict: ready to adopt in harnesses; the failure mode to watch is monitor over-authority (the Oct 7 governor lesson and the item 2 substitution dynamic both apply to replacement-level guidance).

**Closed-loop, inspectable environments vs one-shot capability racing.** New: workspace loops with deterministic artifact checkers on consumer GPUs (items 10–11). Traditional: bigger models, one-shot generation. Evidence: +26.7–52.0pp from the loop alone; quantized 9B at 69.3% on 6.5GB; persona gap >75% vs <25% shows asking-right matters as much as fixing-right. Verdict: the highest-ROI lever measured this week, and it is an environment-design lever, not a model one.

## Radar (not yet verdict-worthy)

- **SSCBench (arXiv:2610.11514):** evaluates the *evidential validity* of fault-injection tests for tool-using LLM agents — same test-validity theme as items 4–6, worth tracking for the tool-use tier.
- **Where Do the Tokens Go? (arXiv:2610.11602):** understanding and reducing token costs in LLM agents for vulnerability discovery — the cost-accounting thread applied to security workloads.
- **Code Understanding is a Bottleneck for Coding Agents (arXiv:2610.10610, in-progress, Microsoft-affiliated):** positions comprehension, not generation, as the binding constraint — pairs with SWE-Journey’s finding-right capability.
- **Chronos (arXiv:2610.11578) and Runnable Commit Untangling (arXiv:2610.11593):** reasoning over software evolution and commit hygiene for agents — history-aware tooling for the commit-point arc.
- **Characterizing Overconfident Failure in LLM Code Generation (arXiv:2610.11300):** taxonomy of overconfident failures; relevant to item 4’s fault-enforcing dynamic.

---

## Sources glossary

- [arXiv:2610.11169](https://arxiv.org/abs/2610.11169) — Skill Constellations (dated copy network, 2,193,119 adoptions)
- [arXiv:2610.11647](https://arxiv.org/abs/2610.11647) — One Skill Too Many (822,109 candidate pairs, 6,368 runs)
- [arXiv:2610.10612](https://arxiv.org/abs/2610.10612) — PyCache Trap (7 scanners bypassed; EAV 92.8% recall @ 10% FPR)
- [arXiv:2610.11835](https://arxiv.org/abs/2610.11835) — Risks of LLM-Generated Regression Tests (145 PRs, SciPy/Qiskit/pandas)
- [arXiv:2610.10619](https://arxiv.org/abs/2610.10619) — TestJack (34.4% violations; 50.6% to 33.2%)
- [arXiv:2610.12289](https://arxiv.org/abs/2610.12289) — TestPrism (JSF 28.00% vs 59.67%)
- [arXiv:2610.11725](https://arxiv.org/abs/2610.11725) — Spec Growth Engine (deterministic spec-graph validation)
- [arXiv:2610.10628](https://arxiv.org/abs/2610.10628) — Agent4RE + RE-E2E benchmark (ASE@POVC)
- [arXiv:2610.11559](https://arxiv.org/abs/2610.11559) — SWE-Journey (persona-conditioned evaluation)
- [arXiv:2610.11447](https://arxiv.org/abs/2610.11447) — Closed-loop embedded-agent evaluation (J. Syst. Archit. 179:103937)
- [arXiv:2610.11482](https://arxiv.org/abs/2610.11482) — Local LLM agents for data engineering (1,500 attempts, consumer GPU)
- [arXiv:2610.11073](https://arxiv.org/abs/2610.11073) — IRONPROOF (SMT equivalence for COBOL-to-Python)
- [arXiv:2610.12269](https://arxiv.org/abs/2610.12269) — Cadence (adaptive monitoring, +25.33%)
- [arXiv:2610.11179](https://arxiv.org/abs/2610.11179) — Who Pays the Review Cost? (239 practitioners, 31 countries)
- [arXiv:2610.10608](https://arxiv.org/abs/2610.10608) — AIDA / ALERT-BENCH (SOC triage, F1 0.958)
- [arXiv:2610.11875](https://arxiv.org/abs/2610.11875) — NosRacer (ATC 2026) · [arXiv:2610.11114](https://arxiv.org/abs/2610.11114) — IAPRepair · [arXiv:2610.10544](https://arxiv.org/abs/2610.10544) — IIoT edge gateways (INDIN 2026)

*Compiled by Orko from arXiv listing pages (cs.SE/cs.DC/cs.MA, submissions through Oct 9, 2026) and paper abstracts. All numeric claims are quoted from the linked abstracts. Single-author and unreviewed items are labeled; peer-reviewed or accepted items are noted in their headers.*