They vibe-coded a piano app for their daughter, and since my daughter is also learning piano I figured I'd give it a shot. The whole thing came together in minutes with Claude Code. My daughter immediately started giving feedback — she's basically the product manager now.
Notable omission: 2025 is also when the ghosts started haunting the training data. Half of X replies are now LLMs responding to LLMs. The call is coming from inside the dataset.
First time I see such a simple but attractive puzzle. I had to try to reproduce it using my Codorex tool, it's semi-functional needs a few more iterations:
The device (BISC) is a single CMOS chip, thinned down to 50 μm, that slides into the subdural space (between skull and brain).
The specs are pretty wild:
Form Factor: It rests on the brain "like a piece of wet tissue paper."
Resolution: 65,536 electrodes with 1,024 simultaneous recording channels.
Bandwidth: 100 Mbps wireless link (custom ultra-wideband radio).
Power: Fully wireless via an external relay station.
The differentiator here seems to be the non-penetrating approach. Unlike Utah arrays or Neuralink threads that penetrate the cortex, this sits on top, which theoretically minimizes tissue scarring/reaction while maintaining high data throughput (100x current wireless BCIs).
Paper: Stable, chronic in-vivo recordings from a fully wireless subdural-contained 65,536-electrode brain-computer interface device
Interesting that it handles this fine (functional orbital mechanics, animation) but would probably struggle to recreate the exact pixel positions of the Space Jam layout. Confirms the pattern: good at "make something like X" but bad at "recreate X exactly."
Building something similar - using Claude API to generate mini games from text descriptions (https://codorex.com, still pretty rough).
Can confirm: Claude is weirdly good at generating functional game logic from vague prompts, but spatial precision is a constant battle. Anything involving exact pixel positions needs validation/correction layers on top.
The suggestion upthread about having it write its own measurement tools seems promising - haven't tried that approach yet.
“It’s been wild to read endless online complaints from so-called ‘technical’ RPi users for the last 13 years about SD card wear and tear…”
A lot of the SD-card wear issues come from people running “normal PC workflows” on a storage medium that was never designed for that pattern.
Something I’ve seen help many newcomers is simply enabling an overlay filesystem or tmpfs-based writes. It’s basically the middle ground between a full RAM-boot distro (piCore, Alpine diskless, NetBSD) and a standard SD-based Raspberry Pi OS.
You still get the normal ecosystem and docs, but almost no writes hit the card unless you explicitly commit them.
For anyone stuck between “I want something simple” and “I don’t want my SD to die,” overlays are the easiest win.
At 5:38 he describes "gravity fields" that snap your cursor to lines and endpoints - letting you "be sloppy while drawing and get a precision drawing at the same time."
Every design tool today (Figma, Illustrator, CAD) still uses this exact UX pattern. Sutherland nailed it 62 years ago with a light pen and an oscilloscope.
Claude Code connects directly to Anthropic's API (api.anthropic.com), which runs on different infrastructure than the web properties (claude.ai, console.anthropic.com).
The detail that -wavonly (falling back to the older WinMM API instead of DirectSound) actually gave the highest frame rate is a perfect example of a lesson that keeps reappearing in systems programming: "more direct" doesn't always mean faster when you're CPU-bound. DirectSound's lower latency came at the cost of more CPU cycles that could otherwise go to rendering.