Newshot Late last year, I decided to examine and document the dependency tree of a project whose dependency tree I happen to fully control: the still-maintained fork of a homebrew music tracker for the Nintendo DS, NitrousTracker.
Initially, I did this out of a desire to understand its licensing status. However, given recent events on Western social media, including the tracker being celebrated for an anti-AI stance in the past I feel it may be socially valuable to provide full transparency on how exactly AI has impacted its development process in recent months. I will try to accomplish this by going through every piece of code that meaningfully1 contributes to the binary file, step by step.
My intent is to document the situation at present as it affects my hobbyist work as a programmer. Please do not bother any of the projects about any of this - no brigading. In addition, this is a personal blog post and does not represent the views of any other current or former NitrousTracker developers.
NitrousTracker
The tracker’s primary source code. After putting this to a discussion between the three developers of the project, an unanimous2 decision was made to not use generative AI to write any code for the project. This includes three other sub-repositories maintained by us: libdsmi, libntxm and tobkit.
Therefore, NitrousTracker, as of writing, does not use generative AI.
-> libdsmi
libdsmi is the library used to facilitate connection between MIDI devices and the DS console.
NitrousTracker has received one vibe coded pull request related to this functionality. The changes concerned adding support for the HobbyChop mDS adapter. It was rejected for not being not integrated with libdsmi, rather creating a second, entirely separate MIDI handling code path in NitrousTracker. Since then, nobody has stepped forward to implement the same feature without vibe coding. As the main developers generally use Slot-2 USB adapters to achieve the same and lack an mDS for testing, it is unlikely this feature will be delivered in a non-vibe coded manner any time soon.
libdsmi, as of writing, does not otherwise use generative AI.
–> TinyUSB
TinyUSB is an MIT-licensed implementation of an USB stack, which I recognize most for its use as part of the Raspberry Pi Pico’s official SDK. It is packaged by libdsmi to support MIDI via the DS Linker Slot-2 USB adapter using a driver I developed. While there was an official USB library for those devices, it was based on proprietary code from the company Keil most likely used in an infringing manner.
TinyUSB features LLM usage extensively. The Claude, Codex and Copilot AI harnesses have been publicly disclosed since at least mid-2025 for code and code reviews, and their use ramped up with time. To try and preserve the AI-free status, this project is frozen on a version from October 30th, 2024 - this requires omitting some features added upstream, like support for the MIDI 2.0 standard.
-> libntxm
libntxm is the library used to handle playback, loading and saving of sound-related files, in particular .mod, .xm and .wav.
libntxm, as of writing, does not use generative AI.
–> ft2play
Since NitrousTracker 0.7.0, libntxm has incorporated significant chunks of code from ft2play, a port of FastTracker II’s .xm play routine written by 8bitbubsy. This choice has been made for interoperability reasons - this way, music played back and edited in NitrousTracker should sound very close to how it will sound in other .xm trackers and players.
ft2play does not use generative AI. As the project is de facto finished, this is unlikely to change.
-> tobkit
tobkit is the library used to handle drawing the tracker’s user interface on the Nintendo DS console.
tobkit, as of writing, does not use generative AI.
BlocksDS
BlocksDS is a software development kit for the Nintendo DS, which began life as a hostile fork of similar components developed by the devkitPro team. While it is maintained by AntonioND, I used to be a co-maintainer of the project. While I no longer exercise editorial control over it, it continues to be shipped alongside a set of development tools I maintain, and is thus subject to coordination with me.
BlocksDS’s contributing guidelines include an anti-AI policy. Therefore, BlocksDS, as of writing, does not use generative AI.
-> dswifi
dswifi is the Wi-Fi network driver shipped by BlocksDS.
dswifi, as of writing, does not use generative AI. However, it has received at least two issue reports alleged to have been generated with the use of AI, which have been acknowledged as valid bugs and fixed.
–> lwIP
lwIP is the TCP/IP stack shipped as part of dswifi, replacing the earlier, homegrown sgIP. It is currently maintained by Simon Goldschmidt.
I am not aware, as of writing, of any evidence or declarations that lwIP uses generative AI.
–> Mbed TLS
Mbed TLS is an embedded cryptography library developed by TrustedFirmware. Small parts of its codebase are included in dswifi to handle connecting to WPA/WPA2 networks.
Many contributions to Mbed TLS do make use of generative AI tools such as Claude. I have not researched whether or not the exact files shipped in dswifi are impacted.
-> FatFs
FatFs is a FAT file system driver developed by ChaN.
It is unclear if FatFs uses AI in its development; I believe that it is unlikely. However, a recent vulnerability scan performed with the use of AI claimed to have found seven bugs, of which the developer considered three to be legitimate issues requiring a fix; an additional bug had already been fixed independently.
-> etc.
There are other components shipped and maintained by BlocksDS. libnds is the DS hardware support library shipped by BlocksDS; grit is the image conversion tool; ndstool is the program used to build .nds files from ELF executables.
Given they share the same maintainer, none of those, as of writing, use generative AI.
Wonderful Toolchain
Wonderful Toolchain ships compilers and libraries for supported console platforms, primarily for the WonderSwan and Game Boy Advance. However, BlocksDS makes use of the ARM compiler and C/C++ libraries shipped by it; as such, it is part of building NitrousTracker. I am the maintainer of Wonderful Toolchain.
-> binutils
GNU binutils provides tools to handle binary code; in particular, an assembler and linker used to build the NitrousTracker binaries. It is maintained by the GNU project.
Recent versions of binutils feature numerous contributions written with the assistance of Claude, as well as one which additionally used the open weight model GLM. The version of binutils currently shipped by Wonderful Toolchain contains, at minimum, the latter commit.
-> GCC
GCC, the GNU Compiler Collection is one of the mainstream free compilers. It is used to compile C and C++ code that comprises the NitrousTracker binaries. It is maintained by the GNU project.
Recent commits to GCC feature numerous contributions written with the assistance of Claude. While it is my belief that these changes are not currently shipped by Wonderful Toolchain, I believe this may change with the release of GCC 17 next year; users of the toolchain expect timely compiler updates to support the latest C++ functionality3.
A popular alternative to GCC is LLVM, which has Claude listed as its most proficient co-contributor by commit count over the past three months.
-> picolibc
picolibc is the standard C library shipped by Wonderful Toolchain, itself a fork of newlib. It is maintained by Keith Packard.
picolibc’s recent contribution policy explicitly prohibits crediting AI tools in any way; as such, it must be assumed that any number of contributions in recent weeks could have been performed with the assistance of generative AI tools. These versions are not currently shipped by Wonderful Toolchain, but this may change at any point in time as bug fixes are incorporated.
“NitrousTracker does not use generative AI”
I still wish to not pay for the services of current large language model providers. I don’t like those companies, so I’d rather not have my money and usage going towards them. That is simple enough to me; maybe, one day, the world will invent a large language model provider that doesn’t suck, and/or RAM sticks that people can actually afford.
But am I really not using generative AI, just because I’m not using generative AI? To make it clear beyond any reasonable doubt, I have full editorial control over all pieces in the NitrousTracker dependency chain - a rare privilege in the programming world. Nevertheless, I have chosen to take advantage of the work of other people, people whose labor I cannot replace - I am not a C++ compiler frontend specialist, not a cryptography expert, not an USB architecture nerd, and I certainly can’t afford to pay people who are - and who have made the decision to incorporate generative AI into their practice in one way or another. Programming is communal in a different way to most other arts: going beyond inspiration, most of us, at least within the bounds of open source development, incorporate each other’s work in one way or another directly.
According to Leafo and rj lake4, the line should perhaps be drawn at intent: for example, an user of Unity does not intend to use generative AI as part of their practice in the way an user of Claude does, even if Unity’s developers use Claude to build it. In that sense, NitrousTracker does not use generative AI. Even then, I don’t feel comfortable calling it a “no-AI” project, as I feel it would minimize the work of those who try harder. At some blurry and unclear point, an “AI-free” declaration on my behalf would just feel like fraud - an attempt to harness the power of populism more than an actual ethical stance. On the other hand, by refusing to categorize my projects as either pro-AI or anti-AI, I’m effectively getting the worst of both worlds. However, it feels true to myself, and I find that to be increasingly important as time goes on.
There is no conclusion. I encourage you to come up with your own; or generate it, I suppose, given the majority of Wonderful Toolchain users today are AI agents.
- Excluding hypotheticals like the host system configuration impacting the linking order. ↩︎
- One of the most prominent users presented a partially dissenting opinion, which - in my understanding - indirectly implied they would personally have rather had us use generative AI if it led to faster delivery of new features and releases. ↩︎
- Note that this does not include the WonderSwan toolchain, which is currently frozen on forks of GCC 6.3.0 and binutils 2.43.1 respectively, with their maintainer having a clear no-AI stance. ↩︎
- To be clear, that is not an universal view. For example, one popular collection of projects “tainted by LLM/AI usage” believes that any explicit endorsement or tolerance of LLM usage within the project’s scope is sufficient grounds for listing. Conversely, storefronts like Steam or Panic’s Playdate have a more liberal stance, focusing on prohibiting content presented directly to the player (such as art, music, or writing) as opposed to the back end of code, security review, or issue triage solutions. ↩︎