Yes, I vibe coded a game, but it was actually quite stressful

I recently released Mac Packwala and the Curse of the Stale Cache, a point-and-click game about the Drupal AI ecosystem. I vibe coded it, for real this time.

I don't mean AI-assisted coding. That is my normal day: four or five sessions open, each of them steering about 20 agents. Many of those agents are just researching topics for me and producing podcasts that I listen to when I go out walking. Very few of them produce code. When they do, they build what I intended: I write the specs, I decide how it should work and I review what comes back. That end product has to be more exact, so sometimes I need to intervene and write code myself. The decisions are mine. And when I build something, I make sure the code being written is something I can sign as my own, with full disclosure.

The game was a test: something I normally don't code, and that would take me months, if not half a year, to finish by hand. So I went out of my way to vibe it: a workflow where the AI takes the front seat. I wrote the story on a high level, but the AI filled it in and made every graphical decision. It made every technical decision, as long as that decision didn't hurt my hosting costs or my token usage. Those few I kept for myself, like smaller audio files, and I picked the music and the voices. Apart from that, I gave it a list of the Drupal modules it was allowed to talk about. It read them and made a game out of them.

That is close to what Andrej Karpathy meant when he named it in February 2025: you "fully give in to the vibes" and "forget that the code even exists".

I tried this in the middle of 2025, and it was hilariously bad. The result has improved by an enormous factor since then, but it is still not there.

Forgetting that the code exists sounds relaxing. It wasn't. When you don't know the code, you can't fix anything yourself. All you can do is describe what is wrong, roll another prompt and hope that the next answer is better than the last one.

It is obvious that the more the code base grows, the more it differs from the initial spec. And the poorer the initial spec, and the sloppier and vaguer the prompts, the worse the whole code base becomes.

On the other hand, it is also obvious that it improves things where I am weak. The most positive part of the whole experience was sitting and testing jokes against the model. I am neither a native speaker nor a natural comedian, so it helped a lot.

It is probably also true that in terms of story, comedy, graphics and more or less everything else, this looks like pure slop to anyone working in the field.

Another problem, one I didn't see until I got some distance and moved out of the vibe coding bubble, was the question: does anyone actually need this? You get so close to seeing something finished that you focus on finishing it, instead of asking yourself the basic question of whether it is needed. An article on HackerNoon makes the same point: "The bottleneck was never the code."

When writing code and producing things become cheap, the distance from idea to prototype gets very short. One could argue about whether maintaining is still cheap: in many cases, AI has made it harder to maintain open source projects, at least. But when you can spin up prototypes that easily, you never stop to think about whether this actually makes sense.

You can see the same pull on r/vibecoding, in a thread called "vibe coding is ruining my life lol".

And can you truly say that you created it? There is the whole question of being a creator versus being a patron or a project manager, and maybe I am one of the latter. The high-level ideas are mine, but the execution isn't really. IBM researchers who interviewed developers using tools like Claude Code heard the same: "many are finding that their work is shifting from implementation to management." In AI art, this is an even bigger question.

In The Atlantic, Ian Bogost, who has a programming background and spent a year making programs with AI, argues that programmers feel this less than writers and artists do: with code, "the outcome and the process improve all at once", and "it just feels like programming." Even so, looking at a small weather display he built that way, he writes that the feeling "isn't quite pride, because I can hardly take sole credit for the accomplishment."

And since the project is ephemeral, is it important enough to continue working on, or to maintain?

If you don't architect your app yourself, the foundation it is built on might already be problematic, and any update can crack that frail foundation.

Even on this smaller app, it got hard to make fixes that worked at a later stage, because I didn't know exactly what to ask: I didn't know the foundation it was built on. The IBM researchers point to a study that found the same: "using agents leaves developers 'cognitively distant' from the code they must review." I don't think this would work as a day job, since I wouldn't know before starting a prompt whether the result would actually be useful.

Normally I'm actually very good at working 9 to 10 hours a day and dropping it at the end of the day. I might leave some agents running when I leave my desk, researching something or refactoring something for me to check the next day. But I have never been one to look at my agents before I go to sleep, or as the first thing in the morning. Agents are tools like any other tool. Maybe the most groundbreaking coding tool there is, but still a tool that I control.

With vibe coding I lost that control, and weirdly enough, I got a lot more invested. When you get a superpower that lets you create something you shouldn't be capable of, it excites you in a different way than a tool that writes out code you had already researched, specced well and prompted for. The vibe becomes a little bit of magic in a box, and you just want one more draw to make it a little bit better.

I was playing the game, both the actual game and the game of vibes, when I realized that I had been sitting at it until 11 at night on a Saturday. If I did this as my actual day job, I'm sure I would burn out within a month.

The same IBM researchers call it vibing fatigue: "Developers and researchers told us they're frustrated, exhausted, overloaded and facing uncertainty." Steering, interpreting and checking the output never stops, and people felt pressure to keep pace with the agent and guilt when they stepped away. Almost all of them still thought the speed was worth it, but their advice is something I recognize: "we have to learn to walk away from it."

Several people have written about this. The same HackerNoon article calls vibe coding an addiction: building feels so rewarding that it is easy to mistake the thrill of making things for real progress. Rachel Thomas at fast.ai compares it to gambling in Breaking the Spell of Vibe Coding. She calls it "dark flow", a term from gambling addiction research: it feels like focus, but the feedback is misleading and the sense of control is false.

While I didn't feel in control, people with less development experience actually feel that vibe coding makes software more accessible. In a survey of 162 vibe coders by Fawzy, Tahir and Blincoe (May 2026), non-developers were the group most motivated by "accessibility and empowerment": vibe coding lets them build software they could not have built otherwise. The same survey shows the other side. The less experienced the participants, the more they relied on reprompting instead of debugging, and non-developers were the only group that reported never checking the AI-generated code before using it.

We actually allow vibe coding on the AI module. You can contribute something you don't understand, as long as you disclose it. That might sound strange after everything above, but there is a reason for it: new ideas.

If you want to create a new component, a new workflow or anything else that could change how the AI module works, it would be foolish of us not to let you show it as realistically as possible. Not every idea can be explained in text or images. A vibe coded prototype can show the whole process, working, from start to finish. And for many features, we developers are not the best judges of whether they are needed, only of how they should be implemented. Vibe coding lets the domain experts implement their own ideas. We will of course not consider vibe coded code for merging. It shows the idea; it doesn't ship it.

We may be creating a generation of people who have a much greater ability to produce sophisticated work, but a weaker relationship between what they accomplish and what they personally understand.

At the same time, this might be an old person yelling at the cloud. The same sentence could have been written about the compiler, the high-level language, the IDE, Stack Overflow, the package manager and, yes, a CMS like Drupal. If the agents become stable enough to produce anything, do you actually need to know the process? I haven't needed to know how to read a map since I was a teenager. The GPS just takes care of it, and looking back, that is incredible. The GPS had problems in the beginning as well: you almost had to assist it, and on the routes you drove regularly, you usually knew better ones. That hasn't been true for some time.

My father always complains that we "younger" kids can't understand the satisfaction of working a whole summer just to afford a bicycle. This might be similar: me trying to force a nostalgic idea of how things should be earned. It might be hypocritical as well that I don't even wonder about the same thing when I use AI to help me write these blog posts, create music or research topics.

The fact that I could create a full point-and-click game just by prompting is a fantastic invention in itself. If Ron Gilbert had had these tools at hand, we might have gotten even more legendary games from his mind.