Systems Programming
In industry, systems code is increasingly drafted by AI coding agents whose memory-safety faults, undefined behavior, and ABI mismatches survive passing tests, so the practitioner's work shifts toward verification, disassembly-level confirmation, and accountability for code no human typed. Systems programmers are also now the people who build the substrate AI runs on, so the course keeps its translation-software and hardware-interface core and adds sandboxing, resource control, and memory-mapped data movement for agent and inference workloads.
Current catalog prerequisites — (CSC 300 or 4400).
Current description → proposed description
This course examines system-level software in depth with an emphasis on translation software and database systems. The interaction between systems-level software and the computer hardware is studied. The role of computer scientist in abstracting the hardware from the computer user is explored.
Prerequisites: (CSC 300 or 4400).
This course examines system-level software in depth, with emphasis on translation software — compilers, assemblers, linkers, and loaders — and on the storage engines beneath database and retrieval systems. Students program directly against the operating-system interface, managing memory, processes, file descriptors, and concurrency, and read the object code and disassembly the toolchain actually emits, studying how these abstractions rest on the underlying hardware. Because much systems code is now drafted by AI coding agents, and because memory-safety faults, undefined behavior, and ABI mismatches routinely survive passing tests, students practice verification through sanitizers and differential testing, retaining professional accountability for code they did not type. Students also construct the systems substrate that AI workloads depend on, including process isolation and resource limits for agent tool execution, least-privilege sandboxing that contains the consequences of prompt injection and tool supply-chain compromise, and memory-mapped access to model weights and vector indexes. The role of the computer scientist in abstracting hardware from the user remains central throughout.
What changes
- Verification of AI-generated systems code with sanitizers and differential testing
- Process, account, and filesystem isolation with resource limits for agent tool execution
- "Database systems" rescoped to storage-engine internals and extended to vector indexes
- Memory-mapped model-weight and retrieval data movement measured as p50/p99 distributions with its memory and energy cost
- Provenance disclosure and retained accountability for code the student did not type
6 proposed outcomes, mapped to 5 program outcomes
Each outcome below is written to be observable and assessable, and each is mapped to the program learning outcomes for which it produces evidence.
Students will be able to implement and evaluate competing designs for the systems primitives that host an inference service — process-per-request, thread-pool, and shared-memory handoff — managing memory, inter-process communication, and file descriptors directly against the operating-system interface, and justifying the chosen design against measured latency and isolation trade-offs.
Building competing architectures for an inference-serving system and selecting one on measured latency and isolation evidence is precisely the proposing and evaluating of an AI-driven solution that 4.2 names, with the evidence supplied by the student's own measurements rather than assertion.
Students will be able to analyze the translation of a program through compilation, assembly, linking, and loading, using object-file inspection and disassembly to determine whether AI-generated source does what it appears to promise and what is at stake in shipping a binary whose emitted behavior no human has inspected.
Inspecting the machine code emitted from AI-generated source is critical analysis of a model-produced outcome, and weighing what is at stake in shipping an uninspected binary supplies the ethical and societal dimension 4.1 requires.
Students will be able to evaluate AI-generated systems code for memory-safety faults, undefined behavior, race conditions, and ABI mismatches using sanitizers and differential testing, producing an evidence-based accept, revise, or reject decision.
Judging generated code against sanitizer and differential-testing evidence rather than its apparent correctness, and committing to an accept, revise, or reject decision on that evidence, is critical analysis of a model-produced outcome.
Students will be able to construct an isolation boundary for an AI agent's tool execution — process separation, an unprivileged service account, filesystem-permission restriction, and per-process CPU and memory limits — that bounds the blast radius of a successful prompt injection or a compromised tool dependency, demonstrating by test that a deliberately misbehaving tool cannot read, write, or consume beyond a declared allowlist.
Confining an agent's file, CPU, and memory reach to a declared allowlist is concrete responsible management of AI compute resources (2.3), and building the boundary and then testing it against a deliberately misbehaving tool is proposing and evaluating an AI-system solution on evidence (4.2).
Students will be able to optimize data movement across the memory hierarchy for data-intensive workloads — buffer management, page layout, and durability in storage engines, and memory-mapped access to model weights and vector indexes — on the basis of throughput and latency reported as p50/p99 distributions across repeated runs rather than single observations, and accounting for the memory footprint and energy cost the chosen layout imposes.
Reporting throughput and latency as p50/p99 distributions across repeated runs supplies the statistical rigor 6.2 asks for in drawing conclusions about retrieval and inference behavior, while accounting for the memory footprint and energy cost a layout imposes is the responsible resource management 2.3 describes.
Students will be able to articulate, in written technical documentation, the provenance of the systems code they submit: which components were AI-generated, what verification evidence supports them, and what accountability they retain for software that runs with privilege over other people's data and machines.
Disclosing authorship and the supporting verification evidence in writing is exactly the transparent technical communication made with integrity that 5.1 requires.
Program outcomes this course reaches
Filled cells are program learning outcomes with at least one supporting course learning outcome in this course. Sparse coverage is expected — no single course carries all eighteen.