Analogue Pocket SNES Core Developer Rejects AI-Generated 50,000-Line Contribution

The openFPGA ecosystem is one of the Analogue Pocket's most appealing features, giving the handheld access to community-built FPGA cores for classic hardware. It is also, like many volunteer-driven retro-development spaces, facing a growing problem: enormous AI-generated code submissions that place the burden of verification on a small number of maintainers.

That tension came into clear view after an experimental feature was submitted for the Pocket's Super Nintendo Entertainment System core. The proposed addition aimed to bring MSU-1 streaming support to the core, potentially opening the door to SNES ROM hacks with enhanced music, including CD-quality audio. The feature itself was interesting enough to catch the attention of agg23, the developer responsible for porting the SNES FPGA core to Analogue Pocket. But the form of the contribution quickly overshadowed the idea behind it.

The submission, sent by a contributor using the name nasonliu, reportedly arrived as an unrequested code change approaching 50,000 lines. agg23 said the work had been produced entirely through a large language model and criticized both its scale and its inclusion of extensive unrelated material. For a project maintainer, the issue was not simply whether the feature appeared to function. It was whether someone would need to spend a substantial amount of time reading, understanding, testing, and maintaining a vast change set that its submitter may not fully understand.

A promising feature wrapped in an unmanageable submission

MSU-1 is not an actual chip released for the original Super NES. Instead, it is a community-created enhancement specification designed for emulation and ROM-hacking projects. It lets compatible games and hacks make use of capabilities beyond the original cartridge formats, most notably higher-quality streamed audio. That has made it a popular option for fan projects that want to add fully arranged soundtracks, voice work, or other presentation upgrades to games built for Nintendo's 16-bit system.

For useful background on this topic, read Storage Unit Discovery Sparks Debate Over Game Preservation and Private Archives.

In principle, having MSU-1 functionality on an Analogue Pocket SNES core could be a meaningful addition. The Pocket is built around FPGA technology, which recreates hardware behavior at the logic level rather than relying solely on conventional software emulation. Its openFPGA platform has encouraged developers to create cores for different retro systems and expand what the device can play. Support for a widely used ROM-hacking standard would therefore be notable for enthusiasts who use the handheld to explore the broader SNES homebrew and modification scene.

agg23 acknowledged that the prospect of the feature working was cool and unexpected. However, that initial enthusiasm was paired with an emphatic objection to the contribution process. A change containing nearly 50,000 lines is difficult to review under any circumstances. When it includes changes outside the stated feature and is generated by an AI system, it creates a particularly serious maintenance problem.

Open-source and hobby projects do not merely merge code because it produces a desirable result in a narrow test. Maintainers must determine what every important portion does, whether it introduces subtle bugs, whether it creates compatibility or performance regressions, whether it has licensing implications, and whether future contributors can safely build on it. A feature is not truly finished when it works once; it must be understandable enough to repair when it fails later.

Why code review matters in FPGA emulation

The difficulty is especially acute for FPGA cores and emulation-related work. These projects often deal with timing-sensitive behavior, obscure hardware edge cases, memory interactions, and years of accumulated knowledge about how original consoles and software behave. A seemingly harmless change can alter timing in a way that breaks one game, one mapper, one enhancement-chip scenario, or one unusual homebrew release.

That means maintainers cannot responsibly treat a huge automated patch as a black box. Even if the contributor demonstrates a working result, the person merging it becomes accountable for its effects. They must be able to identify what changed, why it changed, and how to address issues reported by users after the code has been incorporated into a public project.

The objection raised by agg23 was therefore centered on labor as much as code quality. The developer argued that sending a massive, unrequested AI-built patch consumes the time and mental energy of the people who maintain a project. In that view, the submitter receives the satisfaction of generating a feature proposal, while the maintainers inherit the difficult work of determining whether it is safe, clean, relevant, and sustainable.

agg23's response was direct: the behavior was described as unacceptable, and the contributor was told not to repeat it. The developer did not deny that the feature was technically intriguing. Rather, the point was that a potentially useful feature does not excuse a workflow that hands an enormous, poorly scoped review task to volunteers.

