Vibe Coding

When I saw the Encode Vibe Coding Hackathon, the premise stood out: every single line of code had to be generated by an AI. No hand-written fixes, no quick edits at the end.

It was not about whether AI could magically build a game. It was a test of how far a small team could get when every code change had to be prompted, reviewed, and accepted. We signed up as a team of four: Celvin Kuhn, Lucas Härtel, Laurin Wittich, and myself. We all work together at Accenture and had collaborated on several projects before, which gave us a strong foundation going into a weekend where coordination would matter as much as coding. That was enough to convince us to sign up and head to London.

# Friday in London

We arrived in London on Thursday evening. On Friday we had the morning and early afternoon before the hackathon started at 16:00, so we spent a few hours exploring the city. London made a strong impression on me. The streets were full of people, the city felt incredibly alive, and the mix of historic and modern buildings gave it a unique atmosphere. Later we stopped by the Accenture office, grabbed a coffee, caught up for a bit, and then headed to the venue.

# The event

The hackathon took place at Encode Hub in Shoreditch. Friday evening started with registration and a series of short sponsor talks. Companies like Vercel, Sui, FLock, Codeplain, and Solvimon each had 15 to 30 minutes to pitch their tools and bounties.

Codeplain talked about spec-driven development with agentic skills. Their bounty required using the **plain** format and submitting the resulting files and configuration. We decided to target it and used plain-forge to install the universal skills. The Solvimon bounty was also on our radar, for the idea most likely to become a real business.

After the talks the real clock started. We had the rest of Friday evening, all of Saturday, and Sunday morning until the 12pm submission deadline. The venue stayed open and food kept coming.

# The workflow

The rule was stricter than it first sounded. Every line of code, every asset import, every small tweak had to come from prompting an AI. We could review, guide, and reject, but writing or editing by hand was off limits.

We started by trying to render the specs with Codeplain. It worked for a while, but we ran into friction quickly. We only had one module, so every change meant re-rendering the entire application. The --from option existed, but adjusting specs from earlier stages made it impractical.

At some point we switched to Grok Build. There was a nice offer with three days of super Grok for free, and we leaned on it heavily. Over the weekend we spent around 700 million tokens.

Explaining what we wanted took time. The AI would produce something almost right, then we would prompt again for the missing piece. Over the first night the loop got faster. We learned how to give better context, how to ask for smaller changes, and when to start fresh instead of patching a bad generation. The weekend reinforced something I already believed: precise prompting matters. Clear requirements, constraints, and context consistently led to better results and fewer iterations.

We worked in long stretches with almost no breaks. Sleep happened in short shifts on couches. By Saturday evening the game already had waves, enemies, a basic player, and the start of a supply drop system.

One thing I had been worried about was coordination. AI tools often edit many files at once, which I expected would quickly lead to merge conflicts. In practice conflicts happened occasionally, but they were rare. We communicated well and divided the work clearly, so most changes stayed out of each other’s way. When a conflict did occur we used Grok to resolve it, since manually editing code was not allowed. We stayed on master the entire time. Every commit was usually a complete feature or a meaningful increment.

By the end of the weekend the project contained roughly 26,000 lines of AI-generated GDScript. The AI sometimes fixed one problem while accidentally introducing another, which made reviewing outputs just as important as writing good prompts.

We will probably stick with superpowers as our main spec-driven development toolkit going forward, but experimenting with the **plain** approach during the hackathon was still worth trying.

# The result

By Sunday morning we had something that felt like a real game. We called it Voidlights. It was rough in places, but it had a clear loop, some tension, and enough systems working that people could play a full run and understand what it was.

We tested multiplayer by joining sessions ourselves. We checked whether players could connect, move around together, fight enemies, pick up upgrades from supply drops, and survive waves as a group. The testing was manual and limited to what we could verify in the remaining time.

# After the weekend

What stayed with us was how much four people managed to put together in 48 hours under that constraint. By Sunday morning we had a game that people could actually play, and that was enough to convince us that the project was worth continuing.

We decided to keep working on Voidlights. The goal now is to turn a hackathon prototype into something we would feel comfortable putting in front of a larger audience. That means improving the gameplay, expanding the content, and building a stronger foundation than was possible during a single weekend.

One thing we learned quickly was that the speed came with tradeoffs. To deliver as much as possible within 48 hours, we had to lean heavily into vibe coding and keep moving forward. The result was a working game, but not necessarily clean code. We ran into performance issues, duplicated logic, overly complex functions, and other shortcuts that naturally accumulate when the priority is shipping rather than refinement. We started addressing some of the performance problems during the hackathon itself, but there is still plenty of cleanup work ahead. Before we can ship it with confidence, we want to review every line, take ownership of the codebase, fully understand how the systems work, and polish the parts that were generated too quickly.

# What stayed with me

I was genuinely surprised by how far we got. The rule forced us to be clearer about what we wanted and to make decisions faster. It also exposed every gap in our thinking immediately, because the AI would happily do exactly what we asked for, even when it was a bad idea.

More than the game itself, the weekend showed what a small, focused team can ship when the usual excuses are removed. We left London tired and a bit wired, already talking about the next steps.

The rule did not remove engineering work, it changed where the work happened. Effort shifted into communication, specification, review, testing, and deciding when to accept or reject what the AI produced.

The surprising part was not that AI could generate code. The surprising part was how much progress a small team could make when implementation stopped being the primary bottleneck.

The game is still early, but it exists because of those 48 hours, that constraint, and a team willing to find out what AI-assisted development actually looks like in practice.