> Teaching how code works is more important than teaching how to code.

People learn by doing. There's a reason that "do the textbook problems" is somewhat of a meme in the math and science fields - because that's the way that you learn those things.

I've met someone who said that when he get a textbook, he starts by only doing the problems, and skipping the chapter content entirely. Only when he has significant trouble with the problems (i.e. he's stuck on a single one for several hours) does he read the chapter text.

He's one of the smartest people I know.

This is because you learn by doing the problems. In the software field, that means coding.

Telling yourself that you could code up a solution is very different than actually being able to write the code.

And writing the code is how you build fluency and understanding as to how computers actually work.

> I never did any meaningful amount of assembler programming. It was mostly no longer a relevant skill by the time I studied computer science (94-99). I built an interpreter for an imaginary CPU at some point using a functional programming language in my second year.

Same thing for assembly. Note that you built an interpreter for an imaginary CPU - not a real one, as that would have been a much harder challenge given that you didn't do any meaningful amount of assembly program and didn't understand low-level computer hardware very well.

Obviously, this isn't to say that information about how a system works can't be learned without practice - just that that's substantially harder and takes much more time (probably 3-10x), and I can guarantee you that those doing vibecoding are not putting in that extra time.