CS 394E · Fall 2026/2027
Syllabus & policies
What is expected, how it is graded, and what happens when things go wrong. This page is the current version — it is kept up to date through the term.
Course information
| Course | CS 394E — Contemporary Topics in LLMs |
| Department | Computer Science, KAUST |
| Semester | Fall 2026/2027 — classes 2026-08-30 → 2026-12-07 |
| Meetings | Mondays, 14:30–17:30 (week 1 only: Mon & Thu, 14:30–16:00) |
| Location | Building 9, Classroom 4225 (week 1 only: Classroom 3223) |
| Instructor | Marco Canini · marco@kaust.edu.sa · Room 4418, Level 1, Al-Khawarizmi (Bldg. 1) |
| Teaching assistants | Norah Alballa · Kaihua Liang |
Assessment
| Component | Weight |
|---|---|
| Semester-long research project | 50% |
| — proposal | 10% |
| — midterm report | 15% |
| — final report & presentation | 25% |
| Student-led research paper presentations | 15% |
| Paper reviews and class participation | 20% |
| Implementation assignments (three) | 15% |
Attendance and participation
This is a discussion-driven course; attendance and active participation are graded. Up to two unexcused absences are allowed. Additional absences require an approved reason — illness, family emergency, conference presentation — with advance notice when the conflict is foreseeable.
Participation means engaging with the reading in class: asking questions, taking a position on the paper’s claims, and responding to your classmates. Quantity of speech is not the metric; substance is.
Paper summaries
There are at most two readings per week. For each assigned reading you submit a review through HotCRP — the same software used to review conference papers.
- Length: fewer than 500 words.
- Due: 12:30PM Saudi time, the day of class.
- Late: accepted until class starts at −50%. Not accepted once class has begun, except with KAUST-approved accommodations or an excused absence.
The form asks four questions:
- What is this paper about, in 30 seconds? Explain it to a classmate who has not read it. Your own words, not the abstract’s.
- Why was this paper written and published? What made the work worth doing, and what did the authors do well enough for it to be accepted — a new idea, a careful experiment, a surprising measurement, a difficult piece of engineering.
- Where did the paper not convince you? What did the authors not show, not measure, or skip over? Distinguish “they did not do X” from “I could not tell whether they did X” — saying which one applies to you is a perfectly good answer.
- What would you do next? One thing: an experiment the authors skipped, a situation where you expect their idea to fail, or a different problem you would apply it to.
Summaries must be written individually and without generative AI. Grammar and spell-checking tools are fine.
Most weeks also list a few readings tagged Further reading. These are background and related work for anyone who wants to go deeper — they are not assigned, carry no summary, and are never the basis of a presentation.
Paper presentations
Each student presents in one or two classes.
- Slides due: 24 hours before the class you are presenting.
- Late slides: shared less than 24 hours before class, −25%; not shared before class starts, −50%.
- Swaps: arrange a swap or notify the instructor at least 72 hours in advance. Documented emergencies will be accommodated.
- Sharing: ideally share the slides in a form the instructor can comment on — a OneDrive or Google Slides link.
- You may use publicly available material — including the authors’ own slides — with proper attribution.
Guidelines
- Motivate the paper and provide background.
- Present the high-level idea, approach, and/or insight — using examples whenever appropriate.
- Discuss technical details, so that one can understand the key details without carefully reading the paper.
- Explain the difference between this paper and related work.
- Identify any limitations of the work.
- Say what has happened since the paper appeared, in one or two slides. Many of our readings are a year or two old, and in this field that is a long time. Were the paper’s recommendations adopted? Do its findings still hold for current models? What did follow-up work extend, challenge or replace? Back each claim with a source — a follow-up paper, a model or system card, a benchmark or leaderboard. Frontier labs rarely say what they changed, so separate what is documented from what you infer. “I found no evidence either way” is a legitimate answer, and for a very recent paper “too early to tell, and here is what to watch” is too.
- Raise questions throughout the presentation to generate discussion. Closing with your questions is the minimum; planting them as you go is better, because the room engages while the material is still fresh.
- Remember to number your slides. The audience can then ask a question referencing a specific slide, and feedback on your deck can quote slide numbers — quicker for everyone, and it avoids ambiguity.
Suggested structure
This is a suggestion, not a required format — a talk that covers the guidelines in a different order is fine.
- Problem
- Core ideas
- Descriptive summary, technical details and main results
- Related work
- Strengths
- Weaknesses and limitations
- What has happened since
- Further discussion, including proposals for follow-up work
Prepare early and practice. Worth reading first: David A. Patterson, How to Give a Bad Talk; Randy H. Katz, Pointers for Leading Paper Discussions; and Simon Peyton Jones, How to Give a Great Research Talk (video).
Assignments
There are three short implementation assignments, worth 5% each, each due one week after it is released. Late work incurs a 10% penalty per 24 hours (or fraction thereof) up to 72 hours, after which a zero is recorded without an approved extension.
Research project
The project is 50% of the grade and runs the whole term. Teams of up to three. It is graded in three milestones: proposal 10%, midterm report 15%, and final report and presentation 25% (report 15, presentation 10). Details and deliverables are on the Assignments & project page.
Academic integrity, collaboration and AI use
Paper summaries: individual work, no generative AI (spell-check is fine).
Presentations: public materials permitted with proper attribution.
Project: teams of up to three. Conceptual discussion across teams is encouraged; code sharing across teams is not permitted. External libraries and datasets are allowed where license-compatible.
Implementation assignments: individual work. AI tools are not forbidden but discouraged; if you use them, a disclosure of which tools and what for is mandatory, in a short note with your submission.
AI coding assistants are allowed on the project, and using them well is a real skill. What is required is disclosure: name the models and tools you used, include representative prompts, and say where in the work they were applied. You remain responsible for the correctness, security and originality of everything you submit — a tool’s mistake becomes your mistake the moment you hand it in.
This is asked of you because disclosure is becoming the standard expectation in computing research, not a rule peculiar to this course. ACM’s Policy on Authorship already holds that generative AI tools may not be listed as authors of a published work, and that their use to create content “is permitted but must be fully disclosed in the Work.” Building the habit now is practice for submitting your work anywhere.
Fabricated results are a violation, full stop.
All work must comply with KAUST research ethics and data-governance policy — including de-identification and IRB approval where required. Violations are handled per KAUST policy.
Learning outcomes
By the end of the course, successful students will be able to:
- Conduct independent research in LLM systems, applications or safety by formulating novel hypotheses, designing rigorous experiments, and presenting findings through technical reports and peer-review-quality presentations.
- Critically analyze and synthesize state-of-the-art LLM research by evaluating methodologies, identifying limitations, and proposing meaningful extensions.
- Design and implement scalable multi-agent LLM systems that coordinate specialized agents to solve complex, multi-step problems with dynamic task allocation and external tool integration.
- Evaluate and mitigate safety risks in LLM applications by detecting hallucinations, bias and adversarial behavior, and implementing response mechanisms suitable for deployment in sensitive domains.
- Design and optimize LLM inference systems using serving architecture design, caching strategies and distributed computing to meet real-world performance demands.
- Build and evaluate RAG systems integrating vector databases, embedding models and structured knowledge sources for factual consistency and source attribution.
- Adapt LLMs to domain-specific applications in healthcare, education or scientific research, addressing ethical concerns, regulatory standards and domain-expertise integration.
Changes
This page is the syllabus of record and is kept current through the term. The instructor reserves the right to make changes as necessary; material changes will be announced in class and reflected here.