> In my workplace I find systems and policies move too slowly to keep up with how rapidly the LLM world is changing. Colleges are even more glacial. Perhaps this is rather a sign that you currently shouldn't jump on the LLM hype train, but rather attempt to get a good foundation on the basics. When the whole LLM area becomes much more "stabilized" (I see signs that this is currently happening, if only for the reason that training state of the art models has become more and more expensive), you can still get into LLMs if you want.

I've been wondering if there would be a benefit to inverting how we teach subjects now. Previously we would teach from the bottom, and build up. Semi-colon goes here, curly brace goes there, and then build up to architecture, systems, etc. But this doesn't seem to make sense when someone comes to a topic with an LLM in-hand. They need to know high-level techniques, architecture, best practice, etc. As they pursue the topic they start to get down into the details, although probably never learn to do it fully independently. I quite like this view because it paints a somewhat optimistic way forward from where we are now.

You can ask LLMs about high-level techniques, and their answers will usually be good enough. What you can't get from LLMs is the taste and judgment, which you can only obtain by having a strong CS base and coding manually for years. High-level techniques were never a problem. You could Google tens of articles on this topic. They are useless too, it's like learning how to drive a racing bicycle from reading a book. Sure, you will know a lot about nuances, but you will fail miserably when it comes to a real race.

taste and judgment, which you can only obtain by having a strong CS base and coding manually for years. I disagree, the definers of taste; art and food critics, movie and book reviewers, don’t need to have learned the craft by doing. Taste is a separate skill.

No one seriously expects a food critic to be able to cook a Michelin-starred meal. The job of that kind of critic is to be insightful and entertaining, and it's very different to the taste required to create top quality food, which is a combination of solid technical skill and creative flair. Taste in coding is a combination of insight, experience, native talent, technical skill, and flair. Tasteful coding produces clever but straightforward minimal elegant solutions that an average developer can't imagine but can adapt and maintain.

I'd say taste is a consequence of lifestyle, which is learned by doing. And art critics often have bad lifestyle, which is visible in their bad taste. When art is virtual life, it would define a lifestyle, which is adopted by doing, in its turn producing taste.

Agreed. Taste implicitly requires discipline of what one chooses to expose themself to and what not to.

> which you can only obtain by having a strong CS base and coding manually for years. I hope this isn’t the case. It is the route I took, but it also doesn’t seem to be a likely route going forward. Strong CS grounding is feasible for sure, but I have a hard time believing that a meaningful number of people will be spending the requisite years coding manually.

Exactly. Repeating or rephrasing a definition is trivial, teaching someone is not.

I can't speak for other disciplines, but for math and CS, both with a really heavy focus on abstraction, the final result of learning is to build a nice intuition on top of the abstractions we find useful/expressive. And to build the intuition, the old, usual, and perhaps the only way is to see and practice a lot of concrete examples, after which the motivation of building some abstraction can be understood, and after which the abstraction itself can be fully grasped. e.g. The "group" abstraction requires one see a lot of int, polynomial, modular arithmetic etc. before knowing why we want such a thing. It's unskippable.

This idea sounds good at first, but if you look closer, it would just make workers, not experts who really understand. What we could do, and already do, is tweak the learned abstractions. In our field, it's easy to see: most of us first learned about computing abstractions, not how processors actually work, or started with Java, not assembler. Plus, you can't teach math from top to bottom.

> As they pursue the topic they start to get down into the details, although probably never learn to do it fully independently. It's hard to claim one has mastered a subject without independent command of its fundamentals. A less charitable take on this future is that students only learn to hand-wave answers and correspondingly cannot evaluate statements beyond "sounds about right".

I don't think you can learn high level techniques or architectures without first understanding the basics first. This means boring boiler plate coding.

I’m not sure. We’ve always had to pick the level of abstraction we start teaching at. Voltages, transistors, registers, assembly, C, etc. This feels like it could just be a progression of that.

Personally, I do believe that math as a discipline has this huge issue of being mostly incomprehensible garbage. Not because the actual truth encoded in it would be this complex, but because the encoding scheme just sucks. I see it as a packaging problem that has so far not been painful enough to trigger any meaningful change. With this LLM-driven collapse, that might finally change. Idk I'm hopeful. Math is literally the law of the universe. It makes zero sense that the way that it is taught needs some special brain wiring only found in small chunks of the population to truly click.

Sorry, but I don't think AI is entirely to blame here. When I graduated from a CS program at a top-10 school, I felt frustrated that the professors didn't ever teach. They had slides. They read off slides, verbatim. They explained things sometimes if you asked them, but most often in a very elitist and condescending tone. Like in the movie Good Will Hunting, you could have learned nearly all of it and more by borrowing those books for free from the library. Or, just opening a complex OSS project and learning to contribute. And quite honestly. It shows in the CS grad population too. A lot of us are condescending toward anything that doesn't make sense to us. But, I digress. The best engineers I've worked with are all non traditional backgrounds, non degree or degree holders from non elite schools. They think differently, they tinker, they are incredibly nice and patient, and do it for the love of connecting humans to technology. Look up the names mentioned in the article. Garcia, Ranade, Nelson. All of them are involved with highly theoretical mathematics and scientific computing. Just because you're good at 1 thing does not mean you are qualified to teach. And none of these professors are trained or taught or graded or performance managed on how they teach. For most of them, its just required that they spend 10% of their time in the classroom lecturing. Let's be honest about another thing. 99% of EECS graduates, even from elite schools, are wrangling objects and their relationships to a graph. Simply put, we're all just a bunch of glorified JSON massage therapists. It just so happens that we get paid well for it, and we hold that over people. The same happens in the classroom. I think in order to facilitate a healthy, educational environment for young adults, we as adults must encourage, motivate and make that environment fun and practical. We force feed binary trees and the compiler AST's, but we need to make it fun. It's like the commonly accepted saying: Schools kill creativity :(.

I really wonder if it's important to learn all that low-level stuff at this point. Most programmers today will never write a binary tree or a hash table. Modern high-performance ones are generic components you get from libraries. Even MIT gave up on teaching from Structure and Interpretation of Computer Programs. I got all that stuff. I've wired up a 4-bit adder on a solderless breadboard for an architecture class. I used to have a well-thumbed copy of Knuth handy. I've designed and built a switching power supply. But I'm not up to date on using Claude Code, and should be.

I think it is important to learn how to implement it because it gives the student an opportunity to learn precisely because it's been done countless times and debated over to death. There are many analyses and if one doesn't click, maybe another one will. A student can learn how to analyze the algorithms and try out different implementations to assess differences in performance. Of course, if a student just breezes through it then I would agree. That would make no sense.

IMHO, I think it's good to have some exposure to low-level stuff. There's a good amount of work you can't do without understanding the low-level stuff, but there's more work you can't do well without having at least an idea of the low-level stuff. Start the kids off with high level stuff, but make them do some embedded systems on their way through. At least for an engineering degree. Also, do a bit of lower level communications somewhere in there; expose them to tcpdump/ wireshark, but they need not develop expertise.