Syllabus

Welcome to CSE 190: Working with Large Codebases: Traditional and Agentic Software Engineering! We are so excited to have you in our course! :) This hands-on practicum introduces students to understanding and working with large codebases through a human-centered, agent-assisted approach, using both traditional software engineering practices and modern agentic AI tools. Students will learn how to fix bugs and modify/add features in existing, unfamiliar code, first building strong fundamentals in reading, navigating, and reasoning about unfamiliar systems, then extending those skills with agentic coding tools (e.g., Claude Code, GitHub Copilot, Codex) that can accelerate exploration, development, and testing in large codebases. Students will learn processes, techniques, and tools for working with large codebases, including how to critically evaluate and effectively direct AI-assisted workflows. Students will work in small teams on a large open-source codebase throughout the course. By the end of the course, students will develop practical skills and confidence to collaborate on complex software projects in real-world settings. This course is recommended for students without internship experience, although anyone is welcome to register.

Basics

What is a team? Every student is placed in a team with one tutor. Your team stays the same all quarter and meets with your tutor every week (the “team meeting”). Assignments and skill demos are done with people from your team. Assignments are done in pairs you choose yourselves. Skill demo partners are picked at random. Group Project groups are assigned by your tutor within your team. Your team is the bigger community that all of these come from.

Instructor: Professor Gerald Soosairaj
Course Website: cse190largecodebasesfall2026.github.io
Lectures: Tue and Thu, 2:00 - 3:20pm, Design and Innovation Building (DIB) 122
Skill Demonstrations:
- Midterm Skill Demo: Week 6, during team meeting
- Final Skill Demo: Week 10, during team meeting
Group Project Final Presentations: Week 11, Thu 12/10/2026, 3:00-5:59pm, FAH 1450
Team Meetings: 2 hrs/week, from weeks 2 to 10. Day and time for each tutor are on the Home page. Locations will be posted there once scheduled.
Professor Office Hours: Fridays 1:00-2:00pm, CSE 2106
Q&A forum: Ed Discussion
Canvas
Gradescope (for lecture handouts)

Prerequisites

The prerequisite for this course is CSE 110: Software Engineering, or relevant software engineering experience.

Learning Objectives

Students who successfully complete this course will be able to:

Set up a development environment to build and work on software tools from source.
Read, understand, and modify parts of a codebase.
Test and debug issues in a large codebase, including writing tests for code that has none.
Understand how to conduct and respond to code reviews for proposed changes to a code base, including changes written by an AI agent.
Adhere to code quality standards and conventions for an existing code base.
Communicate how a codebase works, and why you changed it, to others.
Use documentation and Q&A websites to learn just-in-time, and apply what you learn on one codebase to get up to speed on a new one.
Use agentic AI coding tools to understand, modify, debug, and test a codebase, and describe where they fall short.
Work effectively in a team that uses a distributed version control system (e.g., git).
Verify code before relying on it, whether you, a teammate, or an AI agent wrote it.

Core Competencies

This course builds proficiency in three core competencies:

Technical skills: reading, navigating, modifying, debugging, and testing unfamiliar code, both by hand and with agentic tools. Includes judgment/verification (knowing what to check and when to trust code or an agent’s output) and just-in-time learning (ramping up on a new codebase quickly).
Collaboration skills: working in small teams on a shared codebase: reviewing a teammate’s or an agent’s diff, matching existing conventions, coordinating changes, working with ambiguity.
Communication skills: explaining what you did and why: documentation, PR descriptions, process journals, and presentations, including explaining an agent’s output to a reviewer.

What topics will we learn?

See the Lecture Schedule: traditional software engineering (idlelib, Weeks 1-5) followed by agentic software engineering (OpenRefine, Weeks 6-10). For every assignment, Skill Demo, and Group Project date, see the Course Calendar.

Course Components

There are three grading categories in this course: Assignments (which includes the Group Project), Assessments (the skill demonstrations), and Social Learning.

1. Assignments

(Includes the Group Project as a 2×-weighted item. See below.)

