How a Vibe-Coded Capybara Game Won $25K in 15 Days
A solo iOS engineer built a 3D game almost entirely with Claude Code and won Vibejam 2026. Here is the playbook.
A solo iOS engineer built a 3D game almost entirely with Claude Code and won Vibejam 2026. Here is the playbook.

An iOS engineer with nine years of experience but zero game-development background just won Vibejam 2026 — and roughly $25,000 — with a 3D game built almost entirely by Claude Code. The game, A Game About Capybaras Delivering Food, was made in about two weeks. Every line of code, every texture, the music, the 3D models, and even the in-game level editor were generated with AI. It is one of the clearest signals yet that vibe coding has crossed a threshold: a solo builder with taste and a plan can now ship something that used to require a whole studio. Here is how it was done, and what you can steal for your own projects.
The most striking thing about this build is how ordinary the toolkit is. There was no exotic infrastructure — just consumer AI subscriptions wired together with intent. The developer ran Claude Code on the Max 20x plan (topping up about $100 to jump from 5x to 20x) as the coding engine. Textures and illustrations came from GPT image generation and Grok. 3D models were produced with Tripo3D’s Pro plan (about $20/month) by converting reference images into meshes. Music and sound effects were handled by Suno and ElevenLabs on their free tiers. The engine was plain Three.js, running in the browser.
Total tooling spend was on the order of a few hundred dollars. For that, the project produced more than 27,000 lines of code across 188 commits, a handcrafted 3D city, a physics-driven delivery mechanic, multiplayer over WebSockets, and a full cinematic intro. The lesson for builders is blunt: the barrier to a polished, original game is no longer capital or a team. It is knowing what to ask for.
The single most replicable technique here is how the agents were orchestrated. Rather than one long chat, the developer ran two to three Claude Code sessions simultaneously, each working on a different part of the codebase to avoid merge conflicts. New features always started in a fresh session with no prior context, keeping the model focused and its output clean. A separate, long-running session was reserved for bugs that genuinely needed the full history of what had been built.
This maps directly to a lesson every serious agent user eventually learns: context is a resource you spend, and clean context produces better code. Isolating unrelated work into separate sessions stops one task’s noise from degrading another’s output. If you are building anything non-trivial with a coding agent, treat sessions like short-lived branches — one concern each, spun up fresh, thrown away when done.
The biggest insight from the post is not about the game at all — it is about tooling. Early attempts to have an LLM generate the game’s map wholesale failed: the output was a single unoptimized mesh that fell apart when you zoomed in, with no way to control detail. Instead of fighting the model, the developer asked Claude to build a custom level editor — with brushes to raise, lower, and paint terrain, a procedural road system with intersections and sidewalks, and object placement with move, rotate, and scale.
That editor is what made the handcrafted city possible. A second tool, a full cutscene editor with a drag-and-drop timeline, let the developer record camera paths through the city and assemble a cinematic intro like a real video editor. The takeaway is a genuine mindset shift: the highest-leverage prompts often are not "build my feature" but "build me the tool that lets me build my features faster." Every hour spent generating tooling compounded across the rest of the project.
One of the sharper product lessons in the build is how the core mechanic was tuned. The game’s central challenge is delivering a stack of food from point A to point B without dropping it. The first physics implementation had items sliding realistically side to side — and it was boring. The developer experimented until landing on stacked items that form an arch as you steer, with a percentage chance of toppling once you cross a threshold. Crucially, the values were tuned to be less realistic and more fun: a probabilistic wobble reads as tense and playful in a way that accurate rigid-body physics never would.
This is a reminder that AI will happily build you a technically correct system that nobody enjoys. The judgment about what makes something feel good — where to break realism, how much randomness to inject, when to remove a feature like the banana peel that did not land — is entirely human. The convenience-store minigame, a slippery-floored fruit hunt under a 45-second timer, exists purely because the developer kept asking "what would make getting the food more fun?" and iterating on the answer.
For a game jam, the multiplayer turned out to be surprisingly tractable. A single global lobby hosts everyone over a live WebSocket on Cloudflare, relaying each rider’s position and item stack to all other players. But the write-up flags a real engineering gotcha: bandwidth grows with the square of the player count. Every rider broadcasts roughly ten times a second, and the server relays each message to every other client. Five players is fine; fifty players means fanning out fifty messages to fifty clients, ten times a second — a quadratic explosion.
It is a useful illustration that AI-generated code does not exempt you from understanding your own architecture. The naive relay works beautifully at demo scale and would fall over in production. If you are vibe-coding something with real-time or networked components, you still need to reason about the scaling curve yourself — the model will build exactly what you asked for, quadratic blowup and all.
It would be a mistake to read this as "AI did everything." The developer was explicit that AI wrote 100% of the code, art, audio, and models — but the human did all the deciding. That meant writing precise prompts for code, art, and 3D generation; playing the game constantly to tune the feel; placing cameras for cinematics; and, critically, spotting the gaps where a new tool was needed. The one piece of heavy manual work was laying out the city by hand in the custom editor, because getting AI to produce exactly the right map proved harder than building it directly.
There is a concrete craft tip buried in here too. To get good 3D models from image generators, the developer always supplied at least three angles — front, back, and both sides — rather than letting the model guess the geometry. More reference angles meant dramatically better meshes out of Tripo3D. The same discipline applied everywhere: the more specific the input, the less the AI had to hallucinate.
The winning entry leaned into charm as a distribution strategy: a PS1-inspired low-poly art style, an in-game phone with "Capyfied" parodies of real apps, a slippery convenience-store minigame, day-night cycles, and rain. None of that is load-bearing engineering — it is taste, applied relentlessly. And taste is exactly what the developer identified as the new constraint. As they put it, time shifts from coding to deciding: you spend less time writing code and more time planning, testing, and making judgment calls. Many people, they noted, struggle not with the tools but with turning a clear thought into a clear prompt.
That is the real headline for builders. When code generation is nearly free, the scarce skills become product sense, the ability to specify precisely, and the patience to iterate on feel. The capybara game won not because Claude Code is powerful — though it is — but because a builder with strong taste knew exactly what to point it at.
The developer had entered the same jam the previous year, which makes the comparison especially credible: in their own words, it is clear AI coding has crossed a threshold. A year ago, standing up a playable 3D mechanic with custom tooling, multiplayer, and a cinematic intro in two weeks solo would have been implausible. This year it was not just possible but good enough to win. The models improved, but so did the workflow — parallel sessions, tool-building, and precise multi-angle prompting are practices, not features, and they are what turned raw capability into a shipped product.
It is worth being honest about the ceiling, too. The developer has no plans to put the game on Steam: it is a five-to-ten-minute experience, perfect for a jam but far from a complete commercial title with hours of progression. Vibe coding got a delightful MVP to the finish line astonishingly fast; turning that into a durable product is a different and larger problem. That gap — between a magical demo and something people pay for and keep playing — is where the next wave of hard, human work lives.
A $25,000 game jam win built by one engineer in fifteen days is not a fluke — it is a preview. The tools to generate code, art, audio, and 3D assets are now good enough that a single person with a clear vision can produce work that reads as a finished product. The winners will not be the people with the most compute or the biggest teams; they will be the builders who know what to make, can specify it precisely, and have the taste to tell when it is good. If you have been waiting for permission to build the ambitious thing, this is it. Read the full write-up and play the game, then go build your own tools.
Get the weekly digest for AI builders & vibe coders. Curated tools, resources, and stories. Skip the scroll.