Experiment: Vibe-code an app without writing a line of code. Here is what i learned.

I built and shipped a full web app without writing a single line of code. Here's what I learned about what works, what breaks, and where AI coding is headed.

My journey with AI coding so far

I have been using AI for coding for 2+ years. First, I copy-pasted from ChatGPT & Claude, then I used co-pilot in JetBrains IDE. Then I took the plunge, ditched JetBrains and installed Cursor - and have not looked back since (that was around Q1 2025).

Cursor has helped me write better code, write faster and explain concepts to me without having to look at StackOverflow and other online resources. For debugging, it is a godsend.

Claude Code has been a strange animal for me. Why command line? You cannot really see the diff. I like to check each line of code, especially for commercial enterprise software. I tried Lovable once, but it felt really off, especially for someone who likes to code.

Since around mid-December, every coder-friend, every podcast, every post talks about how Claude Code has improved so much, that we are living another "ChatGPT moment" - on the same order of importance and change as the initial release of ChatGPT to the public.

So I took the plunge again, this time on a little personal itch I wanted to scratch for a long time. The goal of the experiment was to do a complete web-app without writing one line of code.

The itch I wanted to scratch

Goodreads is a social network for book lovers. It got bought by Amazon in 2013 and has sadly almost felt abandoned since then. The community is very active, but search is broken and recommendations are generally lousy.

It has been one of my first tries with ChatGPT to upload my Goodreads export as a CSV. But results were very disappointing. It recommended to me mostly books I had already read and were in the CSV. Many iterated prompts later, this was still the case.

So the goal of my mini-project was to build a book recommender which would:

• Recommend books according to my taste, excluding books I have already read
• Recommend books to my friends from my "read" list depending on their mood
• Accept a Goodreads CSV upload

Approach and architecture

My first idea was to use RAG (Retrieval-augmented Generation) and embeddings learned recently in a scrimba course and book blurbs from OpenLibrary.org. But blurbs alone don't capture what makes a book resonate.

Then it clicked: Google scanned millions of books - and that content almost certainly ended up in Gemini's training data. Gemini likely already "knows" most books from the inside. Combine that with a context window of 1 million tokens (~1,500 pages), and you don't need embeddings and RAG at all - just send the whole Goodreads CSV and let Gemini's built-in knowledge do the work.

Experience with Claude Code

I started up Claude Code in my console, gave it the specification, set the API key to my Gemini API and… 20 minutes later the app was up and working.

I was blown away. The next few days I spent in a kind of rush to ship new features: friends' libraries, automatic deletion, security features, improved prompt tone, and more.

The final result can be seen on www.bookybooks.com. I have written not a single line of code.

The crazy good

As a product-minded coder, it is as if you have a highly productive team of junior developers on hand. You have to specify your task well, they sometimes write ugly code, but in the end they arrive at your goal.

You lose all fear of implementing features. An MVP is just a prompt away. Example: "Make my app multilingual with French, English and German" → Claude just does it, including translations. 15 years ago this would have been a major undertaking with a lot of complaints from the team about whether it's really necessary.

You don't have to know coding to use it. I'm currently building a custom homeschooling app for my family in Android's Kotlin - a programming language I have never used. Having coded before helps, but it is by no means necessary.

Pitfalls

Claude did some surprisingly dumb stuff. And as I didn't verify every line of code as I would in a production build for clients, I didn't realize it immediately.

Defeating the purpose: It shortened reviews from the Goodreads export to a low number of max tokens to save money on API cost. And it only took 4- and 5-star reviews into account. I never asked it to save money - eschewing low-star reviews and cutting the others short kind of defeats the whole purpose of the app.

Overengineering: At one point I tried to have more natural-sounding texts by having people choose their pronoun. Instead of just writing the very few lines in different pronouns, Claude reinvented a whole system to replace possessives and subjects in all strings - which was complicated and did not work.

Underengineering: The CSV export from Goodreads was re-parsed on every chat request instead of being parsed once at library creation.

Laziness in planning: When implementation is just a prompt away, you stop thinking features through before building them. You skip the blank-page phase - the ideation, the sketching, the "does this actually make sense?" - and jump straight into building. The result: you discover conceptual errors late, and you miss the creative juice that comes from wrestling with a problem before touching code.

Loss of mental model: When you stop writing code yourself, you lose the mental model of your codebase. Every programmer normally carries a map in their head - where features live, how things connect, where the blind spots are. Without it, your prompts become increasingly generic and less adapted to the codebase. And here's the trap: the less you know your code, the worse your prompts get, the worse the output gets, the more you patch instead of refactor. What starts as incredible initial productivity can spiral into diminishing returns over time.

Are we at a ChatGPT moment?

Absolutely. Programming will be changed forever. Everyone can now code their own apps with enough time, without formal training.

The mentioned pitfalls won't persist for long. Remember how bad ChatGPT was in the beginning? The hallucinations? And how far it has come?

Thoughts

• Easier development means more software, not necessarily fewer programmers (see Jevons paradox).
• Developers who don't use AI to help code will be 3–6x slower than those who do.
• Senior competence is still necessary to verify code, but senior roles will be harder to fill and juniors will have fewer opportunities to learn the ropes the traditional way.
• The bottleneck in software is no longer execution, but creativity. Which I find to be a good thing in principle.
• The whole industry is becoming dependent on a few companies. Right now, the gap between Anthropic (Claude Code) and the runner-up is significant.
• Gemini was really a good choice to do book recommendations, but it absolutely sucks at other stuff. ChatGPT was best at generating the icons/images of the app. Claude was best at coding. It is important to choose the right model for the right task.
• Good prompting is everything: Iterating on the prompts for the book recommendations was what improved the user experience most - giving the recommender personality, producing smart recommendations and avoiding books already on my shelves. But hey - you can use Claude Code to improve prompts.

My recommended setup for (not-so-vibe)-coding

Use Cursor with Claude Code from the Cursor terminal. You get Claude Code's power for generating, plus Cursor's autocomplete and diff view to stay on top of what's changing.

Play around with sub-agents and custom skills in Claude Code. For example, I wrote a "simplify" skill that removes dead code and refactors smartly - a direct counter to the overengineering and underengineering patterns I described above. Think of skills as reusable instructions that keep Claude's worst habits in check.