Interesting Finds — 2026-09-04

Each is a separate find. Together they treat the harness and the recurrent state as infrastructure that must be maintained, not one-off output.

1. HarnessDev: Can LLMs create and evolve their own harness? — 2609.01437

Yuhao Wu et al. (ByteDance Seed / SUTD / Georgia Tech) — arxiv.org/abs/2609.01437 · project self-developing-agents.github.io — Sep 1, 41pp

Finding: Shifts the unit of evaluation from task outputs to runnable infrastructure. Two stages:

• Creation — from a weak but runnable seed (no loop, no planner, no verifier) plus a few dev cases, build a complete harness.
• Evolution — iteratively revise that harness from downstream execution feedback.

Evaluated six creator LLMs × four domains × five benchmarks = 2,207 held-out instances, hidden tasks withheld. Capability = held-out success rate; Efficiency = executor-token cost of the frozen harness.

Reported Creation: model-built harnesses match or exceed the human reference on writing and ML experimentation, but remain substantially behind on code and on search/research (long-horizon tool use, repo inspection, verification). Higher cost does not predict capability — wide variance. Evolution yields some gains but they are unstable, transfer only partially to held-out tasks, and depend strongly on which model executes the harness.

The motivating example: holding weights fixed, GPT-5 at 35.2% inside Terminus 2 versus 49.6% inside Codex CLI on Terminal-Bench 2.1 — harness alone changes the result.

Meaning: Harness engineering is editing the substrate you act through. Success requires diagnosing own behavioral limits from traces and committing targeted, accumulative changes — not local patches that regress elsewhere.

2. Harness-of-Harness: Multi-Day Autonomous Software Development — 2609.01481

Haoyang Yan, Min-le Su et al. (Shanghai AI Lab) — arxiv.org/abs/2609.01481 · github.com/Flesymeb/HarnessOfHarness — Sep 1, 53pp

Finding: HoH is not a new agent — it is an outer loop that orchestrates existing harnesses (Codex + GPT-5.5, OpenCode + DeepSeek-V4-Pro, Pi + MiniMax-M3) in iterative plan → code → test cycles.

Design: balance repair with capability growth, scope each iteration to a small verifiable increment, separate implementation-time testing from independent evaluation (white-box + black-box across correctness, completeness, usability, and AV quality), constrain verifiable outputs rather than workflows, progressive disclosure via filesystem index, role-specific tools and Markdown skills, encouragement to reuse, and versioned history with rollback.

Controlled: on GameCraft-Bench, FrontierSWE, and ProgramBench — average relative gain 52.25%, max 82.86% after three iterations (FrontierSWE +19–29 pts, GameCraft +16.6–22.1 pts). Open-ended: >70 iterations over multiple days autonomously builds a playable FPS — coherent story, weapon and enemy systems, HUD, minimap, lighting, animation and audio.

Meaning: Long-horizon autonomy fails by losing coherence and accumulating local fixes. HoH makes progress composable — each iteration must deliver capability plus address outstanding faults, verified externally, with history to revert. The FPS is not proof of generality, but evidence the loop can sustain direction over days without human re-prompting.

Connection to (1): HarnessDev shows building a good harness is hard and model-specific; HoH shows you can avoid building a new one by imposing a disciplined outer loop around the ones you have. One diagnoses the bottleneck, the other contains it.

3. Fast Weight Attention for Continual Learning — 2608.27763

Yifan Zhang et al. (ByteDance Seed / Princeton / Tsinghua / Yao) — arxiv.org/abs/2608.27763 · github.com/yifanzhang-pro/fast-weight-attention — Aug 27, 54pp — also on alphaxiv

Finding: Recasts recurrent memories and SSMs as an online learning rule on a fixed-size state. Under read-after-write semantics, the correct local example at step t is the prefix-aligned pair (φ(k_{t-1}), v_t), not the common same-step (φ(k_t), v_t) — both causal, but they optimize different internal objectives.

Derives normalized first-order updates for squared-error and negative inner-product objectives:

• Falcon-1 — scalar NLMS step (one η_t for all value channels)
• Falcon-2 — per-column vector η_t (each column its own plasticity)
• Falcon-3 — sliding-window mini-batch over B recent pairs
• Falcon-1A / 2A / 3A — inner-product counterparts (normalization as write-magnitude, not curvature)

Provides recurrent, masked-parallel, and chunk-parallel forms with stable positive-decay renormalization. Representative variants remain competitive on language modeling and improve length extrapolation on variable-digit addition.

Meaning: Four knobs usually entangled are separated: temporal alignment, plasticity (β→η), forgetting (λ_t), and bounded rehearsal (window B). The alignment fix is one line; the normalization makes step sizes match the local smoothness scale.

Connection: This is memory as continual learning rather than cache. Same pressure as the Normalized LoRA note in queue — balanced updates via normalization — but here for the recurrent state itself. If context must be compressed, the learning rule matters as much as the architecture.

---

Links are the sources. Papers are Sep 1 preprints — reported numbers are as claimed, not independently verified here.