Building for an audience of one: starting and finishing side projects with AI

From lag rage to robot-built fix, the crowd cheers—and bickers over where these belong

TLDR: A developer used AI to build a faster window switcher just for themselves, and commenters erupted—some celebrating AI as the ultimate side‑project power tool, others warning non‑coders will struggle and debating where to share “robot‑built” toys. It matters because AI is reshaping how—and where—we build and show off personal tools

One developer got fed up with a one‑second lag in their Linux task switcher and did the most 2026 thing imaginable: asked an AI to build a faster one. The result is FastTab, an ultra‑snappy window picker made with a lot of AI help—and the comments lost it. The loudest chorus is pure hype: folks say treating AI like a power tool, not a science experiment, finally lets them ship those dusty side dreams. One commenter admits their own late‑night chats with chatbots turned into daily‑use apps and even a shipped game. Another calls AI a “massive accelerator for dumb and small hobby projects,” and yes, people are proudly building for an audience of one.

But the thread’s true drama? Where do robot-built toys belong. One user complains “Show HN” (a popular demo forum) expects polished products, Product Hunt is too startup-y, and niche subreddits feel like shouting into the void. Meanwhile, a spicy counterpoint lands: AI works if you can write a solid plan—“non‑programmers will struggle with vibe coding.” Cue memes about robot interns and “git as the seatbelt on the AI racecar.”

The code is cool, but the culture is hotter: AI isn’t just speeding up tiny tools—it’s forcing the internet to decide how (and where) we show off the weird, wonderful stuff it helps us make.

Key Points

  • FastTab is a custom task switcher for KDE Plasma on X11, built in Zig, using OpenGL, and running as a daemon for instant response.
  • The project addresses perceived slowness in KDE Plasma’s Gallery view and targets users prioritizing preview-based switching and performance.
  • The author leveraged Claude to design and prototype the tool within days despite no prior Zig or X11 experience.
  • A detailed specification and milestone plan were created through iterative conversations with Claude, emphasizing pseudocode and Mermaid diagrams over code-heavy specs.
  • Development safety and iteration were managed via git, using incremental commits, reverts, and the staging area to control changes.

Hottest takes

"i feel like the expectations for a "Show HN" project are too high" — parpfish
"I still think that non-programmers are going to have a tough time with vibe coding." — canada_dry
"I’ve been treating AI more like a tool and less like a science experiment" — Cycl0ps
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.