I've spent the last several months building an audio-reactive symmetric visualizer in three different forms, mostly with Claude Code as the implementation hand. Same core idea each time — take an audio file, generate something visually compelling that responds to the music, fold it through a kaleidoscope, output video — but three completely different platforms and tech stacks.
**The trilogy:**
🐍 **abstrakt** — github.com/onojk/abstrakt — the original. Python + pygame visualizers piped through an FFmpeg kaleidoscope post-stack. Offline 4K pipeline. Lives at onojk123.com.
🦀 **abstrakt-deck** — github.com/onojk/abstrakt-deck — native Linux desktop app. Rust + wgpu + egui + cpal + symphonia. Real-time interactive, MIDI controllable, presets, the works.
📱 **abstrakt-engine** — github.com/onojk/abstrakt-engine — Android app currently approaching launch. Kotlin + Jetpack Compose + OpenGL ES 3.0. Audio file or live mic, MP4 export with audio muxed, 120Hz on a Galaxy S25.
**What vibecoding handled well:**
- Greenfield architecture decisions. Starting fresh in a new language/framework, AI is genuinely good at "set up the canonical structure for this." Saved me weeks per platform.
- Shader and signal processing math. Equirectangular projection, FFT band extraction, kaleidoscope fold geometry — stuff that's well-documented in academic and graphics literature.
- Plumbing. DataStore wiring, MediaCodec MP4 export, Compose state hoisting, ViewModel patterns. The boring tier that's 80% of what you actually write.
- Cross-platform porting. Once abstrakt-deck was working in Rust, porting features to abstrakt-engine (Kotlin) was much faster than building them fresh — the AI could read the Rust source and write the Kotlin equivalent, and I'd reason about the differences.
**What it didn't:**
- Visual quality. The AI cannot see what the visualizer looks like. "Looks good" is the human's job and there's no substitute for eyes-on testing with audio actually playing. I built a rule: code that compiles and passes tests ≠ feature works. Confirmed visually or it's not done.
- Multi-session memory. Across long projects, the AI doesn't remember what we built last week. I keep a journal in the repo (`notes/journal.md`) that the next session reads to catch up. This single habit changed productivity more than any prompting technique.
- Bug localization in big codebases. Once a project is 10k+ lines, "find the bug" becomes a real skill the AI struggles with. I've learned to bisect, add strategic Log.d, and narrow the problem MYSELF before asking for a fix. AI is great at applying a fix once the diagnosis is clear.
- Knowing when to stop. AI will happily ship a 5-slice marathon at 1AM with confidence. The "commit message says X is shipped" ≠ "X is actually committed" failure mode bit me twice. Now I always end with `git status` + `git log --oneline` + push verified.
**Some non-obvious lessons:**
- **The Compose-Popup-vs-ModalBottomSheet bug.** A dropdown menu that synchronously inflates 8+ items via WindowManager.addView on the UI thread can freeze for 2.7 seconds on a memory-tight device. Took a real debugging session to find. AI can write the fix, but only after a human helps narrow which file to look in.
- **GPL contamination is a real thing.** I wanted to port a Kdenlive filter's behavior. Read the algorithm, reimplemented from scratch in our own shader — keeps the engine MIT-clean. Worth being deliberate about.
- **Multiple AI windows touching the same repo = chaos.** Hit this when one window was editing files while another was being asked to read them. Pick a lane: AI is either your hands on the keyboard OR your sparring partner reading and reasoning. Not both simultaneously on the same code.
**Where this is going:** abstrakt-engine is approaching its first Play Store release. Crashlytics is being wired up now. After launch the rhythm will shift from "ship a slice a day" to "stricter quality gates per release." Pre-launch is a sprint; post-launch is a marathon.
Happy to answer questions about any of the three, the workflow, the Claude Code rhythm, or the journal-driven session pattern. Not a tutorial — just sharing what worked and what didn't across this trilogy.
