Anyone can get a working app out of an AI tool now. Describe it, paste the errors back, and in an hour you've got something that runs. That used to take weeks, and it's great. It's also where the problem starts, because "it runs" and "it's good" are different things, and the gap between them is exactly what a CS degree covers.
Take Computer Networks. Everything your browser runs is visible to the person using it. Open dev tools, read the network tab, and you can see every request and every key in the frontend code. If an AI puts your payment API key in client-side code, the app still works perfectly. You just won't know the key is public until the bill shows up. Knowing how HTTP and the client-server split work is what lets you spot that on sight.
Take Algorithms and Data Structures. An app with five test users can hide an O(n²) loop or a query that scans the whole table on every request. It feels instant until real traffic arrives. If you can't read complexity, you can't see why it's going to fall over, and the AI won't flag it because nothing is technically broken.
Take OOP and basic design. When your code is split into sensible pieces, a change in one place stays in that place. When it isn't, every fix risks breaking something else, and you can't tell what, because you never knew how the parts connected.
The point isn't to avoid AI. Use it constantly. But it can only get you as far as your ability to judge its output. If you can't tell good code from code that merely runs, you're not directing the tool, you're hoping it's right.
So the practical move is simple: treat every assignment as a chance to understand the code before you ship it, not after it breaks.