AI assistance is not the same as unreviewed AI output

The episode reflects a broader disagreement around AI tools in programming. Many developers use language models for tasks such as drafting boilerplate, explaining unfamiliar syntax, generating test ideas, or accelerating early prototypes. Those uses can be productive when the programmer remains engaged with the output and validates every part of the final work.

Critics are not necessarily arguing that all AI-assisted code must be forbidden. The more focused concern is what happens when generated output is submitted by people who cannot explain or support it. A language model can produce code that looks convincing and may even compile or pass basic tests. It can also introduce unnecessary rewrites, duplicate existing functionality, misunderstanding of project conventions, security weaknesses, incorrect assumptions, or changes that are technically functional but unsuitable for the codebase.

For maintainers, the key question is ownership. A contributor who submits a patch should normally be able to explain its design, narrow it to the problem being solved, respond to review feedback, and fix defects. When a massive patch is generated with little human understanding behind it, that relationship breaks down. The project team is effectively being asked to become the real author, reviewer, debugger, and long-term caretaker of somebody else's automated output.

That is why the description of such material as "slop code" has become common in development communities. The phrase does not simply mean that code was made with AI. It usually refers to high-volume output with insufficient care, poor scope control, and little evidence that the person submitting it understands the implementation. The problem is amplified in volunteer scenes, where a few highly experienced developers may already be balancing technical work with issue reports, documentation, user questions, and their own personal obligations.

A wider concern across emulator development

The Analogue Pocket incident is not an isolated example. Earlier in 2026, the team behind the PlayStation 3 emulator RPCS3 publicly asked contributors to stop sending AI-generated code without proper understanding. Its position did not amount to a complete prohibition on AI use. Instead, the project emphasized that contributors need to understand the code they submit from beginning to end.

That distinction is important. It recognizes that tooling changes over time while preserving a basic standard of engineering responsibility. Compilers, debuggers, code-completion tools, documentation sites, and automated testing systems all help developers work more effectively. But none of those tools remove the expectation that a contributor is accountable for the patch bearing their name.

Retro projects may be particularly vulnerable to low-effort submissions because they attract passionate newcomers. A player discovers a favorite old game, learns that an emulator, decompilation, port, or FPGA core is community maintained, and sees AI as a shortcut to making a requested feature. The intention may be positive. Yet good intentions do not make a 50,000-line patch reviewable.

Recent criticism has also emerged around fan-led PC ports and recompilation efforts, including work connected to Banjo-Tooie. In those cases, developers have similarly argued that using AI as a replacement for technical understanding is disrespectful to the difficult reverse-engineering and preservation work performed by experienced contributors. Such projects are often built slowly through careful testing and close study of aging hardware and software. Flooding them with unvetted generated material can derail that work rather than accelerate it.

What responsible contributions can look like

For people interested in helping openFPGA cores, emulators, ROM-hacking tools, or other retro projects, the lesson is not that newcomers are unwelcome. These communities depend on new contributors. The lesson is that the contribution must be scoped and owned by the person making it.

• Start with a small, focused change instead of a giant feature branch.
• Read project guidelines and discuss a proposed feature before investing heavily in implementation.
• Keep unrelated refactoring out of a feature submission unless maintainers explicitly request it.
• Test the work across relevant games, configurations, and edge cases.
• Be prepared to explain the implementation and revise it after feedback.
• If AI tools were used, verify the resulting code thoroughly and understand every section before submitting it.

Those principles are not unique to retro gaming, but they carry extra weight in preservation-oriented work. FPGA cores and emulator projects can become important ways for players to access and study games that are no longer commercially supported. Their reliability depends on trust: trust that code changes are understood, trust that regressions can be tracked down, and trust that the people maintaining the project are not being overwhelmed by avoidable review tasks.

The MSU-1 proposal illustrates the awkward dual reality of AI-assisted development. A tool may help surface an idea that previously seemed difficult or unlikely. At the same time, it can generate so much opaque material that the idea becomes impractical to accept. For agg23 and other maintainers, the limiting resource is not the ability to produce more lines of code. It is the time, judgment, and expertise required to ensure those lines deserve a place in a long-lived project.