When a small cavapoo named Momo started pawing at a keyboard, Caleb Leak turned that accident into a repeatable system that turns nonsense keystrokes into playable games. The experiment pairs simple hardware (a Bluetooth keyboard and Raspberry Pi) with Claude Code, a careful prompt, and automated verification tools so the system can iterate without human babysitting.
Why it started
What began as a funny discovery—Momo walking across Caleb’s keyboard—became a project after a layoff left time to tinker. The core question: could meaningless input be made useful if the surrounding system supplied interpretation, constraints, and feedback? The short answer Caleb found was yes—if you build the right tooling.
High-level system
The pipeline is deliberately simple and robust. Momo types on a Bluetooth keyboard (Logitech Pebble Keys 2) proxied through a Raspberry Pi 5. Keystrokes are UDP-broadcast on the local network and picked up by DogKeyboard, a small Rust application that filters dangerous keys and forwards safe text to Claude Code.
When Momo types enough characters, DogKeyboard auto-submits the input to Claude and triggers a smart pet feeder (Aqara C1 over Zigbee) to dispense treats. A chime signals to Momo when Claude is ready for more input. The real magic, though, is what happens after Claude interprets the input: Claude builds or modifies a Godot 4.6 project (C# for game logic) and then uses automated tools to check its work.
Prompt engineering: giving nonsense meaning
Random keystrokes by themselves are unhelpful, so Caleb developed a prompt framing Claude as an eccentric game designer who communicates cryptically. The prompt tells Claude that seemingly random strings are meaningful creative commands and asks it to decode them into game ideas and implement those ideas. Iteration on the prompt added minimum requirements—a working player character, input mapped to WASD or arrow keys, at least one enemy or obstacle, and working audio—so outputs were more consistently playable.
Automation and feedback: the real multiplier
Caleb emphasizes that the experiments improved most when Claude could see and test its own work. Key tools included:
- A screenshotting script so Claude can verify the game window actually rendered.
- An input-sequencing tool to simulate player actions, enabling Claude to play-test levels automatically.
- Linters for Godot scenes and shaders to catch malformed .tscn files or shader compile errors before runtime.
- An input-action mapper to ensure keyboard/controller bindings are correct.
With these feedback loops, Claude could launch a build, exercise it, detect issues (for example, invisible players or broken UI), fix the code, and re-test—much like a human developer would, but faster and without constant manual intervention.
Training Momo
Training took about two weeks of short sessions. Caleb used high-value treats to build the association between interacting with the keyboard and rewards, then automated the reward with the feeder. The system required a minimum number of characters before dispensing to avoid accidental payouts, and he tuned the schedule and treat values to keep Momo healthy and motivated.
What Momo produced
The games range from simple musical experiences to multi-stage action games. Examples mentioned include DJ Smirk, Munch, Zaaz, Oracle Frog of Rome, Octogroove, Ewe Heard Me!, and Quasar Saz (a six-stage game with a boss fight). Some games were unwinnable or buggy early on; automated tests and lints helped improve quality over time.
Final thoughts
Caleb’s project illustrates a key lesson about AI-assisted creation: it’s not the quality of raw input that matters but the surrounding infrastructure. A strong prompt plus robust, automated verification and tooling can turn inconsistent or meaningless inputs into functional artifacts. The system shows how feedback loops—screenshots, simulated play, and linters—are the bottleneck you should optimize when building AI-assisted development pipelines.
Takeaway
The spectacle of a dog “making” games hides a pragmatic truth: reliable outcomes come from engineering the environment, not the input. Give an AI clear guardrails, the ability to test its output, and tools to fix its mistakes, and even chaotic inputs can yield interesting, playable results.
Image credit: Calebleak