What should a Computer Science & Engineering (CSE) curriculum look like in the AI / AGI era?

What should a Computer Science & Engineering (CSE) curriculum look like in the AI / AGI era? I think we need to rethink the CSE syllabus—not by throwing away fundamentals, but by going deeper into the parts of computer science that AI cannot reliably abstract away. This is a living post. I’ll keep updating it as I develop the argument further, and I may turn it into a longer article. 1. Fundamentals still matter — perhaps more than ever The fact that AI can generate code does not eliminate the need to understand what that code is actually doing. Consider assembly language. For the last 15–20 years, almost no software engineer has needed to write assembly routinely. Compilers and increasingly sophisticated toolchains handle most of it. Yet at the systems level, there remain situations where hand-written assembly is indispensable. For example, when a hypervisor call has a hard timing constraint in the ~10–30 ms range, or when a new processor generation arrives and existing compilers are not yet capable of producing sufficiently coherent or optimized code for a particular workload. The same principle applies beyond assembly. AI will increasingly write code. But there will still be layers where the engineer needs to understand and manipulate the system directly. AI can fail particularly badly at these boundaries because the relevant knowledge may be: - poorly documented, - highly hardware-specific, - novel, - distributed across source code, specifications and empirical behaviour, - or simply absent from the public corpus on which a public AI model was trained. So hand-coding skills don't disappear. They move upward and downward in importance depending on the abstraction boundary. 2. Theoretical Computer Science needs greater emphasis The theoretical CS syllabus was always there. It was often simply treated as something to get through. That is becoming increasingly problematic. Modern AI systems can produce remarkably sophisticated outputs without giving us a general theory of how their architectures actually produce the observed behaviour. Understanding algorithms, computability, complexity, formal languages, automata, semantics, information, logic and related foundations becomes more—not less—important. But there is an important distinction: The challenge is not merely more mathematics. One of the places AI frequently fails is in novel architectural reasoning. Knowing the mathematics behind an existing system is different from being able to design a new computational architecture. CSE education needs to teach the latter much more explicitly. 3. Teach the topology of algorithms Students need to understand not merely the equations or proofs associated with an algorithm, but its structural topology. How does information move? What depends on what? Where are the state boundaries? What can be parallelized? What must remain sequential? Where does locality emerge? Where are the bottlenecks? What happens when the algorithm is mapped onto an actual machine? This is fundamentally a design perspective. Mathematical proof remains important. But an AI/AGI-era engineer also needs to be able to see the computational structure of an algorithm. 4. Hardware–software co-development The historical separation between “hardware people” and “software people” becomes increasingly artificial. Modern computing systems are co-designed. GPU architectures, NPUs, accelerators, memory hierarchies, interconnects, instruction sets, compilers, runtimes and operating systems increasingly influence one another. CSE should therefore teach hardware–software co-development as a first-class engineering discipline. The question should not merely be: «“How do I write software for this machine?”» It should also be: «“What computational architecture should the machine expose so that the software can do this efficiently?”» And eventually: «“What hardware and software architecture should be designed together?”» 5. Formal methods should become core engineering knowledge AI-generated code creates an interesting reversal. When humans wrote every line, reviewing code was largely a matter of reading what another human had written. When machines generate enormous quantities of code, trust cannot depend on reading everything manually. We need stronger mechanisms for establishing that a system satisfies its intended properties. That means greater emphasis on: - formal specification, - verification, - model checking, - theorem proving, - type systems, - static analysis, - contracts, - invariants, - refinement, - proof-carrying artefacts, - and verification-driven development. The question increasingly becomes: How do we know the generated system is correct? Not: Did the AI produce something that looks correct? 6. Teach the art of software engineering This may sound strange in an engineering curriculum. It shouldn't. Software engineering has always contained an element that cannot be reduced to syntax, algorithms or APIs. Architecture. Abstraction. Decomposition. Naming. Boundaries. Interfaces. Trade-offs. Knowing what not to build. Knowing when a simple solution is better than an elegant one. Understanding the future maintenance cost of today's decision. AI can generate enormous quantities of technically plausible code. That makes engineering taste and architectural judgment more valuable, not less. The future engineer may write fewer lines of code personally while making substantially more important decisions about the codebase. 7. Much deeper computer architecture Students need substantially stronger understanding of what actually happens between software and silicon. Not just introductory CPU diagrams. For example: - virtual-to-physical address translation, - TLBs and page tables, - cache hierarchies, - cache coherence, - memory consistency, - NUMA, - interconnects, - DMA, - speculative execution, - branch prediction, - accelerators, - heterogeneous computing, - distributed shared-memory considerations, - and coherence and communication across clusters. Consider something as apparently simple as memory. A programmer sees an address. The machine sees a chain of translations, caches, permissions, mappings, coherence protocols and physical resources. AI can abstract this away when everything behaves normally. But when it doesn't behave normally, the engineer needs to know what lies underneath the abstraction. And increasingly, that is where the interesting problems are. --- The larger principle I don't think the AI/AGI era means we need less Computer Science. I think it means we need more Computer Science, at greater depth. If AI increasingly takes over routine implementation, the educational centre of gravity should move toward: fundamentals → theory → architecture → system design → formal reasoning → verification → hardware/software co-design → engineering judgment The CSE graduate of the future should not simply be someone who can produce code. AI can already do that increasingly well. The valuable engineer will be someone who can: understand the computational substrate, formulate the problem, design the architecture, reason about its behaviour, verify its properties, and know where the abstractions break. That is a very different definition of “programmer.” And perhaps it is time for the CSE syllabus to acknowledge it. Living post: I’ll keep extending this list with specific subjects, curriculum changes, laboratory requirements, and examples from systems engineering and AI/AGI architecture. I may consolidate the evolving version into a longer article.