Examining the Reality of Vibe Coding

TLDR: The Final React App

"Vibe coding" has become the hottest trend in the software development world now. I decided to test it on something where I have very limited experience: React-based frontend development. And I wanted to do it without touching code by hand.

Tool of choice: Claude Code (the VS Code plugin, not the terminal one).

Can this coding assistant actually build something functional in a domain where I am essentially a beginner? I have worked on backend systems, data pipelines, machine learning systems, etc. But React? I have basic experience with HTML+CSS+JS. That is it. Beyond that is uncharted territory.

The Target: A Spaced Repetition Flashcard App

I needed a project that was non-trivial but not massive. Something with enough complexity to test the vibe coding approach.

I settled on a frontend-only flashcard learning app with intelligent repetition. Users upload a set of multiple-choice questions, and the system shows these questions based on how well they know them. Questions live in different pools — Test, Learning, and Master. Answer correctly enough times, and a question moves up. Get it wrong, and it drops back down.

Higher pools mean lower frequency. If you have mastered something, you do not need to see it every day. But if you slip up, the system catches it and brings that question back into rotation. There is also a snooze mechanism. Once a card is shown, it takes a break. Higher-pool cards snooze longer because you have already proven you know them.

First Attempt: Just Jump In

I jumped in with typical developer enthusiasm. Opened Claude Code, described what I wanted in the full spirit of the vibe, and let it generate the initial project.

It worked! Okay, not so well. Actually, it was bad. And the longer I played with at it, the worse it appeared.

The app ran. Components rendered. The UI looked okay, but the actual logic was completely off. The pool system did not behave the way I expected. No way to know what was going on underneath. Some questions repeated too quickly. Got a few errors here and there.

I tried giving more feedback: "fix the pool logic with reduced snooze time," "increase probabilities for the test pool," etc. Claude Code would make changes, but it felt like it was not getting anywhere.

The problem was not Claude Code, but me. I had not given it a clear blueprint. I was expecting it to read my mind while I was still figuring out what I wanted.

Next: Stop Making Code Changes, Start Planning

Using Claude's regular chat interface, I began drafting a proper specification. Not a vague outline, but a detailed document covering:

• Every screen and what it should do
• Wireframes using PlantUML (because box-drawing characters were not cutting it)
• Question sampling algorithm at any given point
• The exact algorithm for promotion and demotion

This took time. I went through multiple iterations, getting Claude to ask clarifying questions, then refining the requirements based on my answers, making sure ambiguity was reduced. The final spec was about 300 lines long.

Then I gave that spec to Claude Code. It generated the entire project structure. It set up TypeScript (as requested in the spec), created organized components, and even generated a task list for the build.

Vibe coding works, but you need to know what you want, then communicate that well to the coding agent.

From Spec to Code

With a solid spec, development became methodical.

TypeScript was a lifesaver. Claude Code would run the compiler, catch type errors, and fix them automatically. This loop caught issues that would have been runtime bugs otherwise.

UI improvements happened iteratively. I would test a screen, note what felt wrong, list out the issues, and Claude Code would address them. Usually took two or three passes per screen. No confusion, no endless tweaking.

The algorithm was the tricky part. Spaced repetition is inherently slow to test. You cannot verify the snooze logic without actually waiting. Running through the flow manually took forever.

So I had Claude Code add a debug page showing the internal state of every question: which pool, last shown time, snooze status. Originally planned this for development only, but it turned out to be so useful that I kept it in production. Transparency helps.

I also tweaked the configuration to create a "fast mode" for testing: smaller pools, shorter snooze times, higher probabilities. This let me verify the entire logic in minutes instead of hours. But manual testing was still tedious.

Vibe Code Tests Also

At some point, it was clear that the algorithm implementation needed much more testing. Manually testing them by hand would take ages.

Asking for testing, Claude suggested Vitest. Set it up with Claude Code, and it also added a bunch of tests. I got the safety net I was looking for. Changes that might have broken something? Caught immediately.

The final project is about 6,000 lines of TypeScript and React code. Not huge, but not trivial either. Initially, I did not write a single line of code by hand. Every function, every component, every test was generated by Claude Code based on the spec and my feedback. Eventually, I ended up making a few minor edits when the weekly Claude quota ran out.

Does it work? Yes. Is it production-ready? See the links below and judge for yourself.

Lessons Learned

Looking back, here is what I learned:

1. Spec first, vibe code later - Do not start vibe coding with vague ideas. Spend the time upfront to document what you want. It pays off massively.
2. Static typing is non-negotiable - TypeScript caught so many issues automatically. Without it, I would have been drowning in runtime bugs.
3. Separate testing and production configs - Being able to "fast-forward" through time-dependent logic made testing feasible. Without it, I would still be manually clicking through test scenarios.
4. Add tests from day one - Do not wait until you have bugs. Set up testing infrastructure at the start. It saves so much time.

Links

1. The Project: Repeatrom (Github Repo)
2. Sample Course: Basic German
3. Sample Course: Probability and Statistics

Please note that the course material is auto-generated using LLM (Claude Haiku). It may contain errors or traces of humor.