An LLM wrote a decompiler that nearly matches IDA Pro
Kuna is a decompiler where an LLM wrote nearly every line, and it lands 1.3 points behind IDA Pro on structuring. The transferable lesson is the benchmark, not the model.
Coding agents just produced a working decompiler, and it lands within about a point of IDA Pro on one of the hardest tasks in the field. The project is Kuna, announced on 29 July 2026 in Kuna: Decompiler Development in the Age of Coding Agents by Zion Leonahenahe Basque, an assistant professor who previously built the decompiler angr during a PhD.
My read: the model that wrote the code is the least interesting part of this story. The scoreboard it was graded against is the whole trick.
🔍 What Kuna actually is
Strip away the framing and here is the concrete object:
| Item | Detail |
|---|---|
| Name | Kuna |
| What it does | Decompiles C programs; focus is control flow structuring |
| Written in | Rust |
| Lineage | A Rust port of the NSA's Ghidra, restructured to match angr's pipeline |
| Features carried over | More than 20 fundamental features from angr |
| Perfect structuring score | 44.4% of functions |
| IDA Pro, same measure | 45.7% of functions |
| Repo | github.com/noelo-lab/kuna |
| Benchmarks | decbench.com |
Two things jump out of that table that most coverage will skip.
First, 44.4% is not a high number in absolute terms. Kuna gets structuring exactly right on fewer than half the functions it sees. Second, and this is the part that matters, IDA Pro only gets 45.7%. A commercial tool with decades of engineering behind it fails the same way on more than half the functions. That gap of 1.3 points is not "AI almost caught up." It is a measurement telling you the problem is genuinely unsolved by anyone.
📐 The benchmark is the invention, not the agent
The development loop Basque describes is simple to state. The LLM studies the cases where its output scores worse than IDA Pro, Ghidra, or angr on a fundamental metric, then changes the code and gets measured again. Basque calls it autonomous refinement, and frames the result as:
"a truly experimental approach to developing a scientifically interesting tool that gets better automatically."
Notice what has to exist before that loop can turn even once:
- A benchmark corpus of real functions with known ground truth.
- A metric that assigns a number to "is this structuring correct" without a human in the loop.
- Reference implementations to lose against, so the failure has a direction.
- Someone who knows which metric is worth optimising in the first place.
Item 4 is the expensive one. Basque is explicit that the human contribution was discovering "new fundamental metrics," studying "what aligns with human reversing values," and "gathering insights over years." The agent did not decide what good decompilation looks like. It was handed a ruler that a decade of research produced and told to make the number go up.
Key takeaway: Coding agents are strongest exactly where you can score their output automatically, cheaply, and unambiguously. If you cannot write the grader, no amount of agent looping will save you. Build the grader first.
⚠️ The caveats are the most credible part
I trust this post more than most AI-built-X announcements because the author draws the boundary themselves rather than leaving it for critics.
"We are doing well on structuring, but decompilation is more than just structuring! We need to improve types, optimizations, recompilability, variable identification."
And on the research process:
"this is also not automatic research; it requires research led by humans."
So the honest scorecard looks like this:
| Dimension | Status per the author |
|---|---|
| Control flow structuring | Competitive with commercial tools |
| Type recovery | Still to improve |
| Optimisation handling | Still to improve |
| Recompilability | Still to improve |
| Variable identification | Still to improve |
The post gives no license, no line count, no compute cost, and no wall-clock development time. I am not going to guess at any of those. If you need them, the repo is the place to look, not this article.
🚀 Copying the pattern on a student budget
Here is why I think this matters to someone reading from Colombo or Kandy with a laptop and no research grant.
The old moat on tooling like this was labour. Writing a decompiler meant several engineer-years of C++ that almost nobody could fund. That moat is thinner now. The new moat is understanding the problem well enough to define the metric, and that is knowledge work you can do on a cheap machine with a good internet connection.
Concretely, if you want to point an agent at a hard problem:
- Pick a domain where correctness is checkable by a program. Compilers, parsers, protocol implementations, solvers, format converters. Anything with a test oracle.
- Write the harness before the feature. Your grader is the product. The implementation is downstream of it.
- Collect a corpus of real inputs, not toy ones. Kuna is graded against real functions and real competitors, which is why the number means something.
- Log every failing case. The agent's leverage comes from being pointed at specific losses, not vague instructions to improve.
- Stay the scientist. Deciding what to measure remains yours.
If you are learning the low-level side of this and have no toolchain set up, our online C compiler will build and run a small C program for you, and the online Rust compiler does the same for Rust, which is worth a look before you try reading Kuna's source. Neither needs a signup.
💡 What this means for you
If you are a student, the takeaway is not "AI will build your projects." It is that the scarce skill has moved. Knowing how to define and defend a metric for a messy problem is now worth more than knowing how to grind out the implementation, because the grinding got cheap and the judgement did not.
If you build software for a small team, look at your work and ask which parts have an automatic grader. Those are the parts you can point an agent at today with real confidence. The parts where "is this good?" needs a human meeting are the parts that will still cost you people.
And if you are on the security or reverse-engineering side, Kuna is worth reading purely as a data point on how hard decompilation still is. Two mature approaches both fail on the majority of functions. That is a research field with room left, and it is open source, which means the entry ticket is a benchmark run and some patience rather than a licence fee.
Commentary based on Basque's release post. All quotes and figures are from that post; nothing here is independently verified against the repository.
Original source
Kuna: Decompiler Development in the Age of Coding Agents