You can freely download the source code and compile the game here:
https://github.com/Rolandjg/fableflight

The game is fairly performant for how detailed the graphics are, you will need a reasonably powerful GPU though. This is recorded on my RTX 3060.

I have two Claude Plus subscriptions, I was able to build this in a week using Fable 5.2 to solve complex rendering tasks and model the plane. Opus 5.5 was the main workhorse that made the world feel alive.

i kept missing hackathons i actually wanted to participate in. finding them always meant going through unstop, devpost, devfolio and a bunch of other sites separately.

finally, i tried building something with antigravity & claude code. i asked claude design to create the design for the site, then used antigravity to build it and bring the listings together for me.

this is what it turned into. it's called brabble, and i'm honestly quite excited to share it here.

it brings the listings together so you can find something you're eligible for while registration is still open. you can also just tell it what kind of hackathon you're looking for.

5k+ people have signed up so far, which feels pretty wild considering this started with me wanting an easier way to find one.

i'd love for it to eventually become a place where we find interesting hackathons and go build stuff together.

site link brabble.ai

Spent a week of Claude limits rebuilding a trading grid I’ve had in my head for 15 years

About 15 years ago I worked with a derivatives trading team at one of the biggest investment banks in the world. The task sounds simple: a trader watches quotes, and positions update in real time, per client, per portfolio or for the whole bank.

Back then we had our own hand-written grid in C#, and now I’ve rebuilt the idea in Rust on gpui-kit. Here is the repo link.

In my benchmarks it’s 11x faster than the built-in DataTable in gpui-kit.

Vibe coded with GPT 6 Astra. Quite close to the threejs webgpu version..

• Unreal Engine 5.9 MegaJam Preview, built with C++.

• Compiled to WebAssembly; rendered in-browser with WebGPU.

• Uses Unreal’s mobile-deferred renderer.

• Custom ocean with four baked FFT wave cascades.

• Original Three.js boat model, imported through Blender; custom fog and reflections.

Has anyone used both? I mostly use chatgpt for image gen and code reviews and was thinking about trying gemini out instead.

Hi AI folks!

I've been doing gamedev as a hobby for around 10 years, and I'm finally getting to my first ever Steam demo! This video is one year of development squeezed into one minute.

The game was fully vibecoded (Claude Code and Codex), but it wasn't an easy ride. I'm a software developer with 15+ years of experience. AI can do complex things very fast and save you a ton of time, but it still needs to be guided by experience and good planning.

Some numbers after one year: about 500k lines of C# in Unity, roughly a quarter of it is tests, over 15,000 prompts and 840 commits.

Some tips I came up with during development:

- Define future goals upfront. I'm planning a local co-op mode, so it's written in the rules and every feature is built with that in mind. Will save a lot of time once I will switch to this task!

- Build core systems early. I didn't have all languages from day 1, but right after prototyping I made a system for quick language integration. Every line in the game has a key and is never hardcoded in code or UI.

- Keep an index of your systems. Once the codebase grows, AI starts losing track of it and reinvents things instead of reusing what already exists. Make a separate index for mid-big features and push AI to read it before any change. Keep it short.

- Keep a list of repeated mistakes. If AI makes the same mistake again and again, write it down and add a rule to check that list before any change. This helped me a lot to stop going in circles. Keep it short.

- Use your voice. Maybe it's obvious now, but it wasn't for me at first. You speak much faster than you type, so AI gets more context. Make sure you have good voice recognition.

- Ask for tests with every feature and every bug fix. AI breaks old things without noticing. Tests catch it before you do. A quarter of my code is tests and I don't regret a single line.

- Fix the cause, not the symptom. AI loves to drop a quick patch right where the bug shows up. Make it find the root cause first, otherwise patches pile up and start fighting each other.

- Make it show you. Review and read everything carefully! Some people ignore outputs or even checks of what id did. Sometimes it's just enough to read text carefull to see what AI did wrong, sometimes video/screenshot. Saves a lot of back and forth.

- Keep tunable values out of code. All balance numbers live in config files, and AI built me simple HTML editors for them. I tweak balance with sliders, no prompts needed.

- Run agents in parallel. I have several copies of the project, each agent works in its own, and a shared task board keeps them from stepping on each other.

Hope it's helpful! Happy to answer questions in the comments.

Would really appreciate it if you wishlist game on Steam

Thanks for reading!

Fable 5.2 made this in 30 min, a psychedelic endless runner.

I want to take it to the next level. Currently the speed is maxed at 98 m/s around 8900m, I am testing out a cap at 80m/s it is still fast, my highscore was at 72m/s (4500m)

I upload it later so you can test it out.

What do you think?

I've been building a multi-tenant business app (invoicing, payments, storefronts) mostly with AI coding agents. It runs a couple of real businesses, so bugs cost actual money. These four got past type checks, tests and code review. None of them throws an error, which is why they're dangerous.

1. Webhook marked "seen" before the work was done The payment webhook saved the event ID first (to block duplicate deliveries), then updated the payment. If the update failed, the provider retried, the handler saw the ID, replied "duplicate, 200 OK" and skipped it. The customer paid and nothing happened. Fix: if anything fails after you claim the event, release the claim before you return.

2. Status update with no "from" state update({ status: 'paid' }).eq('id', id). Looks fine. But a payment arriving for a cancelled or draft invoice flipped it to paid and sent a "thanks for paying" message. The UI had a proper state machine; the database write ignored it. Fix: every status write says which states it can move from: .in('status', ['pending', 'overdue']). If 0 rows match, skip the side effects and log it.

3. A cache check that quietly always said "stale" A cron job rebuilt a 16 MB catalog file only when row counts changed. One of the count queries asked for an id column the table didn't have. The query failed, returned null, and null meant "stale", so it rebuilt every 15 minutes for days. I found out when Supabase cut off the API for going over the egress quota (7.3 GB on a 5 GB plan). Fix: a failed check should be an alarm, not a quiet "rebuild everything".

4. Writes on the request path on a free tier A public status page wrote to Cloudflare KV whenever its cache looked old. The cache counted as old after 2 minutes, but the cron refreshed it every 10, so most visits (bots included) did a write. Free KV gives you 1,000 writes a day. I got the 50% warning email. Fix: only the cron writes. Requests only read.

The pattern in all four: the AI wrote the happy path correctly and the failure path wrong. When I review AI code now, I skip what it does and ask one question: what happens when this line fails?

Happy to look at anyone's webhook or RLS setup if you're stuck.

Quick disclaimer for the purists: I did not write a single line of this. I described what I wanted, plugged things in, put the headset on and reported back. Claude did the rest.

The idea: falling notes (Synthesia-style) landing on the keys of my real piano, inside the headset, standalone. No PC, no streaming. My piano is a Yamaha Clavinova CLP-230 from around 2007.

How it actually went:

• Day 1, morning: I asked if this was even possible. Instead of just saying yes, it went and checked: Steam Frame docs, Linux USB drivers for old Yamaha pianos, a known USB bug on the Frame. Then it said: before we build anything, let's prove the piano talks to the headset.

• It SSH'd into the headset from my PC, I plugged the piano in, played a few keys and pressed the pedals. It read the raw MIDI bytes and confirmed all 88 keys, velocity and even half-pedalling. Biggest risk of the whole project, gone in 15 minutes.

• Same morning: a tiny Godot test app was running on the headset. Keys lit up when I played. Passthrough worked. The virtual keyboard was floating somewhere random in my room, so it added a calibration: touch the lowest and highest key with the controller. Result: 121.7 cm measured vs 122.2 cm on paper.

• Day 2: I asked for the real thing. Falling notes, wait mode, MIDI import, feedback after each song, nicer menus, a proper font. I also told it the app should be called KeySight. It built it on my PC, tested it with a fake player, deployed it to the headset over Wi-Fi and added it to my Steam library. I then played for over an hour.

• Day 3: I said "put it on GitHub, public". It scrubbed my username and home network details out of the code and history, replaced some MIDI files whose licence it wasn't sure about with its own arrangements of public-domain pieces, wrote an English README and pushed it.

What it did that I didn't expect:

• It said no a few times. I asked to "copy the features from piARno" (an open-source Quest app). It explained the code can't run on the Frame, rebuilt the ideas in Godot and credited them instead. I asked for fully automatic calibration. It explained apps can't access the Frame's cameras, and came up with something better: you press a few real keys with the controller tip, the piano tells the app which key it was, and it computes where all 88 are.

• It read the logs of my practice sessions and fixed things I never reported. One controller click sometimes counted as two. Playing the same key twice counted as an error.

What went wrong (because it's vibecoding, something always does):

The evening it got everything ready for GitHub, it also added a "piano unplugged?" check. On the headset that check misfired, so the app dropped the connection to my piano every 3 seconds. Notes got lost, keys stayed lit, and the next morning I told it "it's not as nice as last time and there are weird coloured blocks over my piano". It found the cause in the log in a few minutes, owned it, rolled it back. Lesson for me: AI is fast, but "it passed the tests on the PC" is not the same as "it works on the headset". Always try the real thing before you share it.

Stack, for those who care: Godot 4.6 + OpenXR, native Linux ARM64, USB-MIDI straight into the headset's USB-C port, passthrough via alpha blend. Built with Claude (Claude Code), partly in the cloud, partly on my own PC.

Repo (MIT): https://github.com/philippeschots-cloud/keysight

Happy to answer questions about the process. And if you have a Steam Frame and a digital piano, I'd love to know if it works for you.

PS: I've mastered the first part of the Für Elise :-)

I built Blockbrain.gg because I love Minecraft, and help guides and wikis are sometimes out of sync.

Graphics for wikis are often not versioned. Build videos are sometimes for either Java or Bedrock, or a different version of Minecraft. At the advanced level, Minecraft information just isn't precise enough.

I was inspired by Crunchbase, Minecraft Wiki, and many other Minecraft sites.

So over the course of 6 weeks+ I have been validating and data wrangling core mechanics in Minecraft for people and AGENTS. I am not 100% there yet. But I'm at a point where I would like more eyes on it.

This site can be an awesome field guide for advanced Minecraft players.

This site can be a Structured Data resource for people playing with Agents and Minecraft together.

One personal goal of the site is to help me build a validation engine for Custom Maps I want to play and build. All to often I buy an addon map, and it BREAKs. Gameplay get's stuck on Sky block, Oneblock, and other maps when you don't have the exact block you need. Sometimes you are actually stuck, other times you just don't know the game mechanic necessary to get unstuck.

This site is a love song to people that want to play Minecraft without cheats and to get unstuck. To get sort of a google maps turn by turn help to get to the block they need.

This site has been challenging, it's an exercise in Ontological exploration and simplifying the immense complexity hidden in Minecraft.

There are over 1800+ block and item types in Minecraft and that will only continue to grow.

This site is still a work in progress considering it's scope. How would you use it? What features would you want? What features would your agents want? What do you love, what do you hate about this project ( be kind, but critical )?

Eventually, I might build a harness and set of tools to automatically validate and update the raw data on this site.

===
PS.

== I also want to use this site as a portfolio piece to get an agentic job. ==

I collected 45s as a teenager in the 1950s and always wanted a jukebox. Never had the money or the room.

This year I decided to build one on my computer. I can't write modern code, so I described what I wanted to Copilot, Gemini and Claude, and they built it, piece by piece, over a couple of months.

It's called BotBox. It plays the music on your own computer with a spinning record, a tone arm that drops and returns, needle scratch, vinyl crackle, and a Disk Jockey who introduces songs. You can even put a family photo on the record. It has a "Built by Bots" plaque on the front, because that's the truth.

The hardest part wasn't the bots, it was me learning to explain exactly what I wanted. Happy to answer questions from anyone thinking of trying this. By the way, it's a html file and written as an example of what can be accomplished with text to code. At the head are paragraphs of introductory material. Then the fully annotated balance of the program. Lots to learn - your bots will be impressed.

(Demo at botbox.media if you're curious.)

(Demo at botbox.media if you're curious.)

Was inspired by Plotropolis, but the tool got repetitive fast, so I tried to make something similar in style, but a version which creates isometric towns and city line drawings based on actual OpenStreetMap data to get more variety. Now OpenStreetMaps API has no 3D building data, just 2D shapes and approximative height, so all buildings are generative made up and so it's more of an art project than a real mapping tool. You can try it out here: https://www.isometrictown.com/

Some locations have very poor data in OpenStreetMap, so those will look very sparse, but it works reasonably well in most of Europe, the US, Japan etc. I picket some good examples in the dropdown below the location search.

Btw, if you see something weird, a rendering bug with a certain feature, I'm constantly on the hunt to fix those, to make the algorithm catch as many edge cases as possible. Would be nice if you could share the link with me of wherever you found the bug.

Looking at just the digits of Pi was boring for me, so Me and Gemini 4.0 Hydrogen made every digit of Pi a tile. with all of these tiles, it forms an entire map of just Pi digits in tiles. It's a fun experiment to showcase the uses of pi.delivery. No token limit was reached during this progress.

Try it out at https://pi.araoz.ar/

https://beta.distantclunk.com/

What it is

Distant Clunk is a spooky first person puzzle game set inside a pyramid. You sing three notes to lift relics and carry them to their plinths, and a shout drives back the things that hunt you. There is a short intro tomb that teaches the mechanics, then procedurally generated levels that get harder. It also has a comfort mode and a fixed overhead view for people who get motion sick.

It is free to play: open the link in a browser on desktop, tablet or phone and allow the microphone. No sign-up, no install, no ads. Your voice is processed on your device and never sent anywhere.

How Claude helped

I'm a designer. I have played with game mechanics for years but never had the skills to build one. I wrote the concept and the design direction, and Claude (Fable 5.2, in the Claude app) wrote all of the code. I did not write a line.

The process, over 23 versions so far:

- I gave Claude a pitch: the setting, the voice mechanic, and constraints (run in a browser, stay tiny, no libraries).

- Claude's answer to the size limit was to skip 3D models entirely. The whole tomb is a signed distance field drawn by one raymarched fragment shader, and every sound is synthesized with Web Audio. There are no image or audio files, which is why it is 61 KB.

- Claude wrote the pitch detection (McLeod method) that turns a hummed note into a control, plus the filtering that stops the game hearing its own rumble.

- Claude tested each build itself before handing it over: it ran the game in headless Chrome, fed recordings of humming into a fake microphone, and scripted full playthroughs.

- I played each build on a Mac and a Pixel, described what felt wrong in plain English ("the doors sound squelchy", "it drops the object when I move", "my friend gets motion sick"), and Claude reworked it. The lock-and-release carrying, the hiding enemies and the overhead view all came out of that loop.

- I kept a set of project instructions and a running notes doc in a Claude Project so the design stayed consistent between sessions.

What didn't go smoothly

Phone audio. It still crackles on some Android phones, especially over Bluetooth, and we are a few versions into chasing it. Claude can't hear my phone, so that part is slow guess-and-test.

There are release notes on the title screen (bottom left) that go into how the engine works. It's an early version, so feedback is welcome, particularly on whether it hears your voice properly.

I wanted to actually see what happens inside a language model when it writes a sentence, so I built this!

What you're looking at:

- The stars are the 36,864 MLP neurons (12 layers × 3,072). Each layer is a disc, and neurons are positioned by a UMAP of their output weights, so neurons that write similar things sit near each other.

- Brightness is how strongly that neuron fires on the current token, scaled per layer so tokens are comparable. Gold means it fires positive, blue means negative.

- The beams are real attention weights from the current token back to earlier ones, one colour per head. The side panel shows the model's actual top 10 next token probabilities.

- You can hover any star, beam or token to see its exact value. There's also a raw mode that turns off all the bloom and fades, so every pixel on screen comes straight from the data.

- How I know it's not lying: the test suite runs the model exactly the way the app does (KV cache, token by token) and compares every activation, attention weight and residual norm against a separate uncached forward pass read through different hook points. Then it checks the bytes the browser actually receives too.

Honest limits: it's GPT-2 small only for now. Single neurons mostly don't mean anything clean on their own, it's the patterns that are interesting. Values are sent as float16, so about 3 significant digits.

Setup is make setup && make start, then open localhost. No GPU needed.
Repo: https://github.com/lak7/thinkspace
Would love the feedback!!

I had Claude set out to make an Australian accounting simulator. I was heavily inspired by BitLife's gameplay starting out but over time the concept evolved considerably as I began incorporating more complex systems such as team management, practice management, and client management. Now it's more of an Accountant simulator with WIP life simulation elements.

One of the biggest challenges throughout development has been getting the UI right. It has gone through numerous iterations, and looking back, my original one-shot prompt was pretty poorly optimised, which made the early development process more difficult than it needed to be.

Visual assets were another particularly tedious part of the process. I generated all of the artwork using ChatGPT Plus, but getting everything to layer properly onto the character sprites still required manual editing in Paint.NET. This was especially time-consuming because the process had to be repeated for different outfits, hairstyles, and hair colours across the various ethnic character sprites.

At this stage of development, UI optimisation still remains one of the main ongoing challenges. There are also still areas where the writing is unnecessarily descriptive, particularly Claude's obsession with explaining things that should already be self-evident through the interface. The game is still missing several major systems needed to complete its life simulation aspect, like property ownership, family, and off-work activities. These are some of the bigger features I want to eventually introduce before I consider the overall concept complete, after the weekly limit refreshes on Tuesday of course.

The model I used was Opus 5.5, Effort Low - Maximum depending on the complexity of the prompt. Fable 5.2 was used sparingly at the highest setting of medium, only when the free usage resets were deployed.

Klad is a drawing app with a fully exposed cli written in rust, that Claude code can use. It can lay down brush strokes one at a time, and each and every stroke remains editable by you or the agent.

Claude Code runs klad commands, the drawing is plain files, and you can open the same file in the Klad editor, which doubles as a fully featured drawing app with layers/brush engine/...

Klad van handle vector art, line art, pixel art, animations,... It's built with game assets in mind, but can do any art style you can teach claude to create really.

There is no image model inside klad. The whole goal is to provide tooling for claude code to use.

The second and third image attached are a couple of examples. The building one shows how easy and consistent it now becomes to ask an agent to make an edit to an existing drawing. This is totally different from the re-rolls you have to do with generative image models. Much less frustrating and with way better results!

This method of working is imo the way forward for human-agent collaboration in art.

How Claude code was used: I've had the idea for a painting app that could work with git for a while now. It would require a special format that is diffsble, and a really performant engine to render all brush strokes in real time as pixels. I didn't want it to be just vectors, as that would not enable paint blending and smudging etc. It would limit the possible art styles.

I had Claude implement this format in Rust, and build a performant render engine around it. Then it was iterating a lot, testing a lot, planning features, testing again... I did a number of performance rounds with Claude code before we got to the point where we are now: detailed 8k drawings with tens of thousands of brush strokes should be no problem for most modern laptops!

Happy to answer any questions!

Try it yourself at https://github.com/klad-app/klad
Or read the docs at klad.studio

Before people get upset with me, I don't think Fable is bad, I think it's probably the best model right now for one-shotting projects without much thought, just like the original was, but it's kind of a brute force machine more than anything.

It's stupidly expensive in that it'll run through your usage and credits with a single prompt while opus 5.5 will get you similar results for cheaper. Yes you have to guide it more, but the things you build are a fraction of the price and often just as good if not better.

IMO Fable 5.2's release was just to get people hyped up about claude stuff ahead of the IPO. "LOOK AT THIS AMAZING THING THAT FABLE DID WITH 1 PROMPT OH MY GOD" and like yeah it's impressive but it's not worth the money you spend on tokens.

Opus 5.5 is still probably the king for now

This is James. He lives in a low-poly terrarium as a simulation you can interact with: give him snacks, pet him, tap on the glass, and leave him notes. Everyone is watching the same frog at the same time.

Stack: Next.js on Vercel, Convex for his state, Three.js for the tank, and Claude for his thoughts.

The part I think is really cool is that the tank is a deterministic simulation. Every change (a snack, a tap on the glass, a new day) is an event in a log that only ever grows, and one function applies them. Same starting point plus the same events gives the exact same frames in your browser, in a replay, and in the videos I make of his day. Visitors can't overwhelm him either: there's one snack at a time for everyone, and he can only get properly spooked once every 15 minutes.

He's 9 days old today, and he just got a new enclosure today. Curious what you'd want to see next, and happy to do a deeper write-up on the infrastructure.

And I don’t mean this in the way you think (speaking to the senior devs here).

Why waste a day designing and normalizing a schema by hand when you can give an LLM a five-minute level 2 C4 diagram, the app's operations, the role separation, and have it produce a prototype schema, an ERD, and 3NF normalization?

With modular monoliths at the app level, the database’s isolation level will inevitably change when the user-base scales anyway, so immediately adding something like Flyway instead of worrying about getting it right the first time seems like a very intelligent thing to do.

I know there’s some anal people out there who will pour fuel to this fire, but what do I actually get from doing it manually these days?

“Make a 2.5D pixel-art game with lots of detail, and cut a trailer for it.”

The video above is the trailer. Claude rendered it as well: it drove the game in headless Chrome, captured the frames, and encoded them with ffmpeg.

What came out

• SKYWAVE, a cinematic platformer set in a foggy port city. You play a pirate radio crew trying to stay on air through one night.

• 8 chapters, including a gunfight on the docks and a boss fight against a sea monster called the Undertow.

• There are no image or audio files in the repo. Every sprite, building, character and sound effect is generated in code.

• A real 3D world sits behind the pixel-art play plane, with a ground that runs to the horizon and buildings that have sides and roofs. WebGL2 adds lighting, bloom, depth of field, rain and wet-floor reflections on top.

• A varied cast: heavy guys, old men, women, kids, a swimsuit character.

• TypeScript and Vite, with 118 tests passing.

Repo : https://github.com/rokrokss/thelastnight