Slow Learning Still Matters

Let me start with a concrete moment, one I mentioned in passing in another post but want to tell in full here. I was building an animation in SVG, the image format you draw with code and can move with code. I wanted an icon that breathed, that felt alive without looking like a bad GIF. I was in Cursor, a code editor with AI built in, and already had the prompt written, the text request you send to the AI. But I could tell what I was describing was too vague, because 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. I stopped because I wanted to understand what animating an SVG is really about: why one curve, the way a movement speeds up and slows down, looks smooth and another doesn’t. I wanted to be able to look at the result later and say “this is wrong” with arguments, not vibes.

What 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. A regex is a text pattern for checking or finding things, like an email. You ask “give me a regex that validates emails” and it comes back with lookaheads and named groups, the advanced tricks of the trade. 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 (movements stacked one inside another), weird easing curves, strokes that draw themselves with stroke-dashoffset. It looks fine in Chrome and a bit 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 nothing to diagnose with.

Two things you gain by going slow

When you stick with slow learning, or take a traditional course (something people seem to have 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. Instead of “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”. In plain words: let the growth slow down gently at the end, rotate from the center, and don’t redraw the whole shape when moving it is enough. The prompt gets better because you got better first.

The second is diagnosis. You can look at what the AI returns and spot when something isn’t right, because learning built you an intuition in that domain: the animation that works in Chrome but breaks in Safari, the regex that passes the obvious cases but explodes with accents or emoji (unicode), the CSS that looks fine in the demo but stutters on a phone. Without understanding the domain, you can only push back on the obvious, handing the AI the mistakes anyone would spot. 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 (the person who knows how to ask the AI for things), but the only kind of prompt engineer that matters: the one who can audit what comes out and explain what’s needed from a place of authority.

It’s not all or nothing

I don’t mean that everything should be done by hand. That would be ridiculous today, and it’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 you can vibecode without guilt, meaning ask for them and accept the result without reading the code much: a low-risk one-off script, boilerplate (the filler code that comes out the same every time) you won’t touch again, or a connection to some third-party service 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, meaning how a whole system is put together), and domains where the AI gets things wrong often and you have to be the filter.

The rule I wrote about in the other post still holds: 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 do SVG animations, regex, database migrations (moving stored data from one shape to another), all of it, better than today. That doesn’t change the underlying question: are we getting better too?

I try to hit pause every now and then. I keep spending time learning new domains I could have solved with a prompt. Time I could have 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 investment is slow, sometimes ugly, and hard to measure in a two-week sprint, but it’s what separates someone who vibecodes from someone who builds.