I keep jumping into things I don’t fully understand and figuring them out on the way. Sequencing my family’s genomes as a data engineer, not a geneticist. Writing shaders I’d never touched before the class that needed them. Building machine-learning things before I could have told you what half the words meant. The pattern is always the same: learn just enough of the basics to start, then learn the rest as the work actually asks for it.

I still mostly believe in this. You can’t front-load a field — the world is too big, and most of what you’d try to learn in advance you’d either learn wrong or forget, because you don’t yet have anything to hang it on. Doing the thing is what generates the real questions, and the questions are what make the learning stick; knowledge that’s immediately load-bearing goes in deeper and faster than knowledge you’re stockpiling for a someday. Your goals decide what you need next, and that’s a better curriculum than any you’d design up front.

But I’ve done this long enough to know where it breaks, and it breaks in a specific, dangerous way.

Some subjects have a foundation you genuinely can’t skip — not because skipping it slows you down, but because skipping it makes you confidently wrong. You get something working, it looks right, and you don’t know enough to know that it isn’t. That’s the real failure mode of learning by doing: not getting stuck, but sailing straight past a mistake you can’t see. I’ve hit my own versions of it — a model that scored well and had a leak I didn’t yet understand, a genomic variant that looked real until I knew enough to tell it was an artifact. In both cases “learn as I go” carried me to a plausible, wrong answer, and only more foundation revealed it was wrong.

So the honest version of “learn by doing” comes with a condition. It works when the feedback is fast and the cost of being wrong is low and checkable — build a small tool, it works or it doesn’t, you see the gap, you learn. It gets dangerous exactly where the feedback is slow or absent and a plausible-but-wrong result passes silently: statistics, security, anything with irreversible consequences, anything where “it ran and produced a number” is not the same as “it’s right.” Match the strategy to how forgiving the domain is. Dive into the forgiving ones. Respect the ones that aren’t.

Here’s the part that’s actually shifting, and I don’t think it’s settled yet.

AI is collapsing the cost of the foundation. The thing that used to make “learn it first” necessary — that you couldn’t get the basics precisely when you hit them — is mostly gone. You can drop into an unfamiliar domain now and have the missing concept explained the moment you need it, against the actual problem in front of you. The barrier to starting something you don’t know has fallen further than it ever has, and I feel it: I take on things now I’d have called out of reach a few years ago, because the just-in-time explanation is always there.

But it cuts both ways, and the second edge is sharper. AI will just as happily hand you a confident, fluent, plausible foundation that’s subtly wrong — and if you don’t have enough grounding to feel that something’s off, you inherit its errors and build on them, faster than you ever could have alone. So it lowers the bar on how much you need to know to begin and raises the bar on judgment: the taste to notice when the fast answer, or your own quick learning, has quietly led you somewhere false. The foundation you can’t skip is moving. It’s less “the facts” now — the facts are cheap — and more the discernment to tell when the facts you’re being handed are wrong.

I don’t have a clean rule to end on, which feels about right for something I’m still working out. What I’ve got is a bias toward starting before I’m ready, a growing respect for the domains where that bias gets people hurt, and a question I didn’t used to have to ask: not only what do I need to know before I start, but can I tell when the thing teaching me is wrong.