CS357: Foundations of Artificial Intelligence - The Reflection Notebook (10 Points)

Assignment Goals

The goals of this assignment are:

1. To think through not just how to build agents but whether and when we should
2. To collect and develop the reflections that close each activity, lab, and milestone
3. To track your thinking against the four Ursinus Open Questions across the term

The Assignment

This course asks two kinds of question at once: the technical one — how do you build and run this? — and the human one — should you, and for whom, and at what cost? The engineers who matter are the ones who hold both at the same time. Your Reflection Notebook is where you practice that. It is graded as the Reflection Notebook category (10% of the course grade) via the midterm and end-of-term reviews; individual entries carry no per-item points. It rewards genuine engagement over polish.

Purpose

The notebook turns the reflecting you are already asked to do — at the end of every activity, lab, and Project-Thread milestone — into a connected record of how your thinking is developing, technically and ethically. Kept honestly, it is both a study resource in your own words and the evidence of the arc this course is built around: from someone who uses AI tools to someone who can build, operate, and reason responsibly about AI systems.

Keyed to the Ursinus Open Questions

Your entries are organized around the four Open Questions that run through the whole course. Return to them as the material gives you new ways to answer:

• What should matter to me? — What do you actually value in a system you would deploy: capability, privacy, cost, control, transparency? Where have those values collided this term?
• How should we live together? — Who is affected by the agents we build, and who decides? Where does responsibility sit when an autonomous system errs?
• How can we understand the world? — What did a by-hand calculation, a broken pipeline, or a failed evaluation teach you that the abstraction hid?
• What will I do? — Given what you now know about how these systems work and fail, what will you build, refuse to build, or build differently? For your final entry, one strong way to answer is to polish the drafted project post from the ShipIt checklist: the problem, what you built, one number, what you learned — whether or not you ever publish it, writing it makes the claim concrete.

What Goes In It

• Activity, lab, and milestone reflections. Each closes with a reflection prompt keyed to an Open Question; answer it here in a few sentences.
• Reading-response stuck points. When a reading response or a setup step fought you, note where and why — the failures are where the real understanding is.
• AI-use disclosures. This course expects disclosure of your AI tool use; your notebook is a natural place to keep that running record and to reflect on what the tools did and did not do for your learning. Note that each major deliverable’s reflection includes an AI-use disclosure — how and why AI tools were used — so the notebook accumulates that record deliverable by deliverable.
• Cross-thread connections. The most valuable entries link the technical and the ethical: a sentence noticing that a design choice you made for cost or capability was also an ethical choice.

Project-Stage Prompts: The Team Itself

The Project Thread will ask you, at three points in the semester, to turn the notebook’s lens on your team rather than your code. Answer these when the stage arrives:

• After the charter (wk2): Re-read the norms your team just signed. Which one will be hardest for you personally to keep — and what does it cost you to keep it?
• Mid-project (around the wk8.0 charter revisit): Describe one moment of productive disagreement on your team — how it surfaced, and how the team moved through it. If you cannot name one, ask yourself honestly whether that is harmony or avoidance.
• After Demo Day (adjourning, in Tuckman’s terms): What did this team teach you about how you collaborate? What will you do differently on your next team — and what will you bring to it on day one?

Format, Cadence, and Evaluation

Keep it however you will actually keep it — a paper notebook, a running document, or a Markdown file in a repository — as long as it is continuous and yours, not reconstructed the night before review. It is reviewed informally at midterm and again at the end of the term; skim it yourself first each time and write a two-sentence summary of what it shows about your growth.

It is assessed on engagement, not correctness or length. A strong notebook is consistent (entries across the term), honest (it names real uncertainty), connective (it links the technical and the ethical, and ties back to the Open Questions), and reflective (it says what changed in your thinking). An entry that says “I assumed local models were strictly worse until this lab, and here is the tradeoff I now see” is worth more than a page of correct summary.

See also

• Preparing for Each Class — the routine and the participation rubric.
• Reading Responses — a steady source of notebook material.

Submission

Kept all semester in a notebook or a repository of your choice; reviewed at midterm and at the end of the term. Its quality is the 10% Reflection Notebook grade.

Please refer to the Style Guide for code quality examples and guidelines.