VibeBoy - Fully vibe coded GameBoy emulator.

Project Link: https://codeberg.org/KOMOTO/VibeBoy

Agent Used: Antigravity CLI

As we can see, the trends in software engineering is moving towards in favor of using coding agents and AI tools. Many engineers see this as a threat to their job security, but looking at real trends instead of prediction, we can see that high cost tokens and the low competency of the said AI agents ensure that our job(s) are well protected. Though low skill "codemonkey" jobs will be completely automated (something I predict) engineering jobs that require complete understanding of business value of the systems we are building, and the testing of the said systems will be controlled by humans until we actually achieve AGI, however that on it is own seems further and further away as our AI systems are improved.

My goals in this project were more than building an emulator. Such a task is no more than write of passage for middle level developers, my goal was more focused on ensuring I get the most value out of the least amount of tokens used. Unfortunately, I failed at this goal because I forgot to keep track of token usage, however there were a few good lessons extracted from this case study.

Lesson 1: Create a central "focus" file

You can find this file in the .agent folder of the project. One common headache I found when using agents was that they would randomly forget what they were trying to accomplish, what framework/language they were using and more commonly what OS environment they are using. If you ever paid attention to tool calls, you will see that agent sometimes tries to use things such as "grep" on a Windows environment. This is a failed tool call, yet it still costs you money. Create a focus file, inform the agent about framework, language, OS environment, coding standards, etc. and feed this file to the agent at every turn.

# System Context & Core Directives


* **Project Identity**: VibeBoy (Rust/Tauri GameBoy Emulator)
* **OS Environment**: Windows 11
* **Development Paradigm**: AI-driven vibe coding. Maximize autonomous tool utilization to accomplish goals efficiently.
## Technical Resources & Fallbacks
* **Primary Knowledge Base**: Always search the local `/resources` directory first (e.g., `CPU_Instruction_Set.pdf`).
* **Ultimate Reference**: Rely on [Pan Docs](https://gbdev.io/pandocs), the most comprehensive technical reference available for the Game Boy. Use this exclusively if local resources lack the required information.
* **Opcodes Reference**: Access `gb-opcodes optables` for detailed opcode mappings and instruction cycles.
## Coding Standards
* **Documentation**: Omit unnecessary, redundant, or explanatory comments. The code must be self-documenting and concise.
## Version Control (Git Flow)
* **Branching Strategy**: Use clear, descriptive branch names indicating the feature or fix (e.g., `Feature/CpuInterrupts`, `Fix/MemoryBankSwitching`).
* **Commit Messages**: Write concise, imperative commit messages that directly state the action taken (e.g., "Implement terminal logger for opcode execution").

Lesson 2: Test features before moving on

Especially for graphical systems, the model cannot see what it has created, therefore, it cannot decide if the code is built correctly. The AI solely relies on the log outputs from the terminal, when I loaded the ROMs only to find audio wasn't playing I understood that agents cannot verify their work like we do. It is an obvious observation for us, however, it was something I took for granted. Looking back at it, it would have been better if I created a tool that could screenshot the screen and feed it back to the agent so it could verify its own work. (There were quite a lot of graphical issues as well.)