The following article originally appeared on Medium and is being republished here with the author’s permission.

There’s a fake confidence you can carry around when you’re learning a new technology. You watch a few videos, skim some docs, get a toy example working, and tell yourself, “Yeah, I’ve got this.” I’ve done that. It never lasts. A difficult lesson often accompanies the only experience that matters.

You learn through failure—falling flat on your face, looking at the mess, and figuring out why it broke. Anything that feels too easy? It probably was, and you didn’t exit the process with anything worth learning.

Ask About Failure: Failure === Experience

When I’m hiring someone who claims relational database expertise, I ask a “trick” question:

Tell me about the worst database schema you ever created. What did it teach you to avoid?

It’s not really a trick. Anyone who’s been knee‑deep in relational databases knows there’s no perfect schema. There are competing use cases that constantly pull against each other. You design for transaction workloads, but inevitably, someone tries to use it for reporting, then everyone wonders why queries crawl. Another developer on the team inadvertently optimizes the schema (usually years later) for the reporting use case only to make the transactional workload unworkable.

The correct answer usually sounds like:

We built for transactional throughput—one of the founders of the company thought MySQL was a database, which was our first mistake. The business then used it for reporting purposes. The system changed hands several times over the course of several years. Joins became gnarly, indices didn’t match the access patterns, and nightly jobs started interfering with user traffic. We had to split read replicas, eventually introduce a warehouse, and after 5–6 years, we ended up simplifying the transactions and moving them over to Cassandra.

That’s a person who has lived the trade-offs. They’ve experienced a drawn-out existential failure related to running a database. While they might not know how to solve some of the silly logic questions that are increasingly popular in job interviews, this is the sort of experience that carries far more weight with me.

The Schema That Nearly Broke Me

I once shipped a transactional schema that looked fine on paper: normalized, neat, everything in its proper place.

Then analytics showed up with “just a couple of quick dashboards.” Next thing you know, my pretty 3NF model, now connected to every elementary classroom in America, was being used like a million-row Excel spreadsheet to summarize an accounting report. For a few months, it was fine until it wasn’t, and the database had made a slow‑motion faceplant because it was spending 80% of its time updating an index. It wasn’t as if I could fix anything, because that would mean several days of downtime coupled with a rewrite for a project whose contract was almost up.

And how were we trying to fix it? If you’ve been in this situation, you’ll understand that what I’m about to write is the sign that you have reached a new level of desperate failure. Instead of considering a rational approach to reform the schema or separating what had become a “web-scale” workload in 2007 from a NoSQL database, we were trying to figure out how to purchase faster hard drives with higher IOPS.

I learned a lot of things:

I learned that upgrading hardware (buying a faster machine or dropping a million dollars on hard drives) will only delay your crisis. The real fix is unavoidable—massive horizontal scaling is incompatible with relational databases.

I learned the meaning of “query plan from hell.” We band‑aided it with materialized views and read replicas. Then we did what we should’ve done from day one: set up an actual reporting path.

If you are having to optimize for a query plan every week? Your database sending you an important signal, which you should translate to, “It’s time to start looking for an alternative.”

Lesson burned in: Design for the use case you actually have, not the one you hope to have—and assume the use case will change.

What Does This Have to Do with Cursor and Copilot?

I’m seeing a lot of people writing on LinkedIn and other sites about how amazing vibe coding is. These celebratory posts reveal more about the people posting them than they realize, as they rarely acknowledge the reality of the process—it’s not all fun and games. While it is astonishing how much progress one can make in a day or a week, those of us who are actually using these tools to write code are the first to tell you that we’re learning a lot of difficult lessons.

It’s not “easy.” There’s nothing “vibey” about the process, and if you are doing it right, you are starting to use curse words in your prompts. For example, some of my prompts in response to a Cursor Agent yesterday were: “You have got to be kidding me, I have a rule that stated that I never wanted you to do that, and you just ignored it?”

Whenever I see people get excited about the latest, greatest fad thing that’s changing the world, I’m also the first to notice that maybe they aren’t using it all. If they were, they’d understand that it’s not as “easy” as they are reporting.

The failure muscle you build with databases is the same one you need with AI coding tools. You can’t tiptoe in. You have to push until something breaks. Then you figure out how to approach a new technology as a professional.

Ask an agent to refactor one file—great.

Ask it to coordinate changes across 20 files, rethink error handling, and keep tests passing—now we’re learning.

Watch where it stumbles, and learn to frame the work so it can succeed next time.

Spend an entire weekend on a “wild goose chase” because your agentic coder decided to ignore your Cursor rules completely. ← This is expensive, but it’s how you learn.

The trick isn’t avoiding failure. It’s failing in a controlled, reversible way.

The Meta-lesson

If you’ve never broken it, you don’t really know it. This is true for coding, budgeting, managing, cooking, and skiing. If you haven’t failed, you don’t know it. And most of the people talking about “vibe coding” haven’t.

The people I trust most as engineers can tell me why something failed and how they adjusted their approach as a result. That’s the entire game with AI coding tools. The faster you can run the loop—try → break → inspect → refine—the better you get.