When It's Okay to Use AI Blindly

The Experiment

I've never found much value in side projects and tutorials. They don't feel real. I wanted to go through the full experience of building something and shipping it. Something live, with a domain, that real people could use.

So I built vCardly - a simple tool that creates downloadable QR codes for digital business cards. Idea to deploy in about 4 hours.

Here's the thing: I don't fully understand the code.

The Stack

Next.js, built almost entirely with Claude Code and v0. Deployed on Vercel. I described what I wanted, iterated on the output, and shipped it. I didn't sit down and learn the Next.js app router. I didn't study the QR code library internals. I prompted, adjusted, and deployed.

If you asked me to explain every line, I couldn't. And for this project, I don't need to.

Here's the thing though - with AI, it's not hard to write code well. The structure, the patterns, the separation of concerns - AI generally gets that stuff right. So while I was prompting, I was still gut-checking that the layout seemed reasonable. Does this folder structure make sense? Is this component doing too much? I applied judgment at the architecture level and let AI handle the implementation.

I wasn't completely blind. Just appropriately blind. And being appropriately blind takes almost no extra effort - a few seconds of "does this structure look sane?" before moving on. It didn't slow me down.

Why This Is Fine

Not everything you build needs to be understood deeply upfront. That's the lesson from my tokens post - but inverted.

That post was about systems you'll live with at work. Infrastructure your team inherits. Code where shortcuts compound into confusion for every engineer after you.

vCardly is different. It's mine. If I break it, I fix it. If I need to extend it, I'll learn what I need to learn. The risk profile is completely different.

Tracer Bullet, but Blind

There's a concept from The Pragmatic Programmer called tracer bullet code - thin, end-to-end slices that actually work and that you build on. You're firing into the dark to find your target, but the bullets are real. The code stays.

Traditional thinking says: if it's tracer bullet code, you need to understand it. You're building a foundation. You can't build on something you don't understand.

But here's what's changed: AI writes decent, extensible code by default. vCardly isn't throwaway. The structure is there. I can add features to it. I just don't fully understand the implementation details yet.

And that's fine. Understanding can come as I extend it. If I need to add a feature and something breaks, I'll learn that part of the codebase. The knowledge comes on demand, not upfront.

This isn't the same as building on a shaky foundation. The foundation is solid - AI got the patterns right. I just haven't memorized the blueprints. I can read them when I need to.

The Real Skill

AI makes it easy to build things you don't understand. That's powerful and dangerous. The skill isn't avoiding that - it's knowing when it's appropriate.

Ship blind when:

It's yours - you own the consequences
The cost of failure is time, not reputation
You can learn on demand as you extend it

Go deep when:

Other people depend on your choices
You'll maintain this for years with a team
The shortcut will confuse everyone who touches it after you

vCardly has about 30 visitors so far. Maybe it goes somewhere, maybe it doesn't. If it does, I'll learn the parts I need to learn as I build on it. If it doesn't, I learned something anyway: how to go from idea to live product in an afternoon.

Either way, it's live. That's the point.