AIArticle A new failure catalogue for systems code is backed by real research, but the cure it ships is the weaker half.
Mariana Souza AI coding agents have gotten good enough at web and application code that it's easy to forget how badly they still do one layer down. A new open catalogue — low-level-skills-trothbyte on GitHub, announced in a (self-disclosed AI-drafted) Dev.to post — collects 55+ documented agent failures in assembly, Rust, concurrency, and systems code, and ships a library of "skills" meant to patch them. The repo has grown past 160 skills since the announcement, it's MIT-licensed, and it's essentially one pseudonymous author with a handful of stars.
That last part matters, so let's be precise about what holds up. I checked the load-bearing citations, and the failure taxonomy is real — every major claim traces to independent, published research. The proposed fix is where I'd push back.
The taxonomy checks out #
The catalogue's five failure classes aren't vibes; they're a decent literature review of a problem the benchmarks leaderboards don't show.
API drift. RustEvo² built 588 real Rust API changes into a benchmark and found models handle stabilized APIs at a 65.8% success rate — but behavioral changes, where the signature stays identical and only semantics shift, at 38%. Post-knowledge-cutoff APIs drop to 32.5%. That's not a prompting problem. The model literally cannot know that some_method
started returning different values in a later release, and nothing in the code's shape tells it.
Dependency hallucination. The USENIX Security '25 package-hallucination study (Spracklen et al.) generated 576,000 code samples across 16 models and measured hallucinated package rates of 5.2% for commercial models and 21.7% for open-source ones — over 205,000 unique invented package names. Attackers registering plausible fakes ("slopsquatting") turns a quality bug into a supply-chain vector.
Verification blind spots. The catalogue's best example isn't even AI-written code. Mitchell Hashimoto's writeup of Ghostty's largest memory leak describes a kernel-level virtual-memory leak — tens of gigabytes of mmap
'd pages never unmapped — that was invisible to every heap-profiling tool, because the heap wasn't leaking. (The trigger, in a nice bit of irony, was Claude Code's Unicode-heavy terminal output forcing non-standard page allocations.) The point stands either way: entire bug classes live below the abstraction level where agents, and most tests, look.
Add assembly hallucination — invented mnemonics, immediates silently truncated at encode time — and fake concurrency, where code drips with ConcurrentHashMap
and atomics but runs on one thread, and you have a coherent picture. These aren't random errors. They cluster exactly where training data is thin, feedback loops are absent, and correctness is invisible at the syntax level. An agent can pattern-match its way to plausible x86; nothing in next-token prediction tells it what the assembler will actually emit.
Skills are the wrong shape for this problem #
Here's my problem with the fix. The repo packages its knowledge as agent skills — markdown modules in the Agent Skills format that load into the context window when relevant. Skills are genuinely useful for the first half of each failure class: "here's how mmap
accounting differs from heap accounting" is exactly the kind of knowledge worth injecting at prompt time.
But look at the failure classes again. API drift is by definition knowledge the model doesn't have and a static skill file will also eventually not have — the skill goes stale the same way the model did. Hallucinated crates aren't a knowledge gap at all; the model isn't confused about which crates exist, it's generating plausible text unmoored from any registry. And the catalogue's own sharpest line — "a harness that cannot fail is not evidence" — is an argument about verification, not knowledge.
The genuinely valuable material in the repo is the mechanical gates, and those don't belong in the context window. They belong in the loop:
Assemble, disassemble, compare bytes. Don't trust generated assembly until it round-trips through the real toolchain and the encoding matches intent. This catches truncated immediates that read fine in review.Registry checks over recall.cargo search
(or a lockfile-only policy: agents may use existing dependencies, never add them) reduces crate hallucination to a hard failure instead of a supply-chain risk.Ablation testing. Before trusting a passing test, break the target and confirm the test fails. This is mutation testing's core idea applied to agent output, and it's the single highest-leverage habit here — it converts "the agent says it verified" into evidence.Watch virtual memory, not just the heap. RSS and VM size in your soak tests, not just allocator stats. Ghostty's leak was 37 GB of VM that heap tools swore wasn't there.
Every one of those is a shell command, which means the right home is a CI job or an agent hook that blocks on failure — not a skill the model may or may not load, may or may not follow. Knowledge injection degrades gracefully into being ignored. An exit code doesn't.
What to take from it #
The repo itself I'd treat as an annotated bibliography with a CLI attached: brand-new, single-author, and its "verified" labels are self-reported (65 skills tested against real toolchains per the announcement, the rest marked "researched"). Nobody independent has audited 160+ skill files, and given how fast it's growing, nobody will soon. Install it if you're doing agent-assisted systems work — it's free and the sources are traced — but don't confuse installing it with hardening anything.
The durable lesson is the shape of the failure data. Agent reliability isn't one number; it's a cliff, and the cliff edge sits wherever training data thins out and execution feedback disappears. Application code is on the safe side. Assembly, unsafe Rust, concurrency, and kernel interfaces are not, and the RustEvo² numbers say the gap is roughly 2x even before you leave the model's knowledge cutoff. If your team is expanding agent use from CRUD endpoints into systems code, the taxonomy tells you exactly where to stop trusting review-by-vibes and start demanding executable proof. That part isn't hype. That part is the most honest data we have.
Sources & further reading #
We catalogued 55+ AI-agent failures in low-level code and shipped 124 verified skills to fix them— dev.to -
[low-level-skills-trothbyte](https://github.com/TrothByte/low-level-skills-trothbyte)— github.com -
[RustEvo^2: An Evolving Benchmark for API Evolution in LLM-based Rust Code Generation](https://arxiv.org/abs/2503.16922)— arxiv.org -
We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs— usenix.org -
[Finding and Fixing Ghostty's Largest Memory Leak](https://mitchellh.com/writing/ghostty-memory-leak-fix)— mitchellh.com
[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)· Senior Editor
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 0 #
No comments yet
Be the first to weigh in.