What if a repair tool could see a single worked example and then fix bugs it had never seen — no language model prompts, no lookup tables, and only four CPU instructions at runtime? At AI Tech Inspire, we spotted an openly published experiment that does exactly that, and the details are a wake-up call for anyone building program repair, mutation testing, or automated refactoring pipelines.
Quick facts from the repo
- One worked example (e.g.,
fault kind 0 → act 5) is enough for the router to infer the correct act for any fault kind it hasn’t seen. - The offset isn’t stored; it’s recovered from the worked example on every call, so renumbering act codes doesn’t break behavior.
- A simple lookup table is wrong on 15 of 16 renumberings; the synthesized expression is wrong on none.
- The routing expression was authored by a program-synthesis engine; it was not hand-written or hand-simplified. The engine reported it as minimal in its D∩I metric, and an independent attempt tied exactly.
- Verification: all
2^32inputs checked against an independent reference with 0 mismatches. Each act0–15occurs exactly2^28times (uniform partition). Bits12–31never influence the result (exhaustive, not sampled). - Emitted ARM64 code uses four instructions:
lsr,sub,add, andand(bitwise). - Applied to unseen code idioms (single-line faults) — funcy-style patterns, a chunking loop, cachetools-style TTL arithmetic, and a sortedcontainers-style bisect bound — it repaired 5/5 cases exactly (byte-identical) in 10.3s with 0 tokens.
- A pipeline bug revealed the importance of timeouts: one non-terminating candidate hung for 595s. With a 5s per-candidate bound, the run completed at 5/5 in 10.3s.
- Limits: a four-act vocabulary covers ~63% of live mutants in real repos. Boolean swaps,
not-removal, and multiplicative flips have no defined act and are not repaired. - Permutation recovery is impossible from one pair: 15! relabelings exist, and only one is a translation. Recovering a full permutation requires all 16 pairs, which is just the lookup table itself.
- Localisation is not solved. Router decision costs ~656 ns; one candidate verification costs ~28.6 ms. Searching over lines is ~44,000× the routing decision and dominates cost.
- Repo: github.com/devkancheti4-design/fluid-router
Why this “one-example router” is interesting
Most automated repair systems lean on heuristics, templates, or large language models like GPT to suggest edits. Those approaches can work well, but they carry costs — token usage, non-determinism, and the risk of “plausible but wrong” patches that pass weak tests. This router takes the opposite path: a tiny, deterministic expression synthesized once and executed at runtime with four ARM64 instructions. No learned weights, no token calls, and no table lookups.
The core promise is compositional: give it a single concrete mapping (say, fault kind 0 → act 5) and it recovers the effective offset needed to route every other kind consistently. Because the offset is computed from the example on each call, the system is invariant to renumbering of the acts. By contrast, a static lookup table “bakes in” labels and fails when those labels change, explaining its 15/16 failure rate across renumberings.
“One fact in, everything routed — and you can renumber without breaking anything.”
Verification that actually inspires confidence
There’s a lot to like in the validation story. Instead of sampling, the author exhaustively checked all 2^32 inputs against an independent reference, yielding 0 mismatches. The output space is uniformly partitioned: each act 0–15 appears exactly 2^28 times, and the higher bits (12–31) have provably no influence on the result. That balance and bit-independence strongly suggest the router’s arithmetic is not only correct but well-structured.
Another detail that will interest performance-minded engineers: the program-synthesis engine found an expression that compiles on ARM64 to four instructions: lsr, sub, add, and and. In practice, the router’s decision takes ~656 ns — negligible compared to the real cost center: verifying candidate repairs, which clocks in around 28.6 ms per candidate. That 44,000× ratio is a sharp reminder that correctness checks dominate.
Applied to real code — and byte-identical repairs
It’s easy to demo a router on toy inputs; it’s harder to show it editing real code. Here, the evaluation targeted one-line faults in patterns inspired by libraries many Python engineers know: funcy-style idioms, chunking loops, cachetools-like TTL arithmetic, and sortedcontainers-style bisect bounds. The reported result: 5/5 exact repairs in 10.3 seconds with 0 tokens. “Exact” here means the tool produced byte-identical source to the intended fix — not just “tests passed.” That distinction matters because a weak test suite will happily accept the wrong edit.
From a developer’s perspective, this opens a few use cases:
- Patch triage in CI: treat the router as a deterministic, low-latency micro-policy for frequent mutation classes.
- Regression bisection helpers: when a candidate diff triggers a known fault pattern, route to a matching act instantly.
- On-device or offline repair: no dependency on cloud LLMs, tokens, or network access.
Lessons from a failure: always sandbox and bound mutated code
Perhaps the most developer-relevant datapoint is the bug uncovered during evaluation. The pipeline executed candidate programs with no timeout; one mutated variant (“act 6”) decremented a literal until the loop counter advanced by zero — a classic non-terminating loop — and the entire run stalled for 595 seconds. With a simple 5-second per-candidate timeout, the same corpus completed at 5/5 in 10.3 seconds.
“Mutation into an infinite loop isn’t an edge case — it’s a routine consequence of off-by-one.”
If you’re building anything that runs transformed or synthesized code, treat resource bounding as table stakes. Practical tips:
- Wall-clock limits per candidate (e.g.,
timeout 5s), plus CPU and memory RLIMITs. - Sandboxed execution: containers, seccomp, or microVMs to gate syscalls.
- Early termination hooks and Ctrl+C-friendly runners.
Important boundaries and what this doesn’t solve
The repo is refreshingly candid about scope. A four-act vocabulary reportedly covers about 63% of live mutants in real repositories. Fault types like Boolean swaps, not-removal, and multiplicative flips have no corresponding act; the router correctly declines to “repair” what it cannot route.
There’s also a clean combinatorial reason you can’t recover arbitrary act-code permutations from a single example: one pair is consistent with 15! labelings, only one of which is a simple translation. To identify the whole permutation, you’d need all 16 pairs — i.e., a full lookup table. The router recovers a translation offset, not a general remapping.
Crucially, localisation (finding the exact line or token to edit) isn’t solved here. The router is the cheap part (~656 ns); verification is ~28.6 ms; and the dominant cost is the line search, roughly 44,000× the routing decision. Any production system built around this idea will need smart localisation heuristics or pre-filters to cut the search space.
How this compares to LLM-driven repair
Token-free and deterministic doesn’t automatically mean better. But the contrast is instructive:
- Determinism: four-instruction arithmetic vs. probabilistic decoding in models like GPT.
- Cost profile: negligible routing time; most cost in verification you’d need anyway.
- Robustness to renumbering: the expression recomputes its offset each call; tables and text prompts are brittle to label shifts.
- Exactness: byte-identical outputs matter when “green tests” are not sufficient.
The sweet spot may be hybrid: a fast, symbolic router like this for frequent, well-typed fault classes, paired with an LLM for long-tail repairs that demand semantic context.
Try it, measure it, and mind the limits
If you work on mutation testing, auto-fix bots, or compilers, this is worth a weekend experiment. Start with the repo: fluid-router on GitHub. Reproduce the timing (router ns, verification ms), enforce per-candidate timeouts, and test against your codebase’s idioms. Don’t expect it to fix every mutant — ~63% coverage is the honest claim — but do consider where a tiny, token-free router could shave minutes off CI or reduce flaky “almost-right” edits.
At AI Tech Inspire, we’re drawn to tools that do less but do it predictably well. A four-instruction router derived by program synthesis, verified over 2^32 inputs, and stable under renumbering checks all those boxes. The question for practitioners isn’t whether this replaces larger systems; it’s where this style of microscopic, invariant-preserving routing can slot into your pipeline today.
Recommended Resources
As an Amazon Associate, I earn from qualifying purchases.