Done in self-chosen pairs, within your team. 3 assignments total: 2 during the traditional half (idlelib, Weeks 1-5), 1 during the agentic half (OpenRefine, Weeks 6-10). A1 modifies an existing feature and A2 adds a new feature, both in idlelib. A3 adds a significant feature to OpenRefine with an agent.

Each assignment is assessed across all three competencies:

Competency	Covers	Graded
Technical	Correctness, process followed with version control, design, code quality	Async, from your pair’s repo
Collaboration	Peer code review, whether review feedback was acted on, evidence of shared contribution in commit history	Async, from your pair’s repo
Communication	Technical documentation (with design/diagrams), process journal, presentation	Docs + journal graded async; presentation graded live at team meetings

Repos are private copies of the course’s idlelib/OpenRefine template repos, created with Use this template inside the course GitHub org.

This is one PR per assignment, not two. You open it at the initial PR deadline and push new commits to it as you address review comments; “final PR due” is the deadline for those commits, not a second pull request. There is no resubmission after grading. Your tutor grades the final version of your PR, after you have addressed the code review: you reply to every comment and update your work by the final PR deadline. Whether you acted on the feedback is also part of your collaboration grade. Your tutor sets who reviews whom. It changes with each assignment. Each pair reviews 2 other pairs’ work, and each pair gets 2 code reviews from 2 other pairs. Late work is not accepted. Each deadline stands on its own. Missing one does not make the whole assignment late. The rules for each stage are below. See Assignments for every date.

If your pair misses the initial PR deadline. Your pair is out of the peer review process for that assignment, both giving and receiving. You do not see other pairs’ code and they do not see yours. This keeps anyone from copying code they saw in a review. Your pair can still work on the assignment and submit at the final PR deadline. You can earn Technical and Communication from it, but your Collaboration score for that assignment is 0 (No evidence). There is no grace period, so put your best work in the initial PR.

Collaboration on an assignment has two parts: giving your 2 reviews, and addressing the review comments on your own PR. If your pair misses the review deadline but addresses the comments on your own PR, your Collaboration score for that assignment is capped at 1 (Beginning). If your pair gives the reviews but does not address the comments, it is capped at 2 (Developing). If your pair does neither, it is 0 (No evidence).

If your pair does not submit a final PR. Your tutor grades your initial PR as the final version, and your Technical score for that assignment is capped at 2 (Developing). If you also missed the initial PR, your Technical score is 0 (No evidence). Your Collaboration score follows the two-part rule above. Not addressing the review comments is a Collaboration matter, not a Technical one. If you submit a final PR on time but do not address the comments, your Technical score is not capped, and your Collaboration score follows the two-part rule.

If you miss a presentation. This covers the presentation for each of the 3 assignments and the Group Project checkpoint. You can make up one of these presentations during the quarter, with your tutor. Your Communication score for that presentation is capped at 2 (Developing), whether or not the absence was excused. If you miss any other presentation, your Communication score for it is No evidence, which is 0. The rest of your pair or group is not affected.

In short (“initial PR” and “final PR” are the same pull request at two deadlines, not two PRs). Technical, Collaboration, and Communication are scored independently, so a row in one table does not override a row in another: a pair can land in one row of each of the three tables at once for the same assignment.

Technical:

If your pair…	Technical
Submits a final PR	Not capped, graded normally, whether or not the review comments were addressed.
Does not submit a final PR, but submitted the initial PR	Capped at 2 (Developing), graded on the initial PR.
Submits neither the initial nor the final PR	0 (No evidence).

Not submitting a final PR means the comments went unaddressed too, so it also triggers a row in the Collaboration table below: “gives the reviews but does not address the comments” if your pair gave its 2 reviews, or “does neither” if it did not.

Collaboration:

If your pair…	Collaboration
Misses the initial PR	0 (No evidence). Out of peer review, giving and receiving.
Gives the reviews and addresses the comments	Not capped, graded normally.
Misses the reviews but addresses the comments on your own PR	Capped at 1 (Beginning).
Gives the reviews but does not address the comments	Capped at 2 (Developing).
Does neither	0 (No evidence).

Communication (presentations):

