Slow learning pays off

Let me start with a concrete moment. I was building an SVG animation: an icon that breathed, that felt alive without looking like a bad GIF. I was in Cursor and already had the prompt written, though I could tell what I was describing was too vague, given that I didn’t have much experience animating SVGs.

And I stopped right there.

Not because the AI couldn’t understand me and do it better than I could in five minutes. It surely could. But because I wanted to understand what animating an SVG is really about. I wanted to know why one curve looks smooth and another doesn’t. I wanted to be able to look at the output later and say “this is wrong” with arguments, not vibes.

What do you lose when you don’t learn?

There’s a big difference between using something and understanding it. AI makes that difference worse because it closes the gap so fast you never feel it.

You’ve been there with a regex, I’m sure. You ask for “give me a regex that validates emails” and it comes back with lookaheads and named groups. It works. You run the tests, they pass, you ship. But if someone asks you why that (?= is there, you stare at the ceiling.

Same with the animation. The AI throws you an SVG with nested transforms, weird easing curves, paths animated with stroke-dashoffset. Looks fine in Chrome. Kind of off in Safari. You don’t know if it’s a browser bug or your code because you never built one by hand.

Superficial knowledge works until it doesn’t. And when it fails, you have no tools to diagnose.

Two things you gain by going slow

When you stick with slow learning, or learn through a traditional course (which nowadays seems like something people stopped doing, since “AI solves everything”), you gain two things speed doesn’t give you.

The first is judgment. You know what to ask the AI because you know what a good solution looks like in that domain. You don’t say “make me a nice animation.” You say “ease-out on the scale, keep the transform-origin centered, avoid animating the path’s d if you can use transform instead.” The prompt gets better because you got better first.

The second is diagnosis. You can look at the AI’s output and spot when something doesn’t look right. It’s possible because when you learn, you develop a powerful intuition in that domain. That animation that works in Chrome but breaks in Safari. That regex that passes the obvious cases but explodes with unicode. That CSS that looks fine in the demo but causes jank on mobile. Without understanding the domain, you can only push back on the obvious stuff. With the domain, you see the real problem.

Continuing to learn the traditional way, slowly, suffering through it when things don’t work out, doesn’t make you a worse prompt engineer. It makes you the only kind of prompt engineer that matters: the one who can audit what comes out, the one who can explain what’s needed from a place of authority.

It’s not all or nothing

I don’t mean to say that everything should be done by hand. That would be ridiculous in the current context, that’s not what I’m saying.

The point is different: don’t let comfort convince you that you don’t need to know the domain you’re prompting about. There are things where you can obviously vibecode, like a (low-risk) one-off script, boilerplate you won’t touch again, or an API integration you just need working today.

But there are things where going slow still makes sense. New patterns you’ll use often. Techniques that show up across your work (CSS, SQL, animations, system design). Domains where the AI gets things wrong often and you have to be the filter.

My imperfect practical rule: if something is going to demand judgment from me in six months, I stick it out and learn it now. If it’s disposable, the AI.

Are we keeping up?

The paradox of starting with AI is that the people who got the most out of it early were the ones who had spent years learning without it. All that prior slowness was the foundation. Without it, prompting is guessing. With it, it’s directing.

AI is going to keep getting better. It’ll make SVG animations, regex, database migrations, all of it, better than today. That doesn’t change the question: are we getting better too? Do we have a strategy to fight cognitive atrophy?

I try to stop the ball every now and then. I keep investing time learning about new domains I could’ve solved with a prompt. Time I could’ve used to learn the “latest AI tool.” Because every time I learn something by hand, the next time I use AI I walk away with something better, not just something faster.

That’s the investment. Slow, ugly sometimes, hard to measure in a sprint. But it’s what separates someone who’s vibecoding from someone who’s building.