Claude Code Vibes

How a Kid's Chore App Became a Week-Long Vibe Coding Adventure

We have been trying to push more of the family responsibilities onto our twin nine-year-olds. To structure this, my wife built a spreadsheet with the tasks for each kiddo to complete at various points in the day.

I decided to use Claude to turn the spreadsheet into an app.

My first thought was that this should be a simple html page with some vanilla javascript that doesn't connect to the internet. I'd just need to get the file onto the kids iPads and we'd be off.

My first step was to prompt Claude with: Help me create a proof of concept chore tracker app for my kids. The results were pretty good. Good enough in fact to inspire some additional prompting.

Please turn this spreadsheet into an "app" that my kids can use on their iPads. It should be a single html file. They should be able to go day by day and check off their tasks. The directions at the top should be clear.

What questions do you have?

With minimal effort, Claude can produce a nice looking task tracker.

Chore tracker one, complete.

But wants have a way of being endless. What if the page refreshes? Both kids need different themed user interfaces. We need a review mode that can act as a conversation starter at the end of the week.

On to chore tracker number two.

The next move was to dive into Claude Code. The latest best practice with coding agents is to use a series of prompts to guide it through an actual software development process so as to prevent the spaghetti code that it will otherwise produce.

I had the AI create a product requirements doc. Next I had it break the product requirements doc down into a series of tasks. Then I had it work through each task one at a time. I used the auto accept mode and deliberately avoided looking at the code because I am not a peasant. I could kick off a task, hang out with the family, then meander into my office and kick off the next one.

I've already made many mistakes at this point in the story, but there are two significant ones worth calling out. First, I did not use version control, which would have allowed me to easily revert any wrong turns. Second, in the product requirements doc, I prescribed all the code be in one html file.

The second mistake meant that the length of the file quickly exceeded the amount of code Claude will slurp up in a given pass. I'm not sure exactly what's happening, because obviously the entire file fits into Claude's context window. I think under the hood Claude Code has some sort of chunking strategy when reading code. I find in longer files it is far more likely to miss a closing curly brace or produce some other basic syntactic error.

As it worked through tasks, the code got longer and more complicated. As it got more convoluted, changes that should have been simple started breaking other pieces of functionality. This kind of whack-a-mole is a common failure mode with the current state of vibe coding.

I finally decided to (gasp) look at the code. What I found I am almost afraid to share. Please sit down. It had inlined what I think was minified CSS. I deliberately wanted everything stored client side because there was no server. To accomplish this, Claude had landed on a system that combined hard coded html ids, JSON, and who knows what else. How did it not understand to just store some JSON in the browser's local storage? Was "make it simple" not a clear enough prompt?

This brings us back to the first mistake - no version control. After a few hours of fixing one thing only to break another with no way to untangle, I realized it was time for chore tracker number three.

I put on my "I'm a professional software engineer" hat, and restarted the process. This time I first used Claude Code to brainstorm the chore tracker with me. It generated a brainstorm document which we then converted into a product requirements doc. I then took the product requirements doc and had multiple rounds of conversation with Claude Code and Claude chat to come up with a database schema.

I mean conversation quite literally. I decided to try out Superwhisper based on all the buzz I've seen. It's pretty great. Essentially, I set up a hot key on my computer to start a dictation.

I say something to Claude Code. I hit the hot key to stop the dictation. Then the words I just dictated are pasted into wherever my cursor is. There are more features, but I can definitely talk faster than I can type. And talking to my computer? Are you kidding? That's freaking awesome. I liked it enough to pay for a one year subscription after my free tier ran out. It's a great product.

How do you even come up with a database schema with Claude? Well, I shared the product requirements doc and the brainstorm doc. I told it to come up with three different database designs. I told it to list the pros and cons of each. I asked it to generate mermaid diagrams of each design so I could read it quickly.

I used a simple heuristic to evaluate the designs. If I immediately understood the design, that was good. If I had to squint, pause, think, read Claude's explanation, or ask follow up questions, that was bad.

To summarize, we are up to build attempt three of a very simple to-do list tracker and at this point I've spent an entire day just brainstorming, getting the product requirements doc right, and generating multiple database designs until I found one that I intuitively liked.

Next, I ran rails new. Why Rails? Well, it happens to be the web framework I know best. Why not Next or Vite or whatever? I actually think, and others that I respect a lot on this subject agree, that LLM's benefit from the opinionated, convention-first philosophy of Rails. Running rails new sets up directories and files that become like a coloring book for the LLM rather than a sketch book of blank pages.

Then I had to remember how to deploy a new Rails app, which is why I wrote Rails Deployments for Mere Mortals. I walked through my own god damn tutorial and had things up and running in a few hours.

Only once the scaffolding was set up did I go back to Claude Code. I shared the product requirements doc and created an engineering plan. I reviewed the engineering plan very carefully. I deleted parts that were out of scope.

I then prompted Claude Code to turn the engineering plan into a list of tasks. And then finally I had it process the tasks. After each task, I had it create a pull request on Github. I then reviewed the pull requests, just like I do at work, except I was less polite. I would list comments about my code style and organizational preferences. I'd then ask Claude Code to fetch my comments and update the pull request.

Then I'd ask Claude Code to update the CLAUDE.md file, which is where project level instructions are stored. I'd prompt, something like, "add anything that would have gotten us here more quickly with fewer prompts."

Rails, Git, a rigorous software development process, and Claude Code's capabilities helped me produce a product that meets my quality bar. Each kid has a personalized theme that I designed with Claude.

If you are interested in digging deeper into how I use Claude Code, you can checkout my repository of Claude Code Commands. I also recently listened to a podcast about teaching vibe coding to novices, which has me intrigued. How would I run such a learning session? Would you take it? Would you tell your friends about it?

Reach out if you have questions or want to share protips that I'm missing.