If your pair…	Communication
Misses a presentation (the first one)	Capped at 2 (Developing), with a make-up from your tutor, excused or not.
Misses any other presentation	0 (No evidence).

1a. Group Project (graded as part of Assignments, weighted 2×)

Small groups, tutor-assigned, within your team. Tied to the agentic half only (OpenRefine, Weeks 6-10). It is a bigger project than A3, and the group has to split the work and merge it. Counts as two 1×-weighted parts within the Assignments category (2× in total): the checkpoint presentation, and the final PR and final presentation together.

The project is released on Fri 11/6 (Week 6).
Your group hands in a proposal (due Fri 11/13) and then starts on the project. Your tutor gives feedback on your scope at the checkpoint presentation and may ask you to adjust it. See Assignments for the dates.
Checkpoint presentation: Week 9, at your team meeting, about 10 minutes per group. Show your progress, your plan, and how you used agents. Every member presents part of it. Your tutor gives you feedback on your scope. Your tutor also sees your group at every team meeting.
Final code (PR): due Wed 12/9, graded async from the repo.
Final presentation: Week 11, during the 3-hour final exam slot (Thu 12/10, 3:00-5:59pm, FAH 1450). Groups present one after another. Each group gives a presentation, then answers questions from the instructor and the audience. The exact schedule is posted once groups are set.

If a member misses the checkpoint presentation. The group presents on time. The absence uses the member’s one presentation make-up (see Assignments). If a member misses the final presentation, their Communication score for that part is No evidence. There are no exceptions. Individual grading applies to the whole Group Project: every part is scored per student, and your tutor uses your commit history and your own presentation to score you.

2. Assessments (Skill Demonstrations)

There are two skill demonstrations, each covering all three competencies. You’ll be randomly paired with someone from your team for each one (it’s fine if you end up with your assignment partner, or someone you’ve worked with before).

Midterm Skill Demo: Week 6, during team meeting. Traditional half (idlelib). No AI/agentic tools.
Final Skill Demo: Week 10, during team meeting. Agentic half (OpenRefine). AI/agentic tools expected.

Format: a 2-hour session built around the same scoped task as your partner, worked independently:

5 min: Setup.
40 min: Individual work. You and your partner work the same task on your own and each submit your own PR. (Technical)
40 min: Peer review. You review your partner’s PR in writing. (Collaboration)
30 min: Documentation. You answer a set of specific questions about your own work, in writing and diagrams, on paper. (Communication)
5 min: Teardown.

Throughout the session, your tutor walks around and asks each of you 1-2 questions about your own work. There is no separate time set aside for this and no live presentation, it happens informally as the tutor circulates. This is also evidence for Communication, and it’s the check that you, not your partner or an agent, can explain your own work.

Grading: scored per competency using the same four levels as Assignments (No evidence=0, Beginning=1, Developing=2, Proficient=3). See How work is graded under Grading.

If your partner does not show: your own Technical and Communication work are not affected, since you already work independently. Your tutor will pair you with someone else for the review step. If no one is available, your tutor will do the review with you. Your Collaboration score will not be lowered. Assessments is always out of 18, so a partner’s no-show never lowers your score or changes your grade thresholds.

If you miss a skill demo: you are not advised to take this class if you cannot attend the skill demos at your scheduled team meeting time. If you miss a skill demo because of extenuating circumstances, do the following. First, contact your college dean and request an alternative skill demo. The dean verifies your documentation and contacts the instructor if they recommend a make-up. Second, if the dean approves and contacts the instructor, you make up the skill demo by scheduling a 2-hour, in-person oral exam with the instructor. In the exam, you work with the instructor on the large codebase. If you miss a skill demo and do not get an approved make-up, you receive a 0 for that skill demo.

(Midterm and final skill demo scores each count on their own. There is no exam replacement policy.)

One of the important skills for a successful programmer is the ability to work effectively with other people. This matters even more in the era of GenAI, as ChatGPT is eroding student learning communities. Research with software engineers, academics, and students warns that if everyone works alone with their own AI, we risk graduates who are strong at individual tasks but struggle with shared vision, decision-making, and teamwork. Communicating and collaborating with real people is a core part of software engineering, and this course gives you regular time to practice it. In this course, you will have many chances to work with other students and course staff on software engineering problems.

