By skyforbes 
Featured
Code generation with LLMs holds a lot of potential and promise. In this article, I share my experience of Vibe Coding three daily puzzle games, what worked, what didn’t, and what to keep in mind if you plan to Vibe Code your next project.
I came across Lenny’s post on Vibe Coding, where he asked his followers to share their own projects. It was inspiring to see the response he received and the different kinds of projects that people are building.
You can also check out this post, where Lenny summarized the responses and shared the real-life examples of these projects. It was interesting to see how the technology that’s still nascent has gained such wide adoption and shows the real value LLMs bring to code generation.
Inspired by the article, I decided to share my own ‘Vibe Coding’ experience of building and launching an application with the help of ChatGPT. I wanted to see how far LLMs could assist a Product Manager like me, with minimal development experience, in taking something from zero to one. In this article, I talk about my goals for the project, what I built, and the key learnings along the way.
LLMs for Code Generation:
The term “Vibe Coding” has been trending this year, popularized by Andrej Karpathy. The idea is simple: using Large Language Models (LLMs) to generate code, where the developer primarily guides the process through prompts rather than writing all the code manually.
Code generation with LLMs holds a lot of potential as it can empower anyone to become a developer. However, unlike text or image generation, code generation with LLMs has a unique scaling challenge. You can get quite far by describing what you want to an LLM, but the real difficulty arises as the code base grows or when multiple components need to work together.
The main challenge lies in validating that LLM-generated code is reliable and maintainable. With text or images, the feedback is almost immediate as the users can easily judge whether the output is good or not. Code, on the other hand, needs to stand the test of time: it needs to run correctly, adapt to new requirements and remain understandable for future developers.
My Goals for the experiment:
As a product manager, I wanted to see how far I can go with the Vibe Coding and whether I could create production-ready software, not just a prototype or a dashboard. So here are my goals:
- Define the product clearly
Articulate the purpose, features, and experience I wanted to create so the LLM could execute based on a precise vision.
2. Build and deploy a production-ready application
Vibe code the application and make it live for real users, managing the practical realities of deployment, performance, and reliability.
3. Gather feedback and iterate
Collect feedback from real users, fix bugs, and enhance the application based on real-world experience with the help of LLMs.
The Outcome:
I have decided to build a puzzle game for this experiment since I’m a fan of the format and had a few ideas I thought would make interesting daily puzzles. Puzzle games also make it easy to find users, as they have a broad appeal and satisfy the need for challenge and fun. I also know a few people who enjoy solving puzzles, which makes it easy to gather early feedback and drive adoption.
I created three puzzles that share some features with popular puzzle games but have unique mechanics of their own. The rules are distinct enough to test whether LLMs can build something according to the specifications.
You can try the games to get a sense of the outcome:
Vertiqle
Submit a guess in any column and receive feedback to find the secret word within 6 attempts.
Vertiqle+
A more challenging version of Vertiqle where you must guess both the secret word and the plus word within 7 attempts.
Hexqle
A six-letter puzzle that provides feedback based on whether the letters are on the same side or the other side in the word.
The Result:
If you have tried playing the games, you can see that I succeeded in my goal of taking the idea from 0 to 1. The games include some complex features like resetting the daily word overnight, switching between game modes and computing daily play statistics. I was able to instruct the LLM to implement these features as envisioned.
The games currently have around 20 DAU (Daily Active Users) who are playing regularly and a total of 1400 unique visitors since launch. Although modest, these numbers show that the games have reached real users and generated meaningful early feedback.
Since launch, I’ve also been able to address user reported bugs, from color issues in dark mode to the target word changing mid game, by identifying the problematic parts of the code and fixing them with the help of the LLM.
At least at the scale of my puzzle games, I can conclude that the process of building, launching, and iterating on real user feedback proved that Vibe Coding can go beyond prototypes and support the full product development cycle. So, let’s look at the key learnings and considerations from my experience.
Key Learnings:
Yes, you can go from 0 to 1
“For a long time, technical people in the startup industry have made fun of ‘the idea guys’… people who had an idea and were looking for a team to build it. It now looks to me like they are about to have their day in the sun.” — Sam Altman
Sam Altman’s post about the “idea guy” feels more relevant than ever, as LLMs are proving to be reliable coding partners. I’ve always been that idea guy who struggled to take ideas to the next level, but now LLMs have made the building part far more accessible to almost anyone.
While I do not have professional coding experience, my background as a product manager gave me familiarity with the software development process. This foundation helped me communicate effectively with LLMs and understand the logic behind the code they generated. That said, these skills can be learnt by anyone who is serious about using LLMs as their co-founder to turn their ideas into working products.
There’s still a learning curve
Vibe Coding made it possible for me to launch the games, but it was not a weekend project or something built with a few prompts. I spent around one to two hours a day on the project, and it took me roughly two months to launch Vertiqle.
It takes multiple iterations and a fair amount of trial and error to get usable code. While best practices are still evolving, you start to figure out what works after a few iterations. There is definitely a learning curve, and it’s not as straightforward as text or image generation.
The best part of investing the time is that it translates into productivity gains. It is reflected in my subsequent games as it took roughly one month for Hexqle and around 3 weeks for Vertiqle+. I only used my ChatGPT Plus subscription for coding, and I believe the experience would be broadly similar with other tools as well.
If I had to learn to code first and then build the game, it would have taken me at least a year. So, despite the learning curve, the timeline with Vibe Coding is still remarkable.
You have to wear multiple hats
The three key skills for Vibe coding are writing clear and detailed specifications, testing the generated code and having the big picture view to structure and organize the development lifecycle. For each skill you have to play a different role while iterating with the LLM.
You: Product Manager | LLM: Developer
This is the core loop where you act as the Product Manager, specifying the features, while the LLM acts as the developer turning them into code. To get better at this, you need to understand the right level of detail to include in your prompts and how to break down requirements into manageable parts. After a few iterations, I even started writing my features in Trello as prompts that I am going to describe to the LLM.
You: Tester | LLM: Developer
The second loop is where you shift into the role of a tester, validating whether the output matches the specification. This is an important loop to make sure that your specification is understood by the LLM and actually you specified what you envisioned.
You: Product Manager | LLM: Architect
This loop is less discussed but just as important to understand the big picture and help you structure your project. asking about the best languages, frameworks, and deployment strategies for your project. For example, I decided to write my back-end in Python and host on Render and my front-end in Svelte and host in Netlify. This loop helps you break down the project into well-defined components and ultimately build a deployable application.
This shows that Vibe Coding demands patience, structure, and a way of thinking that might not come naturally to everyone. Let’s look at the trade-offs and why its appeal might not be universal.
Why Vibe Coding Might Not Be for Everyone:
During the process of Vibe Coding the 3 games for product pickle, I realized that it might not be for everyone. While it empowered me and made it possible to launch my ideas into games, here are a few reasons why I think some people need to consider:
You’ll get better at vibe coding — not coding
It is important to understand this distinction. Prompting an AI to build features, debug, or restructure code is a different skill altogether, and it doesn’t directly translate to traditional coding ability. You might find it difficult to judge the complexity of tasks since all prompts can look similar in form, even if they vary greatly in effort.
If your goal is to become a developer, relying purely on Vibe Coding will not help you build the foundational skills required for software development.
The hidden cost: your time
Because every task or bug fix appears similar, it can be hard to prioritize effectively. You might spend hours — or even days — on something that would take an experienced developer just a few minutes. I spent several days trying to make the game’s favicon display correctly in the browser and eventually gave up. So, even if Vibe Coding saves money, the opportunity cost of your time can be significant.
Mistakes can become expensive
When you rely heavily on AI for architectural or design decisions, mistakes can compound over time. Early choices can become difficult to reverse, sometimes requiring a complete rebuild. I experienced this firsthand when I realized that my initial project setup used the Svelte framework, but I needed SvelteKit to support multiple pages. That decision forced me to start almost from scratch. An experienced developer could have avoided such pitfalls, which can make AI-driven development more costly in the long run.
Conclusion
My experience with Vibe Coding showed me the possibilities and the considerations of this technology. While I wanted to test whether it is truly possible to go from 0 to 1, I chose a project (web-based puzzle games) that is relatively simple compared to most digital applications. Even so, demonstrated what can be achieved by a non-developer like me.
GenAI is still in its early stages, and future tools will continue to lower the barrier for non-developers. Vibe Coding offers powerful leverage, but its value depends on who you are:
- Generalists can extend their capabilities.
- Specialists can amplify their output.
- And for everyone, there is a learning curve that demands time and effort before the productivity gains start to show.
My verdict: you can ship real products with code generated by LLMs. But remember, AI does not have the skin in the game. The ownership, accountability, and vision are still yours.
This article was originally published on Product Pickle on November 2, 2025. Subscribe to get the latest updates delivered straight to your inbox.