The Bugged Dev (@thebuggeddev)

Only if education could be this interactive ❤️‍🔥 I've had a looong wish to build something genuinely useful through vibe coding, and I finally did it. A 3D human anatomy application built with @threejs using GPT 5.6 Sol. It all started with a single design image that I created using GPT Image 2.0. I then used it to generate every 3D organ image, one by one. Next, I converted each of those images into 3D models using @tripoai (and no, they didn't sponsor this 😄). After that, I opened Codex, wrote a master prompt based on the design, and gave it the prompt, the design image, and all the 3D models. Codex built the first version beautifully, but there was one big problem. Every single 3D model was nearly 120-150 MB. That obviously wasn't practical for the web and was giving a performance of 16fps. After a few iterations, Codex optimized each model down to roughly 2–5.5 MB while preserving the visual quality, reducing the total asset size from ~900 MB to just 28.6 MB. And each model loads on demand. Along the way, Codex also generated those anatomical illustrations showing where each organ sits in the human body, and even created the interactive hotspot markers that explain different parts of every organ. It handled all of that. The process wasn't exactly one shot, but it also wasn't difficult. You just have to do it step by step. It genuinely felt like building something that could make learning anatomy much more engaging. The inspiration came from @DilumSanjaya's 3D animal plant cell project. I remember seeing it and thinking, "I want to build something like this one day." And I did it :D Live: Code:

My honest take on @Kimi_Moonshot K3 👀 As soon as I got access to Kimi, I put it through the exact same 3D football stadium challenge I had previously given Claude Fable 5. Fable 5 finished in under an hour. Kimi took almost 3 hours 🥵 At first, that was a very bad impression but i decided to see what's taking it this much of time. It was running E2E tests, validating desktop, tablet, and mobile, taking screenshots, finding failures, fixing them, even adapting for low end hardware and low FPS before moving on. All these that Fable 5 never did. None of it because it wasn't able to run this WebGL app on a headless browser. Kimi also shipped a clean React + Three.js codebase with proper components while Fable, as you might have checked codebase, generated one big HTML file with everything stuffed in. With all of this happening, it felt like I was doing more "Vibe Coding" with Fable 5 and more "Vibe Engineering" with Kimi K3. It feels like it's spending more time making sure the code actually works and easily scalable. Really impressed so far. More Kimi K3 experiments coming soon. Code (Kimi): Code (Fable): Live (Kimi hosted):

Why do we still buy stadium tickets without ever seeing what the view from the seat actually looks like? ☠️ So I prototyped an idea. A 3D seat view experience for a football stadium built with Fable 5 + @threejs, where you can preview exactly what you'll see from your seat before buying. The entire 3D experience was working after the first prompt, and the whole prototype came together in just five prompts. This is the kind of 3D experience I'd love to see more of, tbh. Feels so good. Right now, buying a ticket gives you almost no sense of what the experience will actually feel like. We're still relying on static seat maps, charts, and boring UI layouts, when interactive 3D experiences could make that decision so much easier. If you think, 3D development has the potential to create genuinely useful experiences. This feels like the direction we should be heading. 3D is the future. I can already imagine this for cinemas, cricket stadiums, Wimbledon, concerts, and so many other venues. I'm planning to take this further. What should I build next? More stadium features, or should I try another venue? Let me know :D Code: Live: