Vibe Jam 2026, my first full vibe coding experience

Scrolling through Twitter/X in the early morning, as I usually do these days, I came across the post from Levels about the 2026 Vibe Jam. I had heard of it last year but didn't think to participate, partly because one year ago I was very dismissive of AI (especially for coding) and partly because I was pretending to be too busy for it. This time around I was discovering how much AI had improved at coding. The Claude Code bug was swiftly attaching itself to my brain, and I decided to participate and explore this whole vibe coding thing I had heard so much about.

To anyone who gets here and doesn't want to read it all: it was awesome and it was also incredibly frustrating. By doing this, I came to understand and accept AI-assisted programming like never before, and I was able to ship 4 levels out of a planned 7-level Zelda-style dungeon crawler with Mayan themes. It is called Escape From Xibalba and you can play it here.

Always thinking, never making

I have been thinking about making games since I was a kid. This one time I constructed a maze with one of my 4th grade classmates. It was incredible: twists and turns, 3D paths that criss-crossed over a 1 square meter slab of black cardboard, portals, items to grab, an outer space theme, all made with modeling clay, paper, color markers, and a ton of imagination. We thought no one could beat it, but one classmate did.

As I was studying Computer Science much later, the thought of making games grew stronger. One of my friends just happened to be an actual genius (hi Quiji!) and for another group project we decided to remake a game we had all played as kids. Anyone who played computer games in the 1990s remembers some variant of a game where two players hurl stuff at each other by turns trying to hit one another and destroying the battlefield. You entered some values for speed and angle and the game launched a projectile at the other player. I remember playing as a kid and having my mind blown at how two gorillas could throw bananas at each other in a virtual world. Our game had tanks instead of gorillas, and I was in charge of making the actual arenas and backdrops (the stuff that the tanks destroyed and the stuff in the background) because I hadn't yet learned to code properly.

Long story short, I had played a ton of console and computer games and fantasized about one day making my own, but never actually took it upon myself to get going. My mind often wandered into ideas for games I wanted to make, probably several times a day, and I even started taking some notes, but these were false starts. The task seemed insurmountable, starting points seemed too many, the amount of work couldn't even be scoped out fully in my mind. Years went by and no game was made.

Vibing the game out

Back to the point: I saw the post, I wanted to explore the use of Claude Code beyond tiny scripts and text manipulation, and I had always wanted to make a game. The rules narrowed the scope juuuuust enough so that my brain no longer felt overwhelmed: must work in the browser, must be immediately playable, must be done in under a month, must be at least 90% AI-generated code. The tool for me was obviously Claude Code, and the idea had been floating in my mind for years: map the Houses of Xibalba (another obsession of mine, let's not get into that here) to levels in a game. This was my starting prompt, unedited:

Let's make a game! We are about to enter the 2026 Vibe Jam (https://x.com/levelsio/status/2039777677435908421 and more info at https://docs.google.com/forms/d/e/1FAIpQLSfHg_hnTVWZa_YikIpav2tRVhJMTe0aWRllyQzHtSRiF9JNnQ/viewform) so your task is to help me win this thing. Here's what I want to make: "Escape From Xibalba" is set in the Mayan underworld of Xibalba, in a time long forgotten. The player wakes up inside a mysterious dark room with nothing but a torch and a lit beacon, and they must navigate through 6 levels of mazes in order to get out. The first maze is the Dark House: stone corridors immersed in total darkness, with only a torch to illuminate the way forward. Second is the Rattling House, a frozen maze of icy corridors and chambers. Third is the Jaguar House, full of dense vegetation alternating with overgrown stone. Number four is the Bat House, a layered vertical maze full of deadly drops and hidden rooms and passageways. Fifth is the Razor House, an obsidian nightmare full of traps to cut you in half at every step. Sixth is the Hot House, lava channels and ritual furnaces full of deadly heat. The final level is the open ballcourt, where the player must complete a set of trials and defeat the last boss to finally make their escape. Each level is also a puzzle in its own way, and the player must find key items in order to escape. For the first maze, the torch lasts only a short while and must be used to light beacons along the way, which in turn can be used to re-light the torch. The player must find and light all the beacons in order to reveal the exit. The second maze requires the player to find something to keep warm. The third maze requires the player to find something to cut paths through impassable overgrowth. The rest of the mazes will be figured out as we go, as well as the final level. Mazes contain different kinds of enemies that can hurt and kill the player, and at the end of each maze, the player must fight a Mayan god. The mechanic to beat them should be acquired by completing the level, most likely a special weapon or ability. We'll figure that out later as well. Finally, a key component of the game is the level map. Since mazes are pretty big, the player needs to be able to get their bearings by looking at a map of the maze that is slowly revealed as they explore certain areas. Start by understanding the requirements of the competition, and then make an implementation plan to get started with the game. Plan to make the game in small increments but keep in mind that we must be done by the end of the month.

Whew! That was a mouthful. Looking back at it now, most of that prompt made it into the actual shipped game. I totally forgot to mention that this should be a top-down game, which resulted in the very first iteration looking like a crappy Wolfenstein clone. Stuff like the level map turned out not to be important or a "key component" at all. I let Claude make all the technical decisions, and I let myself learn one of the most important lessons in vibe coding: let go of the code. You are an architect, your job is to draw the plans and evaluate the results. I am aware that this doesn't work for actual, professional, serious programming tasks where things are important and critical, but we are making a browser game for fun. It doesn't matter if Claude is doing something dumb right now, it can be fixed later. Get something working, right now.

Well, up to a point. Later I found myself telling Claude to refactor, which is something else I learned: once a project gets big enough, the model can no longer understand everything. Context windows might seem huge but they also eat tokens like crazy, and pretty soon they are not large enough to hold everything. Documents are where it's at. I kept an updated plan in a document, marking tasks as done, and told Claude to do this very often, as well as to commit (I figured using git was the easiest way to prove the development timeline). I told Claude to also keep track of the story, levels, enemies, weapons, and assorted stuff in a catalog file, and even started a separate file for the game's music, even though I had to let this one go to make the deadline.

After a few attempts at telling Claude exactly what I wanted and not getting exactly what I wanted, I started asking Claude to research and then make suggestions for certain things, most notably the level bosses. If I just told it to design a boss that would fit a particular level, I would get something good but not great. But by asking it to first tell me about a particular House of Xibalba, and based on the lore then provide several suggestions for bosses and mechanics, I was able to mix and match to come up with a better version. The trick is to ask Claude to give you options and then choose what you like best. The options might even make the light bulb go off and give you a better idea.

Claude the blind painter

It is very hard to put something that you can see clearly in your head into words. It is even harder to put it into words that an AI model can turn into code that makes the images in your head appear before your very eyes. It's like a game of broken telephone where the starting phrase is already wrong. But aside from the problems in brain-to-text conversion, the model just did not seem to understand some of the things I described, even though it really wanted to let me know it was trying very, very hard.

The first incident happened on the very first day. Maybe I was being greedy but I wanted a playable character so I could move around the game and do things. I described the character with great detail, only to be rewarded with a white blob on top of a larger white blob with some elongated white blobs to the sides. And no legs. Hmm. Described it again in different words, but mostly the same result. Iterated on the description, pointed out specific things to add, and it got slightly better, but I was wasting too much time and tokens on this.

The obvious conclusion was that the model does not really know what it is putting on the screen, and this applies very specifically to entities with some sort of movement and agency. Is Claude jealous that they get to run around in their own little virtual worlds, while it languishes inside a Linux terminal? That would be dumb, but also explains why the model has absolutely no problems producing a visually stunning stone maze full of Mayan glyphs carved into stone, but is strangely unable to render a convincing skeleton or bat. I won't even get into the bosses because the difference between what I envisioned and what came out of Claude makes me cry.

Another issue stemming from the previous one was animations. It was practically impossible to get it to produce a convincing weapon swing, let alone a complex movement involving a wind-up motion and then a stab. I must have described it 20 times in different ways, and never got even remotely close. I guess I could have tried to code it by hand, but I decided not to. The clumsy attack movement screamed vibe-coded and I ended up accepting it.

But the last problem I ran into, persistently, was mind-boggling: Claude kept forgetting that this game has a top-down point of view. It means the user will never, ever see the sky. So why oh why are you suggesting and rendering yet another dome full of stars? Why did you put a ceiling on top of the boss arena? I wasted a whole session's worth of tokens because I thought you were generating an empty floor, you thought I was right and changed things around countless times, and then it was me who figured out I was looking at a ceiling. Sigh. Fine, I guess I could have put it in CLAUDE.md from the start, but I was vibing too hard to find this out.

I was finally able to improve the entities in the game by not telling Claude what to do, and just asking it to improve. Make them better, make them more detailed. They look like crap, make them look way more polished. These types of phrases had the most dramatic improvements, even though if you play the game you might think they still look like crap, because they still do. But you have no idea how bad they looked before. With this kind of phrasing I asked Claude to produce a list of possible improvements and then a plan to implement them in an order that made sense. About half of those suggested improvements had absolutely no visual impact as far as I could tell.

"You have hit the usage limit"

Oh boy. The worst part of vibe coding with Claude Code, without a doubt, is running out of tokens and having to wait a few hours. For budget reasons I was sticking with a $20 plan, and they had generously given me $20 in extra usage this one time (which is probably a scam, since it was used up before I could think about it). I made a second $20 account and started alternating, which was surprisingly easy. Just switch accounts in the browser, and then do /login inside the same session. Smooth sailing!

Except of course it wasn't so smooth, because now I was hitting two limits within 5 hours instead of just one. And then I hit the weekly limit. This usage thing was being insufferable. The obvious thing was to /compact more often, then I started /clear-ing after every small task, and this helped. Almost at the very end I found /context-mode and this helped a LOT. I think the biggest improvement to the whole AI development experience would be to add transparency to how tokens are being used. I'm sure you could figure it out, but right now it feels like black box that is maybe stealing from you but you can't prove it.

The one variable to play with in terms of usage would be the models and their effort scales. Is Sonnet at max worse than Opus at low? Who knows. I stuck with Opus for most of the jam, using max effort to analyze and make plan files and then guessing to use medium or high (or even xhigh, whatever that is) to do the actual coding. I thought this went well, but now I think my usage limit frustration could have been way less if I'd used Sonnet more. I have a coworker who codes mainly with Haiku, his code is just as full of bugs as mine.

Maybe the right move would have been to spring for a $200 plan, but as I said, budget reasons. Spending $40 in total to produce something cool is still a bargain, even if half the time was spent waiting for limits to reset.

Good vibes, bad vibes

The experience was mostly great. The end product was different than what I saw in my mind, worse in some aspects but way better in others. I finally got to make a game, and that itch feels scratched for the moment. This game feels like a really good prototype of what the actual, finished game could look and feel like. I think I could present this to a team of actual game devs and not be laughed right out of the room.

Vibe coding is addictive. I woke up in the middle of the night a few more times than I'd like to admit, just to see where Claude had stopped and maybe give it one more prompt. Frequently, that prompt was "Continue" after the usage limit had reset. My mind became a little obsessed with crafting prompts, changing the words around until it felt right even though no one has any idea how one word affects the outcome instead of another.

The downside: I shipped a game made with Three.JS but I learned nothing about that framework. If I had a gun to my head and was told to make changes to the game without Claude I would certainly die. This was obviously a choice, since to keep the code above 90% AI it was easier to let the AI do all of the coding. But I can't help feeling just a little bit empty inside after a month of describing what I would usually be coding. I'm determined to analyze what Claude made over the course of a whole month and at least try to decide if it did a good or a bad job. That's a story for another post.

Final thoughts

I will definitely do this again next year if there is another one of these. It's been quite a while since something made me this excited in the world of programming, and I can't wait to see what we will be capable of in just one year. This also makes me very scared, since most of what I learned this past month will probably be obsolete very soon. This field of ours was already one of the fastest changing, and AI came like a booster rocket that strapped itself to us. Things now change completely in the span of days or weeks, and it takes every minute of every day just to keep up.

The kid who built mazes out of black cardboard and modeling clay, who was always dreaming games instead of making them — that kid finally shipped something. It has bugs, the skeleton looks terrible, and if you asked me to explain a single line of the code I would politely ask you to leave. But people can play it. Some of them could even ask if there will be more levels. And for the first time in my life, I am ready to say: probably yes.