decomp.dev Closes as AI Changes the Decompilation Community

decomp.dev, a public tracker built around the slow, communal progress of game decompilation projects, is closing. Its creator, developer Luke “encounter” Street, says the immediate issue is not simply that artificial intelligence can help with reverse engineering. It is that AI-led activity has changed the incentives around an open, volunteer-driven practice that was meant to reward understanding, contribution and careful review.

The site tracked decompilation efforts across dozens of classic games. Its central visual idea was straightforward: as contributors recreated and matched functions from an original game, a percentage indicator advanced toward 100%. That number represented painstaking work, often in tiny increments. Street now believes putting that progress into a public index and leaderboard is doing more damage than good in an environment where some people can use AI systems to accelerate output, fork a project, or rush toward a PC port.

A tracker designed to make difficult work visible

Decompilation, in the sense Street is discussing, is a form of reverse engineering. Developers study a compiled game program and work to recreate its functions in human-readable source code. The goal is not merely code that looks similar or does approximately the same thing. A decompilation project can aim to reproduce each function closely enough to match the original program’s behavior and build output.

That distinction matters because the tracker’s percentages were meant to reflect a specific kind of accomplishment: the gradual recreation and matching of a game’s code through human effort. A fraction of a percentage could represent a real technical breakthrough, a carefully verified function, or a contribution that helps a much larger team understand a difficult part of an older game.

Once code has been recreated, it can be recompiled—built again into an executable program. That can create opportunities to run a game’s code in different environments, including new platforms. Ports can be exciting outcomes, but Street argues that they were never the only reason for the work. For many participants, reverse engineering is also research: a means of learning how a beloved game operates and uncovering choices or mysteries embedded in its original construction.

“For years, decompilation communities attempted to establish that decompilation is primarily for research,” Street said, while acknowledging that ports can still be fun.

That is the cultural loss at the center of decomp.dev’s shutdown. A percentage meter can be a useful motivator when each movement reflects research, collaboration and verification. It becomes a much different kind of signal when people treat it as a scoreboard to be completed by throwing automated generation at a project.

Why “decomp,” “recomp” and static recompilation are not interchangeable

The language around these projects has blurred as the scene has grown. “Decomp” and “recomp” are often used casually as if they mean the same thing, but they describe different stages or approaches.

Decompilation is the work of reverse engineering compiled code and recreating the game’s functions in source code. It is the labor-intensive process that decomp.dev was built to follow.
Recompilation is the act of building code again into an executable. In a decompilation project, recreated source code can be recompiled for a different target.
Static recompilation refers to tools that translate original code into a form capable of running on modern PCs without first completing the same line-by-line, human-led decompilation process.

Static recompilation is especially important to this dispute because it lowers the threshold for getting a game running in a modern PC context. Street characterizes it as an approach that can skip decompilation entirely. Add AI assistance to that workflow, and the barrier to producing a static-recompilation-based port can fall even further.

That does not mean every use of automation or every new port is inherently the same. Street explicitly says AI, with the right guidance, human input and code review, can meaningfully speed up decompilation. The concern is about how that speed is being used—and about the behavior that follows when speed, visibility and port-first ambitions become the dominant incentives.

The same broader tension is visible elsewhere in gaming, where questions around AI-generated work frequently come down to provenance, oversight and trust rather than a simple yes-or-no technical label. Recent AI claims around Battlefield 6 cosmetic assets, for example, show how quickly a debate can shift from the tool itself to whether the work is accurate, accountable and clearly understood by its audience.

The specific behaviors Street says are harming projects

Street points to people forking existing decompilation repositories in an effort to “finish” them with AI, including in cases where that runs against the wishes of the people who began the project. In open-source development, a fork is a copy of a project that can be developed separately. Forking can be a normal and legitimate mechanism for experimentation or independent work. Street’s objection is not to the concept in isolation, but to forks that exploit a community’s openly shared groundwork while disregarding its creators’ intentions and norms.

He also describes a race to release ports before traditional contributors finish the underlying reverse-engineering work. In Street’s account, community members may spend significant time decompiling and documenting a game only for others to publish a “half-baked” and “barely-functional” port built from that momentum.

There is a practical difference between a finished-looking result and a healthy technical project. A port that launches is not automatically a well-understood, maintainable or thoroughly reviewed implementation. Likewise, an AI-generated contribution is not automatically useless. But it still requires skilled human evaluation, particularly when it is introduced into a codebase whose point is precise reconstruction and shared understanding.

That is why Street’s emphasis on human input and code reviews is crucial. Code review is the process in which other developers examine a proposed change before it is accepted. It can catch errors, clarify how a solution works, preserve standards and establish responsibility for what enters a shared project. In a community built around learning from old game code, review is more than a quality-control checkpoint. It is part of the educational and social value of the work.

When gamification starts measuring the wrong thing

Street says decomp.dev was originally created to gamify decompilation. Used carefully, gamification means applying game-like feedback—progress bars, milestones or visible goals—to make a difficult task feel more approachable. A completion meter made sense for decompilation because the work can be long, incremental and technically demanding. Seeing progress rise could give volunteers a reason to stay engaged.

But the design depends on the number continuing to mean what the community thinks it means. If the meter is read as evidence of measured human progress, it can celebrate perseverance. If it becomes a target for people who want to spend AI tokens until a number rises or use a project as a shortcut to “port game to PC,” it no longer carries the same meaning.

Street describes that shift as a hollow numbers game. The term is pointed, but the underlying problem is recognizable: public metrics often shape behavior. A leaderboard can encourage friendly collaboration, yet it can also reward haste, spectacle and claims of completion over careful work. In this case, the project tracker’s original strength—making progress highly legible—appears to have become part of its weakness.

This is not an argument that new participants are unwelcome. Street notes that increased attention has also brought in people who sincerely want to learn and make meaningful contributions. The challenge is that an open community needs mechanisms to distinguish patient, reviewable work from activity that uses its open structure primarily as raw material for a rapid release.

What decomp.dev’s closure signals for the scene

The closure removes a visible hub for following decompilation across multiple games, but the larger issue is cultural rather than logistical. Street’s reasoning suggests that the community is now being asked to weigh the benefits of openness and accessible tooling against the cost of making projects easy to exploit, misrepresent or turn into a race.

For contributors, the practical implications include a greater need for clear project expectations: whether AI-assisted changes are allowed, what review is required, whether forks are welcome, and how ports should relate to research-focused work. These are governance questions, not merely technical ones. A tool can speed up a task; it cannot independently establish consent, preserve a community’s purpose or ensure that a result deserves trust.

For people watching from outside the reverse-engineering world, it is also worth resisting a simplistic framing in which every project is either a pure preservation effort or a port factory. Street’s description makes room for both curiosity and practical outcomes. The problem, as he sees it, begins when the output becomes the only thing that counts and the research process is treated as disposable.

Decomp.dev’s percentage bars once made an often invisible kind of labor visible. Their disappearance is a reminder that progress indicators are never neutral. They tell a community what counts. In this case, Street has decided the public scoreboard no longer reflects the values it was created to support.