The Confidence That I Have in My Taste, and My Ability to Express What I Feel

If you haven't seen this clip from the 60 Minutes interview with legendary music producer Rick Rubin, now's your time:

Having confidence in your taste and an ability to express what you feel (and, I might add, what you want): this is what "vibe coding" is all about.

"Vibe coding" was just named word of the year by Collins Dictionary, defined as "an emerging software development practice that turns natural language into computer code using AI."

I've been vibe coding for six months using Cursor (I'm actually drafting this post inside Cursor, although the words are entirely my own). If you're thinking of trying it out, here's what I've learned:

1. Always make a plan for more involved work

Cursor's Plan mode is excellent, especially with Sonnet 4.5. It asks smart questions before executing—this is where the magic happens. Answering those questions helped me settle on the right stack (Next.js 15, TypeScript, Tailwind CSS) and avoid costly rewrites later.

The pattern: Think in Chat → Plan in Plan mode → Execute in Composer.

2. Claude Code will keep you honest

Install Claude Code and use it to critique your project from a different perspective. Be specific: ask it to evaluate architecture, security, code quality, and test coverage. Request a grade and recommendations. Save that to a .md file—you now have a continuous improvement roadmap you can convert into Issues.

This catches things Cursor won't because it's been embedded in your project the whole time. Fresh eyes matter, even if those eyes are AI.

3. Switch to Composer 1 for most coding tasks

Cursor's in-house agent model is lightning fast, and code quality is barely different from Sonnet 4.5. The speed difference is massive.

My workflow: Plan thoughtfully (Sonnet 4.5) → Execute with speed (Composer 1).

4. Start with what you know, then convert

I built my latest project (Mindarin) as an R package first. With my data analytics background, I could give specific guidance ("use tidyverse packages", "run devtools::check()") and reach MVP in a day. Then I converted it to Next.js.

Starting in a familiar language means better prompts and faster iteration. The conversion step is trivial compared to figuring out what to build.

5. Implement tests from the start

I use test-driven development for every new feature—nothing gets built before its test. I'm running hundreds of tests now (unit, component, hook, E2E), and most were written by Cursor.

Tests aren't overhead with AI coding—they're documentation that runs. They also prevent the AI from breaking working features. When you're shipping fast, tests are the guardrails that keep you from driving off a cliff.

6. Version control isn't enough

The full GitHub ecosystem matters:

Actions: Run tests in parallel across multiple workflows. Catches regression before production. You might not need CI from day one, but there will come a point where you need it to prevent yourself from breaking things you've already fixed.

Issues: Your roadmap, labeled by priority. Have Cursor create them via GitHub CLI after planning conversations with Sonnet 4.5. Well-structured Issues become your project's memory.

Projects: Organize Issues into P1/P2/P3 views. Always know what to work on next. When I run out of fixes to apply in Cursor, I know exactly where to pull the next job from.

7. Always ask questions in Ask mode

Seems obvious, but don't brainstorm in Agent mode—it's prone to action and will start coding before you're ready.

Use Ask mode (with Sonnet 4.5) for thinking through problems. It can still read your files and search the web, but won't touch your code. Build a plan from these conversations, then execute.

Think of it this way: Ask mode is for architects, Agent mode is for builders. Get the design right before you break ground.

8. Don't let debugging slow you down

I'm pushing to main dozens of times a day. Most CI runs fail on first attempt. Cursor fixes things fast, but it's way more effective if you feed it the actual logs.

Solution: Ask Cursor to write a script that downloads logs from your most recent failed CI run. Point it at those logs when troubleshooting. Beats copy-pasting from the web, and Cursor can pattern-match errors across your entire codebase.

9. Stop writing documentation manually

I haven't written a commit message in three months. Cursor generates them from my staged changes, writes my README from the codebase, and creates inline docs as I code. The time I save goes into building features users actually care about.

Documentation is a solved problem now. Your brain should focus on what to build, not how to describe it.

10. Speak your thoughts out loud

Cursor has voice mode now, but I prefer superwhisper—it understands me first try, filters out "um" and "actually," and its free tier is generous.

Speaking forces you to provide more detail than typing. You naturally explain context, edge cases, and intent. Better prompts = better code.

---

What Vibe Coding Actually Changes

Here's what surprised me most about six months of vibe coding: it's not that I can build faster (though I can). It's that I can now build things that were previously out of reach.

Before Cursor, I had a graveyard of half-finished projects—ideas that died when I hit my technical ceiling. The gap between "I want this to exist" and "I can make this exist" was often too wide to bridge alone.

Now? That gap is gone.

Mindarin would have been impossible for me a year ago. Full authentication system, spaced repetition algorithm, multi-export functionality, hundreds of tests, accessibility-first design — each of these would have been a research project in itself. Together, they would have been overwhelming.

Instead, I built it in two weeks.

But here's the thing: The code is better than I could have written alone. Not just faster — better. More tests, better architecture, more thorough error handling. Because I could focus my limited expertise on the hard problems (what does a seamless learning experience look like?) while Cursor handled the implementation details I would have muddled through.

Rick Rubin talks about having confidence in your taste. Vibe coding is what happens when you can finally express that taste without your technical skills being the bottleneck. You can hear the song in your head, and now you can actually produce it.

It's no wonder that the subreddit r/vibecoding has a Rick Rubin image on its front page.

What This Means for You

If you're considering vibe coding, here's my advice: Just start. Pick a problem you actually have, something you'd use yourself, and build it. Don't wait for the perfect idea or the perfect moment.

Start with what you know. Use Ask mode to plan. Let the AI handle the boilerplate. Focus on the interesting problems.

You'll be shocked at how quickly something that seemed impossible becomes real.

And if you get stuck? That's good. It means you're learning the right things — not how to configure webpack, but how to think about what you're building.

---

Mindarin—my vibe-coded Chinese learning app using memory palace techniques—is live at mindarin.vercel.app. Built entirely with the approach described here.

What are you building? I'd love to hear about it: comment below!