Learning (in college) is, in part, a social process. Your engagement with it is part of your grade for the class. See Grading below for how it counts.

These are the opportunities for social learning in this course:

Lectures. Lectures are interactive, with many in-class activities for you to complete. At the start of each lecture there is a handout to complete during the lecture. You must submit it at the end of the lecture through Gradescope to earn credit for attending.
Team meetings. Every student belongs to a team with a tutor. Your team stays the same all quarter and meets for 2 hours each week, for all 10 weeks. This is where you present your assignments and your Group Project checkpoint, talk through feedback with your tutor, and do the skill demos. Presentations and demos happen at your team meeting during the week shown on the Course Calendar. Your tutor records your participation.

Missing a team meeting. Updated: 10/3/2026. Missing a team meeting costs that week’s 1 Social Learning point, whether or not the absence is excused. There are no make-ups. You may not attend another team’s meeting instead. This is because you work with the same team and tutor all quarter, and your assignment pair is inside your team. Team meetings are where your tutor and teammates get to know you and your work, so a meeting with a different team does not do that. If you miss a meeting, ask a teammate or your tutor to catch you up. The grade thresholds leave room for a few missed points. For example, the A level in Social Learning is 26 of 30.

Grading

There are three grading categories, each with its own minimum threshold. Falling short in any one category caps your grade, regardless of your standing in the others.

How work is graded

Grading in this course is based on clear standards, not on counting up lost points. This is called specifications grading. Every assignment, both parts of the Group Project, and each Skill Demo is graded on the three competencies: technical, collaboration, and communication. For each competency you get one of four levels, and you can see what each level looks like before you start:

Level	Points	Technical	Collaboration	Communication
No evidence	0	Nothing to assess: not submitted, not attempted, or missed.	Nothing to assess: not submitted, not attempted, or missed.	Nothing to assess: not submitted, not attempted, or missed.
Beginning	1	Needs step-by-step help to navigate and change unfamiliar code. Does not check whether a fix or an agent’s code really works.	Rarely reviews others’ or an agent’s work critically. Changes do not match existing conventions. Stalls or guesses when requirements are unclear.	PR descriptions and commit messages say only what changed. The journal is sparse or written after the fact. Cannot explain a tradeoff or an agent’s reasoning in your own words.
Developing	2	Navigates and changes code with some guidance. Sometimes trusts passing tests or agent output without checking that they test the right thing.	Gives review feedback, mostly on surface issues like style. Matches conventions when shown an example. Often asks a person before checking docs and history.	Explains what changed and sometimes why. Documents decisions when reminded. Explanations are imprecise.
Proficient	3	Works independently in unfamiliar code, thinks about what a change could break first, and checks that a fix (yours or an agent’s) addresses the root cause.	Gives substantive review feedback on correctness, scope, and conventions. Matches conventions without prompting. Checks docs and history first, then asks focused questions.	Consistently explains why a change was made. The journal captures your reasoning as it happens. Explains tradeoffs and agent-made work clearly to a reviewer.

What Proficient means. Proficient is the top level and full marks for a competency. It is the standard we expect from a developer who is new to a codebase: works independently, checks their own and an agent’s work, and communicates clearly. It does not mean flawless, it means reliably doing the job well.

No evidence. If there is nothing to assess for a competency, it is marked No evidence and counts as 0 points, the lowest score. Beginning (1 point) means the work was there and showed those behaviors. No evidence means there was nothing to look at. This happens when you do not submit an assignment, you miss a skill demo, or one piece is missing, such as a peer review you did not write. If only one piece is missing, only that competency is marked No evidence. The others are graded as usual.

The three competency scores add up into one 0-9 score for that item. The point totals below add those scores up. For example, if every competency on every assignment item is Developing (2 points), you have 30 of 45 points, which meets the B threshold for Assignments.

