How to Use AI Properly for Wii Homebrew Development
Disclaimer: First, I want to say what this guide isn't. This isn't a condemnation of AI, or the projects created with the use of AI. I use AI extensively myself, and I believe that there's a right way to do things and a wrong way to do things. I also won't be addressing the political/ethical concerns regarding data scraping and the environmental harm caused by data centers. These are important conversations, but this isn't the place for them.
We're all making software in C for a console that's probably older than some of the people on this website, and there are machines that can make that task exponentially easier. The problem now is that with a lower barrier to entry, a lot of low-quality work is being submitted. This is what this guide aims to mitigate, at least a little. If AI is part of your workflow, this is for you.
§1: Private Software vs. Public Software
Lately I've seen more and more projects that seem to have been written almost entirely by AI agents that were never told the code would be shared publicly. This is a major concern for two reasons.
First, and thankfully least common, is the security of the developer posting the code. If your AI doesn't know that you're sharing this on GitHub/GBAtemp/wherever, information you might would rather keep private could find its way into comments or documentation. Second, and far more common, is code that's obviously personalized to its user.
What do I mean by that? I mean comments explaining how things work that reference chats that the public isn't privy to, usage of "we" or "us," and timeline-specific comments that wouldn't be useful to anyone except for the developer and their AI agent who have the memory of the entire project's history.
These comments don't break anything, but they are sloppy. And it's "slop" that we would like to avoid. The fix is simple: tell your agent up front that the code is public (put it in whatever instructions file your tool reads, like CLAUDE.md or AGENTS.md), and read through the comments before you push.
§2: Understanding Your Code
When you post your homebrew project and its source code publicly, you are expected to be able to maintain it. You made it, after all! So when you have done nothing but prompt an LLM to "make this thing perfect, and make no mistakes," without actually understanding how it works at all, you can't really do that properly.
I don't claim to be an excellent programmer by any means; I couldn't write a single C file from any of my projects by hand if I were asked to, but I understand how they work. I could point to which parts of the VectrexWii codebase generate sound, which parts draw the screen, and which parts load the ROMs. That kind of understanding is what you need before you ever decide to make a project public. Ask your AI to explain what something does, in plain language, until you can look at your codebase and have a moderate understanding of how your app is put together.
The goal is that when something breaks, you know at least the shape of what went wrong, instead of dreading every bug report. People rightfully expect bugs to be fixed by someone claiming to be maintaining the software, and if you aren't at least guiding the AI in the right direction, this could be a time-consuming and frustrating endeavor.
§3: If You Can't Audit by Reading Code, Audit by Using Your App
I highly recommend that you attempt to read (or even just skim!) the code your AI writes for you, but if that is too much for you, at least make sure it works. This doesn't just mean seeing if it boots on your Wii. It means using it like an end user would. Use different controllers, try it in both 4:3 and 16:9, and launch it in both Wii and vWii if you can. Interact with your software in ways that you didn't intend. Try and run every line of code that you didn't read earlier so that you can see where it breaks.
Thoroughly testing your homebrew application before posting it is the single most important thing you can do to ensure it doesn't feel "off." You should be actively working with your AI, telling it how things actually feel on hardware, not just sitting at your desk writing prompts and posting your application as soon as it boots.
§4: Design and Voice
Two things that will get your project labelled as "vibecoded" are having clearly LLM-generated text in your documentation and having visual elements in your software's design that reflect the current clichés of AI-generated software. Soft gradient backgrounds, small caps in the corners,
emoji headers in your README, etc. When you are working on your project, and using AI extensively, you must take on the one role only you can fill: creative director.
You are free to prompt the AI on what visual design elements you want, but you should think of them first! Try and be a little bit creative, or else we end up with 9001 websites and homebrew apps that all look the same. When it comes to READMEs, and, more importantly, thorough documentation, it's okay to use AI to proofread for you, but you should be writing the majority of the text here. If you used AI for a first draft, rewrite it in your own words. AI can be good at a lot of things, but ironically, for something built on a language model, it can be really bad at writing documentation without making overconfident claims, padding out paragraphs unnecessarily, or just generally being hard to follow. This calls back to §2, as it helps immensely to understand what the hell you're talking about before you write about it.
§5: Attribution
LLMs gather their information from an enormous number of human-made works published online. When it comes to Wii homebrew, that number dwindles, and when it comes to whatever specific thing you're building, it dwindles further. You will inevitably be relying on the hand-coded work made by other developers, and this is something that your AI could be transparent with you about, but it is important to check behind it. Your job here is to be very meticulous in documenting the licenses used by the software you're borrowing code from and crediting the original developers properly.
There's absolutely nothing wrong with your project resting on top of the work done by others; this practice predates the use of AI in coding and is part of what makes free and open-source software great. But there is a huge problem with not respecting the license that software was originally published under, and not giving credit to the developers that make your work possible. Additionally, just because code is public doesn't mean it's free to reuse, and open-source code still comes with license terms you have to follow. Please make sure that you are actually allowed to borrow code before doing so.
§6: Closing Thoughts
Personally, I see the "vibecoded" label used in one of two ways: for any project that uses AI at all, or for sloppy projects that clearly didn't have a human guiding them. I hope I've made it clear that the second kind is avoidable and, unfortunately, far too common in our community.
If you're a developer that uses AI and you got something out of this or have any criticisms of what I've said here, please let me know. If you are 100% against the use of AI, that's fine, and you have legitimate reasons to hold that opinion, but I ask that we not bring discussions about that opinion into this thread. Once again, not the time or place. Thank you all for reading.
Disclaimer: First, I want to say what this guide isn't. This isn't a condemnation of AI, or the projects created with the use of AI. I use AI extensively myself, and I believe that there's a right way to do things and a wrong way to do things. I also won't be addressing the political/ethical concerns regarding data scraping and the environmental harm caused by data centers. These are important conversations, but this isn't the place for them.
We're all making software in C for a console that's probably older than some of the people on this website, and there are machines that can make that task exponentially easier. The problem now is that with a lower barrier to entry, a lot of low-quality work is being submitted. This is what this guide aims to mitigate, at least a little. If AI is part of your workflow, this is for you.
§1: Private Software vs. Public Software
Lately I've seen more and more projects that seem to have been written almost entirely by AI agents that were never told the code would be shared publicly. This is a major concern for two reasons.
First, and thankfully least common, is the security of the developer posting the code. If your AI doesn't know that you're sharing this on GitHub/GBAtemp/wherever, information you might would rather keep private could find its way into comments or documentation. Second, and far more common, is code that's obviously personalized to its user.
What do I mean by that? I mean comments explaining how things work that reference chats that the public isn't privy to, usage of "we" or "us," and timeline-specific comments that wouldn't be useful to anyone except for the developer and their AI agent who have the memory of the entire project's history.
Code:
// fixed the flicker you noticed last night
// we tried the ring buffer earlier but it crashed, so back to v2These comments don't break anything, but they are sloppy. And it's "slop" that we would like to avoid. The fix is simple: tell your agent up front that the code is public (put it in whatever instructions file your tool reads, like CLAUDE.md or AGENTS.md), and read through the comments before you push.
§2: Understanding Your Code
When you post your homebrew project and its source code publicly, you are expected to be able to maintain it. You made it, after all! So when you have done nothing but prompt an LLM to "make this thing perfect, and make no mistakes," without actually understanding how it works at all, you can't really do that properly.
I don't claim to be an excellent programmer by any means; I couldn't write a single C file from any of my projects by hand if I were asked to, but I understand how they work. I could point to which parts of the VectrexWii codebase generate sound, which parts draw the screen, and which parts load the ROMs. That kind of understanding is what you need before you ever decide to make a project public. Ask your AI to explain what something does, in plain language, until you can look at your codebase and have a moderate understanding of how your app is put together.
The goal is that when something breaks, you know at least the shape of what went wrong, instead of dreading every bug report. People rightfully expect bugs to be fixed by someone claiming to be maintaining the software, and if you aren't at least guiding the AI in the right direction, this could be a time-consuming and frustrating endeavor.
§3: If You Can't Audit by Reading Code, Audit by Using Your App
I highly recommend that you attempt to read (or even just skim!) the code your AI writes for you, but if that is too much for you, at least make sure it works. This doesn't just mean seeing if it boots on your Wii. It means using it like an end user would. Use different controllers, try it in both 4:3 and 16:9, and launch it in both Wii and vWii if you can. Interact with your software in ways that you didn't intend. Try and run every line of code that you didn't read earlier so that you can see where it breaks.
Thoroughly testing your homebrew application before posting it is the single most important thing you can do to ensure it doesn't feel "off." You should be actively working with your AI, telling it how things actually feel on hardware, not just sitting at your desk writing prompts and posting your application as soon as it boots.
§4: Design and Voice
Two things that will get your project labelled as "vibecoded" are having clearly LLM-generated text in your documentation and having visual elements in your software's design that reflect the current clichés of AI-generated software. Soft gradient backgrounds, small caps in the corners,
emoji headers in your README, etc. When you are working on your project, and using AI extensively, you must take on the one role only you can fill: creative director.You are free to prompt the AI on what visual design elements you want, but you should think of them first! Try and be a little bit creative, or else we end up with 9001 websites and homebrew apps that all look the same. When it comes to READMEs, and, more importantly, thorough documentation, it's okay to use AI to proofread for you, but you should be writing the majority of the text here. If you used AI for a first draft, rewrite it in your own words. AI can be good at a lot of things, but ironically, for something built on a language model, it can be really bad at writing documentation without making overconfident claims, padding out paragraphs unnecessarily, or just generally being hard to follow. This calls back to §2, as it helps immensely to understand what the hell you're talking about before you write about it.
§5: Attribution
LLMs gather their information from an enormous number of human-made works published online. When it comes to Wii homebrew, that number dwindles, and when it comes to whatever specific thing you're building, it dwindles further. You will inevitably be relying on the hand-coded work made by other developers, and this is something that your AI could be transparent with you about, but it is important to check behind it. Your job here is to be very meticulous in documenting the licenses used by the software you're borrowing code from and crediting the original developers properly.
There's absolutely nothing wrong with your project resting on top of the work done by others; this practice predates the use of AI in coding and is part of what makes free and open-source software great. But there is a huge problem with not respecting the license that software was originally published under, and not giving credit to the developers that make your work possible. Additionally, just because code is public doesn't mean it's free to reuse, and open-source code still comes with license terms you have to follow. Please make sure that you are actually allowed to borrow code before doing so.
§6: Closing Thoughts
Personally, I see the "vibecoded" label used in one of two ways: for any project that uses AI at all, or for sloppy projects that clearly didn't have a human guiding them. I hope I've made it clear that the second kind is avoidable and, unfortunately, far too common in our community.
If you're a developer that uses AI and you got something out of this or have any criticisms of what I've said here, please let me know. If you are 100% against the use of AI, that's fine, and you have legitimate reasons to hold that opinion, but I ask that we not bring discussions about that opinion into this thread. Once again, not the time or place. Thank you all for reading.
