Learnings from 40 hours and $106 of vibe coding
Developing a game with minimal technical expertise.
In high school, I was obsessed with playing point-and-click escape-room Flash games like Cube Escape, Submachine, and Alice is Dead. I wanted to create a game of my own, but I lacked–amongst other things–the technical capabilities, artistic vision, and will. Also, Adobe deprecated Adobe Flash in 2017, so that was that.
Until now! A decade and a half later, a proliferation of vibe coding tools promises us the sun and stars, and–somewhere in that distance–the ability for an individual to create an indie game without investing years of their life. So some $100 and 40 hours later, I have a working prototype of a hand-drawn point-and-click and numerous learnings. You can playtest the first level of my game here (desktop-only) or read about my experience below.
I. CHOOSING AN AI TOOL
To start, I created a set of high-level principles for my project:
HTML, CSS, and Javascript (Phaser framework) only.
Modular approach to building.
Extensible configuration via json files, which allows me, a non-technical creator, to easily build gameplay without digging into code.
Despite vibe coding, I wanted to draw my own art, so all assets are to be provided by me.
As a new, non-technical vibe coder, I explicitly wanted to keep my scope simple. That meant descoping account management, monetization, server storage (everything will run client-side), and complex gameplay: full-fledged 3D game engines, game physics, multiplayer, etc. There’s a lot that I ruled out here, which was easy to do because I was looking to build a point-and-click anyways.
Having a general idea of what I needed to support meant I could make my decision quickly. I consulted only three sources–
Vibe Coding: My Deep Dive into Tools, Techniques & Personal Takeaways by Alison Brunk,
A Comprehensive Guide to Vibe Coding Tools by Madhukar Kumar, and
ChatGPT
–before I decided on a lightweight vibe coding tool that focused on web development and, importantly, is browser-based as I was traveling and only had my iPad with me. This led me to Lovable and V0 Vercel.
II. THE LIMITATIONS OF 5 CREDITS
On a free plan, Lovable and Vercel both have credit systems that refresh on a daily/monthly basis. So I tried, as much as possible, to log on to both platforms during vacation travel.
To say I did not get very far on daily credits is an understatement. If you have any delusions about vibe coding on free credits, let me burst your bubble now: you need to pay to vibe code.
Conversational chatbots like ChatGPT/DeepSeek/Perplexity conditioned me to expect large returns for free, and that was naive. I ran head-into-wall against two assumptions: (1) that vibe coding will do it all for me, and (2) that vibe coding is cheap. Neither of these statements are wholly false, but they obfuscate a whole bunch of caveats.
I decided that if I was going to pay, I should at least have an IDE instead of hacking away in a browser tab–so it was back to the drawing board. While in an Uber to a wedding with my friend Raunak, he recommended Replit, describing how he used it to build a move optimizer for a Tetris game (I lightly teased him for cheating). That was enough of a sales pitch; I took his recommendation and bought a Replit subscription when I returned home.
I still marvel at the power of community-based recommendations in decision-making. In the online age, we often think that aggregate feedback (e.g. Google reviews, search rankings) and targeted content (e.g. ads, influencer videos) are the most impactful forms of marketing, but nothing beats word of mouth from a trusted party. It might be idiosyncratic, but it might also be an indicator of the enduring strength of personal recommendations.
III. WHAT WORKED, AND WHAT DIDN’T
Spec docs: ❌ Didn’t work
Online guides recommended I start with a spec doc, so I created a short one and fed it to my AI tools. Being a PM by trade, I think my 1-page spec was reasonable. However, starting with a spec doc crashed and burned for the following chain of reasons:
It is impossible for a person (or a team, or an org) to think of all desired behaviour and possible interactions upfront.
Therefore, assumptions must be made when starting with a single spec doc. Way too many assumptions.
AI aims to please and will prioritize completing the request over other possible paths like pausing, asking clarifying questions, choosing to not complete part of the request, picking and choosing which assumptions to make, etc.
Thus AI will make assumptions required to complete the task.
When more than a handful of assumptions are made, logic breaks.
That leaves you, the human, with a mess of a result. It is really difficult to untangle after the fact which functionalities were desired, which were assumptions, and which assumption(s) caused the issue(s).
Spec docs are necessary for thinking through the overall architecture–and I found it immensely useful to use ChatGPT and Claude to flesh out design–but handing off the doc to kickstart vibe coding is not a good idea. You wouldn’t work in a rigid waterfall process with an engineering team, so why do it with your AI tools? Instead of feeding the Agent the entire project, figure out your architecture and start with building a single central piece.
Ideation jamming: ✅ Worked
A few days in, I found that while Replit’s default Agent mode was Build, it also offered a Plan mode for non-coding ideation as well as a more reasonably-priced, 5-cents-per-request Claude 4.5 agent called Assistant.
It’s much better to spend a few dimes going back and forth on architecture with a low-cost agent than to immediately commit to a direction with a high-cost agent. I ask Replit’s Plan or Assistant to–
“Ask clarifying questions”
“Tell me what you need to know that you’re currently missing”
“Tell me if there’s a more modular or elegant way to solve this problem”
“Don’t code; just walk me through the logic”
–and it often returns with thoughtful points that I address one-by-one. This is the closest I got to feeling like I’m working with a flesh-and-bone collaborator.
Proactive problem solving: ❌ Didn’t work
At this point, vibe coding tools are still directive-based: they’re great at solving targeted problems, and are also surprisingly useful in offering creative alternatives and considerations, but they don’t discover unrelated problems yet.
About halfway into development, I noticed that my images sometimes looked blurry. During numerous back-and-forths, the AI asked me: “How do you know it’s blurry?” Because I can see with my own two eyeballs, Agent.
AI doesn’t find problems you don’t tell it about. It didn’t know that my game was blurry before I said it was, and philosophically it didn’t realize that blurriness is a problem. That’s why it’s good to pause and ask AI to identify technical problems you may not have considered–e.g. “Tell me about any issues I currently have with scalability and loading time”–so that you can help it determine what’s an issue.
(The problem, by the way, was device pixel ratios. I drew in 2x size because I thought it might be good practice, but for retina displays my canvas was being rendered in 1x size and then being re-blown-up to 2 dpr despite me already drawing in 2x. Because I couldn’t wrap my head around the difference between physical pixels and CSS pixels, I floundered around frustratingly before I even figured out what the problem was).
Guided debugging: ✅ Worked
I watched video tutorials of vibe coders debugging by typing in chat: “X is broken. pls fix.” There’s no way that actually works, I thought.
Surprisingly, it works pretty well. So long as you can identify what’s broken, communicate what you want the fix to be, and contain your changes, AI does a tremendous job at fixing the issue.
But for more complex issues, Agent got stuck in a loop of generating fixes that not only didn’t solve the problem, but occasionally introduced new bugs. This happens not because it can’t fix the problem, but because it can’t efficiently diagnose the issue.
Instead of asking Agent to solve the problem by itself, I asked it to add console logs through the code logic I was trying to debug, and then I returned with the results and my hypotheses. Short of actually writing code myself, this was the best debugging process for getting to the root of complicated problems. You should fix problems alongside your Agent; that, or be prepared to spend a disproportionate amount of your money on debugging.
Really straightforward asks that I thought AI could for sure handle: ❌ Didn’t work
As a result of the above insight, I was generous in asking Assistant to add console logs whenever I was debugging. 9 days into vibe coding, my console looked like a filler chapter from Game of Thrones: a lot of information, none of which I cared about.
So before I got farther, I asked Replit to find and remove all console logs in the code. 11 minutes and $3.93 later (my highest single-message action yet), Replit had removed all the console logs. It had also completely broken the game. I asked Agent to fix.
Another fruitless 10 minutes and $2.74 later, I decided this was a task for human hands. I ended up restoring my last working commit, ctrl+f’ing all instances of “console.” and manually deleting relevant lines (if you’re a real programmer and know of a better way to find and replace, now would be a great time to let me know).
AI was paradoxically wondrous at ideation jamming and horrendous at well-defined, automatable tasks. Go figure.
IV. ALL THE MARKETING IS LYING… KINDA
I recently started getting Base44 ads on Youtube:
Eager vibe coding companies flaunt variations of the same tagline: “Bring your ideas to life just by thinking about it”! “Turn any idea into a beautiful, working app in seconds”! Are they catchy marketing taglines? Sure. Do they also set up their paying users for failure by promising Heaven and failing to deliver even Cosplay Jesus? Absolutely.
Vibe coding slogans are at best deceptive, and at worst amoral and fraudulent. Mismatched expectations lead to frustration and outrageously inefficient usage, like this Replit user who spent $350 in a single day, or this Lovable user who spent 400 credits ($100) in an hour. Vibe coding companies seem hellbent on Simba-holding this mythology of “no coding necessary”, but that’s false. I lived predominantly in json files, but I read more code than I expected to and rejected a fair number of diffs just by doing a cursory review (the problem largely lay with me–usually, it was because I didn’t communicate well enough or didn’t think through a use case). Trying to vibe code without basic coding comprehension is like trying to guide your pre-algebra tween when you flunked second grade maths.
And yet, there are examples out there of incredible projects built through vibe coding. Or games like fly.pieter.com that are reportedly earning $50k in revenue a month. Or even niche projects that have just a few MAU but are truly revenue-generating. The effortless veneer around vibe coding caused me to ponder the deeply introspective question: “Am I too dumb to vibe code?”
Two things can be true: that vibe coding is incredibly powerful, and that it does not remove the effort of creation. More reasonable guides show seasoned vibe coders sharing knowledge from hundreds, if not thousands, of hours and dozens of projects. The “I have absolutely zero experience and I vibe coded a million-dollar idea” pipe dream is borne afloat on marketing dollars, to be recouped downstream from credit whales who fall for the scam. The reality is, as one of the video guides said, “somewhere in between”–that vibe coding can truly produce a good product, but only on the basis of hard work and driven learning.
V. VIBE CODING IS THE FUTURE
$106 is the cost of:
4-5 lunches in San Francisco,
13 coffees/bobas,
1 nosebleed Taylor Swift Eras tour concert ticket, or ~1/10th of a really good floor ticket
1/7th of the cost of my vet bill the time my budgie, Snowy, vomited on my keyboard and I took him to emergency care
I’m not advocating for skipping meals, to be clear–I’m making a point that the cost of vibe coding is very reasonable when denominated in other expenses. I believe that this new accessibility in digital creation will cause an explosion of creativity in the same way that smartphones created an amateur photographer out of everybody.
But having vibe coded, I now know that it’s all overcooked pasta behind the scenes. That’s not a big deal when I’m making a game, but it’s absolutely a big deal when it comes to privacy and security.
I’m not sure I’d trust non-technical vibe coders to create enterprise-grade software, and I wouldn’t hand financial or medical data to a vibe-coded app. However, we’re definitely going to see creative consumer apps and one-man initiatives explode now that non-technical creators have a feasible way of building apps for highly niche areas. This, in my opinion, is a deeply positive development.
I have a ton of improvements to my game I’m excited to add, including adding audio, load time management through using more spritesheets and texture atlases, building the next level, etc. But for now, I’m taking a pause on development to focus on my next passion project: finding a job.
Thank you’s:
Many thanks to my alpha playtesters Annie, Svitlana, Kelsey, and Amy, as well as my beta playtesters David, Annora, Kyara, and Jon. Thank you David for beta reading this article.
So fun trying ur game!!
the game was so fun and creative! thanks for letting me play it and loved hearing about your process building it :)