Where the evidence comes from. On assignments, your tutor looks at your repo: your PR, your commit history, the code review comments you write and answer, your documentation and journal, and your presentation. On Skill Demos, your tutor looks at what you produce and say during the session: your own PR, the review you write of your partner’s PR, your written documentation, and what you say when your tutor asks you about your own work.

Assignments (45 points max):

Each of the 3 pair assignments is scored on technical, collaboration, and communication (0-3 each, added together), weight 1×, up to 9 points each (27 points total)
The Group Project has two parts, the checkpoint presentation and the final PR and presentation. Each part is scored the same way (0-9) with weight 1×, so the Group Project is 2× in total, up to 18 points
Total: 45 points max

Assessments (18 points max):

Each of the 2 skill demos is scored on technical, collaboration, and communication (0-3 each, added together), up to 9 points each, 18 points max

Social Learning (30 points max):

Each week (Weeks 1-10) you can earn up to 3 points: 1 point for each of that week’s two lecture handouts, plus 1 point for team meeting participation. Over 10 weeks, that is 30 points max.
Lecture 0 (Week 0, before team meetings start) does not carry a Social Learning point.
There is no lecture on Thursday 11/26 (Thanksgiving). Everyone automatically earns that handout point.

Letter grade thresholds: to earn a letter grade, you show that level of achievement in all three categories:

Grade	Assignments (≥)	Assessments (≥)	Social Learning (≥)
A	36/45	15/18	25/30
B	30/45	12/18	20/30
C	21/45	9/18	15/30
F	Below the C threshold in any category

Your grade reflects your achievement in all three categories, not an average of the three. Two examples:

You reach the A level on Assignments (38/45) and Social Learning (26/30), and the B level on Assessments (13/18). Your overall grade is B. Earning an A means showing A-level achievement in all three categories, not just two.
You reach the A level on Assignments (42/45) and Assessments (16/18), but only 10/30 on Social Learning, which is below the C level (15/30). Your overall grade is F. Earning any letter grade means showing that level of achievement in all three categories.

Collaboration Policy

In CSE 190 we believe that learning is a collaborative and social process. Real software is built by teams, and this course is set up so you work with others in every part of it. This policy explains who you work with, and where the lines are.

General guidelines

Collaboration is encouraged. Talk through problems with your classmates. Explaining an idea to someone else is one of the best ways to learn it.
Ask for help. Tutors and the instructor are here to help. The goal is to learn, not just to find an answer. Make sure you understand anything you submit.
Online resources are allowed as long as you understand what you use and can explain it. Cite or link to anything substantial that you borrow.
Your team is your community. Help each other at team meetings, share what you learn about the codebase, and give honest feedback.

Who you work with, by component

Component	Who you work with	What that means
Assignments	Your self-chosen partner	You and your partner submit one shared piece of work. You are both responsible for all of it.
Group Project	Your tutor-assigned group	The group submits one shared project. Every member contributes and every member is responsible for the whole.
Skill Demos	Your randomly assigned partner, for that demo only	You work only with your partner. No help from anyone else while the demo is in progress.
Lecture handouts and team meetings	Your team and your tutor	Participate and help each other. Do not submit a handout for a lecture you did not attend.

Working with your partner or group

Both people do the work. Split up tasks if you like, but you should both understand everything you submit, including the parts your partner wrote. Pair programming and reviewing each other’s code are encouraged.
Your commit history should show it. We look at the repo to see that each person contributed. One person doing everything while the other only approves is not collaboration.
Be a good teammate. Reply to messages, show up to meetings, and do your share on time.
Tell your tutor early if something is not working. If a partner is not contributing or you are not able to work together, talk to your tutor as soon as you notice. Do not wait until the deadline.

Working with other pairs and groups

You may discuss ideas, approaches, and how the codebase works with people outside your pair or group. Do not share or copy code, and do not use another pair’s repo. Your pair’s submission should be your pair’s work.

Skill demos

Skill demos are paired, but each of you is graded on your own.

Work only with your assigned partner. Do not get help from other pairs or from people outside the room.
You and your partner each work the whole task on your own. Your tutor asks each of you questions about your own work, and you review your partner’s PR. Understand the whole task.
The code review of your partner’s work is graded from your repo, so review honestly.
The tool rules are different for each demo. The midterm allows no AI tools. The final expects them. See the AI / LLM Policy.

