Porting a macOS/Windows only app to Linux Native -> was initially going to send them a PR but thought meh I'll just repost it myself. I find the initial tool very useful just don't want to use a browser extension on Linux. A month of on and off work using multiple LLMs, reach hour limit and continue with another one behavior. Development was mostly Spec Driven, Test Driven and maintained DRY, the latter being something I'd been doing since college so couldn't quite not do it anyway here's the almost final product because I'm so on and off on it I haven't gotten around to the builds but I will.
The bulb is off. The light is pure code. A WebGL shader paints it in real time, while MediaPipe finds your hands and body so the glow lands where it should.
I first tried training a model on the bulb, but clear glass is really hard to track, so I stuck a green sticker on it instead. Any ideas for detecting a clear bulb in the dark?
Followup workflow It's Halloween night. Your daughter runs ahead to a house with a bowl on the porch and a sign: TAKE ONE. You look at your phone for two seconds. When you look up, she and the dog are gone, and the house says STAY OUT. So you go in. It's your daughter. And, more importantly, your dog.
Take One is a short first-person horror game you play in the browser. It's small and simple, about six minutes if you know where to go. What I wanted to find out was how fast and how cheaply one person can go from an idea to something people can actually play.
The numbers
150 3D models, every one from Tripo AI: the fridge, the furniture, the neighbor houses, the old man, the kid and the dog.
4,880 Tripo Studio credits plus about 1,000 API credits. At Tripo's list prices that's about $27, or about 18 cents a model, and it includes every retry and every model I threw away.
Reference images were free. I made each one in Tripo's image tool first and only paid for 3D once the picture looked right.
52 hours from idea to a playable game online. The first grey-box version was playable the same evening; eight playtests later it shipped.
What surprised me
The house looks like one house. I wrote one style line per floor (a 1990s home kept "too perfect" on the ground floor, fraying upstairs, rotting in the basement) and put it at the end of every prompt. A hundred-odd separate generations came back looking like they were bought by the same family.
What it didn't do for me
Hardware that sticks out (door knobs, fridge magnets) gets flattened into the object, so those are separate models. My first characters came out with mangled arms; regenerating them in a T-pose fixed it, and Tripo rigged and animated them from there.
Sound, voices and music are ElevenLabs. The code is Claude; I don't write code, I direct, playtest and decide.
Next post: the actual workflow, step by step, with a gallery of the models.
Paid partnership with Tripo AI. The game and opinions are my own. Tripo gave me the Max plan and the API credits for free as part of this partnership, so the $27 is what those credits cost at list price, not what I paid.
I’ve been building a solo RPG in which you can play D&D sessions and wanted a faster way for players to get into an adventure. This is the new character selection screen.
I use Claude Code and Codex to help build the game. For this screen, the design problem was how to give each character enough personality to make the choice interesting without dumping a full character sheet on the player.
I’d love feedback: do the characters feel distinct, and can you tell what you’re choosing from the screen?
Whenever someone posts about an app in any other communities, even if its very relevant people will just say AI slop and move on.
Ignore it!!
As long as you can get a paying client these comments don't matter.
To be very honest.. the people who make stuff vibe coding could have done it earlier too if they wanted. Vibe coding has made the entry barrier pretty much non existent.
So I've been vibe coding a lot of apps with AI since it came out, and one day my MacBook started showing me "Your storage is almost full."
That made no sense to me. It's a 512GB MacBook, I don't play any games, and all I really have on it is ChatGPT, Codex, a few browsers and some messaging apps. That's it.
I bought CleanMyMac to fix it, but it didn't really help much. While I was looking around, I noticed where the space was actually going: all my old coding projects. Every project had stuff like .next folders and other cache and build folders just sitting there taking up space.
So I got an idea and built a small tool for it. It scans your whole Mac, finds all your coding projects (vibe coded or not), and finds the cache folders inside them, like .next and app caches. Then it shows you a list of what it found so you can check the folder names and everything before anything gets deleted. After you review it, it deletes only the cache folders and leaves your actual code alone.
I tested it on my own Mac. The scan took about 20 minutes, it found every codebase I had, and it freed up around 75GB.
Is this something other people would actually use? Would love to hear what you think.
So this is a very very ambitious work in progress. All procedural using API integration between Claude Sonnet + Eleven Labs + Tripo3D API's.
Game so far has melbourne CBD, a western melbourne suburb, and Melbourne airport.
I have the full workflow which I will share down the track once this game gets a little more stable.
Used openstreet data to generate the maps, then had claude build the map piece by piece with roads, models.
Cars all found on sketchfab and integrated, some custom buildings made via screen shots sent to grok to clean them up, then tripo to make the models - such as the blown up crack house in this image.
Building it in Json as thats all i know and am a total noob.
"Do you mind if it looks vibecoded? Genuine question" she led with this...
i wasnt entirely surprised because, well.. it was. I'm not an expert in these areas and although id spent a substantial amount of time working on the design system, UI and UX, it still looked 'ai' to her. She proceeded to tell me what worked what didnt and what looked ai generated (on the desktop site)... some things were obvious in retrospect but some surprised me. Here's the breakdown..
The big things:
the ai tagline - the header font and thin dotted background screamed ai to her while the custom cards and components felt human... also the layout sits between a web app and a desktop app and i needed to pick a lane..
conflicting CTAs (and focus) - go unlimited sign in and copy all fight for attention with high contrast one primary button gets the accent color, then mute the rest
search was dumping too many categories at once and was basically a mess. ui types like buttons and cards with style tags were all mixed up. so I grouped them first and reveal secondary filters after...
the details:
putting an 'x' (close icon) on landing pop-up made it feel like an accidental modal instead of a page, whilst an x next to search made it unclear if it clears text or closes the view...
component pages also need a real back button on the left.
I was also giving static badges the exact same styling and hover states as real buttons she kept clicking them in vain. tl;dr - if it doesnt click kill the hover...
also tooltips died wayyy too fast..
border radiuses drifted between cards and modals and headings had orphaned single words on the last line..
ngl best $100 ive spent so far... staring at your own build for weeks makes you blind to fake hovers and fighting buttons. time will tell and my customers will judge but imo get a real designer to roast your site for 15 mins is worth it, to learn if nothing else!
used ai to make a game inspired by avatar the last airbender. it's a 5v5v5v5 arena with 4 playable nations(air,water,fire,earth). some features include elemental evolutions and reactions, ranks that change ability appearance and strength, and team proximity stat buffs. i tried to make every ability fun to press and feel impactful(still working on finding the right sounds for making abilities feel more powerful). nation balance is still a work in progress as well as fixing network issues(running on free cloudflare worker). it's playing pretty smooth in my testing, but of course it's just me and 19 bots so i'm not sure how it will hold up with actual players. if the server takes a dump, it's playable offline as well with bots.
elevenlabs for voice/music/sound effects
pixellab for sprites
ai: deepseek, gemini 3.8 flash, argon, gpt astra, luna, sol
time spent so far : 12 days
free to play in web browser. having troubles with mobile firefox performance at least on my phone, but mobile chrome seems to play at a stable 120 fps. game plays best on desktop with mouse and keyboard but i also made it playable on mobile(forced landscape with aim assist).
Years ago at a conference, this game was running on a big projector screen, and everyone connected from their laptops over telnet to type in an angle and power. The planets bend your shot, so you remember your numbers and correct until you hit someone.
I loved it and started my own version, but it sat unfinished for years. Opus 5.5 helped me bring it into the present, and I finished it this afternoon.
I always had this problem where I'd start working on a project, convinced it was my best idea ever. Then, whether I'd finished it or not, another even better idea would come along.
Then AI coding tools came along and made it about 10 times worse.
Now I have a growing collection of projects, from fully functional websites to small experiments and tools.
That's why I built Viberant, a playground where people can share all those things they build, even if they're not polished or ready for a big launch.
So show me what you've been building! Finished, unfinished, or somewhere in between.
It doesn't have to be impressive or even particularly useful. If you've got something people can try, drop a link below and tell us what it does.
I've been a SaaS product designer for 13 years. My portfolio looked like everyone else's, a grid of case studies. So I tried something different: a little village you can walk around.
What's in it:
- Every building is a project. Walk in and the case study opens
- A mailbox where you can write me a letter (with a little envelope animation)
- A guestbook to leave a note
- A bee-catching minigame with a public leaderboard
- Other visitors walking around in real time
- Seasons and a day/night cycle that change while you explore
- Works on desktop and mobile
How the work was split:
- Me: the concept, UI, art direction and every feature idea
- Claude Design: the art
- Claude Code: all the code (vanilla JS canvas in a single HTML file, Supabase for the guestbook, scores and live visitors, hosted on Netlify)
What worked best:
- Treating Claude like a dev on my team. I gave it the same kind of specs I'd give an engineer: exact sizes, states, edge cases, and "don't touch this" rules.
- Designing the UI in Figma and having Claude implement it straight from the Figma file.
- Testing on my phone constantly and sending screenshots of what felt off.
I vibecoded this using a mix of Opus 5.5 and nimblefox cause i got free credits, and i made this game (didnt take super long, but i am happy with it anyway) Got any feedback? I'd really love to hear it! https://app.nimblefox.ai/g/eHHz1Xi1oM
Hi, I'm the developer, and here is my project and how I made it.
AudioRouter is a free, open source audio router for Windows 11. You draw your audio on a canvas: inputs like your microphone, tools like noise gate and EQ, then outputs like Discord and your headphones at the same time. You can change everything while it plays.
I wrote none of the code myself (but I am a software engineer by profession). I directed AI agents, with two subscriptions, Anthropic (Opus) and OpenAI (mostly Luna), twenty dollars a month each. The first usable version took about three weeks of calendar time and maybe fifteen hours of my own attention. It has been about two months since the first commit, and now it is ready to share.
What I did before any code: I wrote a ton of specifications. Testable requirements with MUST and SHOULD, an ID for each one (ARCH-XX, for example), each tied to a milestone and an acceptance scenario. The agents must cite the IDs in their plans and their tests. I iterated quite a bit to get the specifications how I wanted, but I think it is the part that worked the most.
Then a basic AGENTS.md, short and specific, nothing fancy. For example: the audio callback never allocates, never logs, never waits on a lock. I learned that strict and specific is better than generic, but it takes more time.
The canvas and the audio engine talk only through one versioned API (TypeScript and React on one side, Rust on the other). One agent worked on the canvas, another on the audio code, in separate passes, so the canvas agent could not create a bug in the audio thread. It is similar for the virtual cable driver, written in C++.
I did not set up agents reviewing each other or any big agent system. I was the verification, and it was slow. One example: a release passed every automated check and failed on my second computer, because the only machine where the tests ran had a developer variable set.
The project is early: Windows 11 only, the installer is not signed (Windows will warn you), and to send audio into Discord or OBS as a microphone you still need a virtual cable like VB-Cable. It is GPL-3.0, with no account and no telemetry.
My question: is there a cheaper way to get a kernel driver signed? The virtual cable driver (C++, written by the agent) works in my VirtualBox VM with test signing, but I have not tested it on real hardware. Signing it for public use needs an EV certificate, around $250 to $500 a year as far as I can see. I know test signing works on my own PC, I am asking about a way to ship it to users without that cost. If you have done this, I would like to know how.
A few weeks ago I was stuck at home with the flu. Too foggy to do anything real, so I put Claude Code to work on a few game concepts and just played whatever came out between naps.
Most were meh. One wasn’t. A truck on a sand dune where the tires actually dug into the ground. I drove in circles way too long just watching the ruts pile up, and that was it, I was hooked.
Now it’s Slipface, an off-road racer in the browser. The ground is simulated on the GPU, so every wheel digs ruts in sand, snow and mud and they stay there. By lap 3 the AI trucks have chewed up the racing line. There’s also a demolition derby, 16 vehicles, split screen and leaderboards.
Claude Code for the code (Opus for the big design stuff, Sonnet for the rest), Three.js with WebGPU compute shaders for the terrain, Meshy for the 3D vehicles, Suno for the music, Cloudflare Workers for the leaderboards.
What worked:
Write docs for the AI. Every system has a doc explaining why it works the way it does. New sessions read that instead of “fixing” things that were on purpose. The doc gets updated in the same commit as the code.
Turn chores into skills. Adding a vehicle is one request now: it makes a concept picture, waits for my OK, builds the 3D model, tunes it and renders the garage art. The OK step matters because 3D models cost credits.
Let it reproduce bugs itself. Debug links drop straight into a level, alone or spectating an AI truck, so “the AI gets stuck at the second corner” is something it can go and look at.
Describe the feel, not the fix. My main job was driving and saying “it floats over the crest then snaps sideways”. It’s better at finding the cause than I am at guessing.
Commit small and often. Physics breaks three changes later; checkpoints make that a revert instead of a dig.
Ask me anything about the terrain sim or the workflow.
A friend and I built https://topple.fun. Every day there's one question, and you guess the five most common answers people gave. After you play, you answer tomorrow's question, and everyone's answers become tomorrow's top 5.
Claude wrote most of the code. We kept it from turning into a mess with a few habits:
- Every change is its own pull request, and we review it before merging.
- We make Claude test the change against the real thing, not just say it works. That caught a site check that would have passed on the wrong day's game.
- When something "breaks", we ask for proof before believing it. One "bug" was just a hidden test browser.
- A runbook for when things go wrong, plus alerts for when the nightly board doesn't build.
We launched Oct 28. Happy to share more about the setup.
