vibeEmu
A Game Boy and Game Boy Color emulator written in Rust by vibe coding — with an unusually candid account of what that did and did not achieve.

What it is
An experiment with a stated question: how far can you get on an emulator if you describe what you want and let an AI agent do the work? The answer is a working Game Boy and Game Boy Color emulator — a platform-agnostic core, a desktop frontend, an Android app, Super Game Boy modes and Mobile Adapter GB support — published as a Rust crate. It has four stars. The interesting part is not the emulator but the author’s own assessment of how it was built, which the README states before it says anything else.
Who built itA pseudonymous account, active since January 2014 with 48 public repositories; no name, biography, company or site is published on the profile. Nothing about the builder is therefore knowable beyond this one repository, and the note is written from it rather than around it.
Build log
6 stages- 01
The thesis comes before the software
The README opens with a line in bold — “AI is a tool, not a crutch” — followed by a disclaimer that is rare in either direction: this project is not a statement, the author is not endorsing the use of AI, and he understands that opinions differ. He names the emulators he is not claiming to match — SameBoy, mGBA, BGB — and says he will never claim this one is more accurate or made with as much care. The framing is set before a single feature is described.
- 02
It is an actual emulator, not a demo
The repository is a Cargo workspace rather than one program: a platform-agnostic core, an egui/eframe desktop frontend, an Android app, and two crates wrapping the Mobile Adapter GB. The desktop side covers ROM loading, configurable keyboard and gamepad input, screenshot capture, display filters and a VRAM viewer for tiles, maps, sprites and palettes. Model support runs from the original DMG through the Game Boy Pocket, Super Game Boy and Super Game Boy 2 to the Color and the Advance boot ROMs, including hybrid modes that pair Color output with live Super Game Boy commands.
- 03
Where the agent brute-forced, and the author said so
The most useful sentence in the repository is an admission: AI agents have a tendency to brute-force their way into passing tests, while the hand-written emulators it is measured against were built from a deeper understanding of the underlying hardware. The commit history bears out both halves — a long run of precise PPU timing fixes against named test suites (Mooneye, Wilbertpol, GBMicrotest, AGE), and a separate status file that is repeatedly committed, in the author’s own phrase, as “update test status”.
- 04
The collaboration is visible in the commit trailers
About a fifth of the last hundred commits carry an AI co-author: sixteen from GitHub’s Copilot SWE agent and four more from Copilot itself, alongside the author’s own. The repository also carries an AGENTS.md and a set of instruction files that the agents read while working — separate rules for Rust, Python, Markdown, and one on writing self-explanatory comments. The toolchain is not implied; it is recorded in the history.
- 05
The part vibing does not solve: attribution
The author states that the AI derived some code from other emulators and that he has attributed it where he felt it necessary — then asks to be told about anything he missed, promising to fix it without hesitation. That concern is visible in the repository’s proportions: the third-party licence file is over 400 KB, an order of magnitude larger than the README, and larger than the test-status file that tracks hundreds of hardware tests. A project assembled by an agent has to work out where its code came from, and that work does not get done by the agent.
- 06
Four stars, and no coverage to speak of
717 commits between May 2025 and September 2026, four stars, three forks, one open pull request, and a core crate on crates.io with two published versions and 306 downloads. There is no Hacker News submission and no write-up anywhere it could be found. The author says he wanted an emulator of his own to use in other projects, and that he relaxed the vibe-coding-only rule along the way. The repository is the whole public record — which is unusual here, and the reason the record leans on it as heavily as it does.
What they would tell you
- Brute-forcing tests is not the same as understanding the hardware. In the author’s words, AI agents “have a tendency to brute-force their way into passing tests”, where emulators like SameBoy, mGBA and BGB were written with a deeper understanding of the machine.
- The rule was worth setting and worth breaking. He began by limiting himself to vibe coding only, and now says he is less strict about it — the constraint was a way to learn what the tool is good at, not a position to defend.
- Attribution is the part that does not get automated. The AI produced code derived from other emulators, and the author asks to be told about any he missed: “I will absolutely provide proper attribution without hesitation.”
Adjacent records
All records →No. 038
VibeRave
A fork of Strudel that lets you hold a key, say a genre out loud, and have the music change on the next bar without the beat ever stopping.
No. 037
Vibe Coding Keyboard
A meme about vibe coding turned into working hardware: an ESP32-S3 desk keyboard with nine keys, a rotary encoder and a small screen holding ten switchable keymaps.
No. 036
Clawd on Desk
A pixel crab that sits on your desktop and shows what your AI coding agent is doing, so you can walk away from a long task.