Getting help from course staff

Staff can answer questions, point you to the right part of the codebase, and give feedback on your approach. Staff will not write your solution for you.

AI / LLM Policy

Experts can write code faster with the help of AI tools. But they did not become experts by using them.

Think about running for fitness. An electric scooter gets you to the finish faster and with less effort. But it misses the point of the run. The goal is the change in your body, not the destination.

In this course, programming is running for fitness. In the first half, you build your core skills by hand: reading, changing, debugging, and testing code. In the second half, you learn to use agentic AI tools the way professionals do. You can only do that well if you can tell when the tool is wrong, and that takes the skills from the first half.

Part 1: idlelib (A1, A2, and the Midterm Skill Demo)

Chat tools for documentation only. Web chat tools (ChatGPT, Gemini, and similar) are allowed as an easy way to look up documentation. For example, ask how a Python feature works, or for a tkinter tutorial. You may also ask a chat tool to explain existing IDLE code you are reading. Do not use them to plan, write, fix, or review your code changes on A1 or A2. Doing the change yourself is the point of these assignments.
No agentic or IDE-based AI tools. Do not use GitHub Copilot, Claude Code, Codex, Cursor, or similar tools on A1 or A2. Agentic tools start with A3, which is released in Week 6.
Midterm Skill Demo (Week 6): no AI tools of any kind. This holds even though agentic tools are expected on A3 that same week.

Part 2: OpenRefine (A3, the Group Project, and the Final Skill Demo)

Agentic tools are expected. We teach them in lecture and you use them on A3 and the Group Project.
Tell us how you used them. In your process journal and PR descriptions, note where you used AI, what you asked it to do, and how you checked its output.
You own the result. Code from an agent is your code once you submit it. You are responsible for whether it is correct and whether it fits the codebase.
Final Skill Demo: AI tools are expected.

All quarter

Your journal and your reviews are in your own words. Write your process journal and your peer code review comments yourself. Explaining or reviewing an agent’s work in your own words is a skill we grade.
Understand what you submit. If you cannot explain it, it does not count, even if it works.
Follow the rule for the task. If a task or demo says no AI, that means no AI.

Summary

Activity	Part 1: idlelib (A1, A2)	Part 2: OpenRefine (A3, Group Project)
Assignments and Group Project	Chat tools for documentation questions only. No help with code changes. No agentic or IDE tools.	Agentic tools expected. Disclose how you used them.
Skill Demo	Midterm (Week 6): no AI	Final (Week 10): AI expected
Process journal and peer review comments	Your own words	Your own words

If we have concerns

We do not punish you for using AI where the policy allows it. The concern is work you do not understand. If we think you cannot explain something you submitted, your tutor or the instructor may invite you to a 1-on-1 meeting to walk through it. If you cannot explain your work, the matter may be referred to the Academic Integrity Office. Using AI where the policy does not allow it can also be referred.

Academic Integrity

Our course is built on collaboration. You work with a partner or a group on almost everything, and we encourage you to learn from your classmates. The goal is for everyone to master the material.

The most important rule in this class is that you must be able to explain any work you submit. You can get help from classmates, tutors, online resources, and AI tools where the AI policy allows them. But submitting something you do not understand is a violation of academic integrity. The purpose of the work is to help you learn. Copying an answer that you cannot explain, from a person or from an AI tool, defeats that purpose.

If we have concerns that you do not understand work you submitted, the instructor or your tutor may invite you to a 1-on-1 meeting to discuss it and the concepts behind it. If you are unable to explain your work, the matter will be referred to the Academic Integrity Office.

What counts as a violation

Submitting work you cannot explain.
Sharing or copying code between pairs or groups, or using another pair’s repo. See the Collaboration Policy.
Getting help from anyone other than your partner during a skill demo.
Using AI tools where the AI policy does not allow them. This includes any AI on the midterm skill demo, and agentic or IDE-based tools on A1 or A2.
Misreporting how you used AI, or who did the work. Describe your AI use honestly on A3 and the Group Project, and do not claim work that your partner or group did.
Sharing a lecture handout with students who did not attend the lecture, or submitting a lecture handout without attending the lecture.

If a rule is not clear to you, ask before you act. It is much easier to ask first.

Technology Policy

Lecture is a communal space where your screen choices impact a “cone of attention” behind you. Research shows that off-topic visuals can detrimentally affect the learning of everyone in your field of view. Therefore, any technology used in class must directly support the current activity, such as accessing slides or taking notes.

Use of technology for any activity not directly related to what is going on in class is strictly prohibited. This includes, but is not limited to, the following:

Texting/instagram/tiktok/etc.
Playing games
Web surfing
Watching videos
Doing homework (including for CSE 190) or engaging in work for other classes

Students who persistently use technology for reasons other than those directly related to class activities will be politely asked to leave the classroom to protect the collective focus of the community.

Resources for Students

Getting Help

We expect that all students will need help at some point during the quarter. Many resources are available including team meetings, instructor office hours (posted on the course website), as well as the course discussion board (Ed discussion).

Classroom Community

Every student in this course should be able to focus on learning without distraction or discomfort. Our goal is a classroom where all students are treated with respect and have an equal opportunity to succeed.

Our instructional staff is committed to being approachable and supportive to every student in this course. If something is making it harder for you to participate or feel comfortable in class, let a member of the course staff know: in person, by email, or on the discussion board.

We also expect you, as a student in this course, to treat your classmates with respect, consistent with the UCSD Principles of Community. If you experience harassment or discrimination, please contact the instructor as soon as possible. If you’d rather speak with someone outside the course, you can contact the Office for the Prevention of Harassment and Discrimination.

Students with Disabilities

We aim to create an environment in which all students can succeed in this course. If you have a disability, please contact the Office for Students with Disability (OSD), to discuss appropriate accommodations right away. Students requesting accommodations for this course due to a disability must provide a current Authorization for Accommodation (AFA) letter (paper or electronic) issued by the Office for Students with Disabilities. Students are required to discuss accommodation arrangements with instructors and OSD liaisons in the department IN ADVANCE of any exams or homework assignments. Please note that existing course structures may be used to satisfy accommodations when they meet the accommodation requirements.

Basic Needs/Food Insecurities

If you are skipping and stretching meals, or having difficulties affording or accessing food, you may be eligible for CalFresh, California’s Supplemental Nutrition Assistance Program, that can provide up to $292 a month in free money on a debit card to buy food. Students can apply at benefitscal.com/r/ucsandiegocalfresh.

The Hub Basic Needs Center empowers all students by connecting them to resources for food, stable housing and financial literacy. Visit their site at basicneeds.ucsd.edu.

Acknowledgements

The human-centered approach to working with large codebases that we use in our course is largely inspired by the following research papers:

Maria Kallia. 2025. To Be, or to Be Otherwise? Silicon Souls in Search of Dasein and Authentic Human Engagement in the Age of Generative AI. In Proceedings of the 2025 ACM Conference on International Computing Education Research V.1 (ICER ‘25). ACM, New York, NY, USA, 240–255. https://doi.org/10.1145/3702652.3744223

Irene Hou, Owen Man, Kate Hamilton, Srishty Muthusekaran, Jeffin Johnykutty, Leili Zadeh, and Stephen MacNeil. 2025. ‘All Roads Lead to ChatGPT’: How Generative AI is Eroding Social Interactions and Student Learning Communities. In Proceedings of the 30th ACM Conference on Innovation and Technology in Computer Science Education V.1 (ITiCSE 2025). ACM, New York, NY, USA, 79–85. https://doi.org/10.1145/3724363.3729024

Anshul Shah, Thomas Rexin, Anya Chernova, Gonzalo Allen-Perez, William G. Griswold, and Adalbert Gerald Soosai Raj. 2025. Needles in a Haystack: Student Struggles with Working on Large Code Bases. In Proceedings of the 2025 ACM Conference on International Computing Education Research V.1 (ICER ‘25). ACM, New York, NY, USA, 27–40. https://doi.org/10.1145/3702652.3744218