CS357: Foundations of Artificial Intelligence - Overview (100 Points)

Purpose, Task, and Criteria

Purpose: To get your local AI stack and your coding agent working before the labs depend on them, capture a baseline snapshot of your thinking about AI that you will revisit at the end of the semester, and launch your team.

Task: Install and verify a working local AI environment and coding agent, and write a short baseline reflection on AI agency and trust.

Criteria: I grade this on a complete setup-verification transcript and a specific, personal reflection in equal measure. Please read the rubric below for the details.

Assignment Goals

The goals of this assignment are:
  1. To install and verify a working local AI environment including Ollama, a pulled model, a Python API call, and a coding agent answering from that same local model
  2. To demonstrate baseline command-line, git, and Python-environment fluency by navigating a shell, cloning and committing to a repository, and creating a reproducible environment with uv
  3. To articulate personal baseline beliefs about AI agency, trust, and delegation with specific examples

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

In this warmup you’ll install your local AI stack and your coding agent, and write a short baseline reflection on your experiences with AI. I have kept the stakes low here on purpose. It exists to make sure your tools work before the labs depend on them, and to capture a snapshot of your thinking that you’ll come back to at the end of the semester. (Your team charter is not part of this assignment; it is handed out separately once teams are announced; see the Project Thread.) There are no wrong answers in the reflection. This is a starting point, and I am not evaluating what you know. See the course schedule for this onboarding assignment’s due date; it is assessed within the Class Activities and Participation category.


Before You Start

Added after this assignment went out: Step 5 of Part 1, the coding-agent check, and its checklist item. It is one command and one prompt, and the Week 2 lab depends on it, which is why it is here rather than discovered later. It follows the same failure policy as everything else on this page: a documented failure, with the verbatim error and what you tried, earns full credit for that step.

Also added after this assignment went out: three setup notes that cost students time in the first week. Windows users should work in PowerShell rather than the old Command Prompt (Before You Start), the Python requests library has to be installed before the Route B script will run (Part 1, Route B, step 4), and GitHub Desktop is a supported way to do the git step (Part 1.5, step 2). None of them changes what you turn in.

Also added after this assignment went out: step 5 of Part 1 now names opencode.ai and lists the install options, both the command-line version and the desktop app. Route A is unchanged, because the course image already ships the agent, and what you turn in is the same.

Reorganized after this assignment went out (Sep 5): Part 1 is now split into Part 1A (the Ollama stack, steps 1-4) and Part 1B (the coding agent, step 5), each with its own checklist, and the route choice is stated once up front. Nothing was added to what you turn in, and nothing was removed. The same five steps are graded by the same rubric; they are just no longer interleaved. If you already started against the old layout, your work still counts as-is. One genuinely new item appears at the end of Part 1B, an optional herdr install, which is explicitly not graded.

This is the first thing you install for this course. I have put it early on purpose, so that a broken setup costs you this assignment rather than a lab.

Pace yourself: most of this is downloading. The model pull alone is about 2 GB, and the container image is larger. Please start the downloads on good wifi and write the reflection while they run. Don’t leave this for the night before; the downloads will not go any faster because you are in a hurry, and I can’t help you at 11 PM.

You need: a laptop you can install software on, a GitHub account, and about 10 GB free disk. On Windows, use PowerShell (Windows 10 and 11 include it; open it from the Start menu) rather than the old Command Prompt, because every command on this page and in the labs is written for PowerShell or a Unix shell; WSL2 Ubuntu, which the Docker route sets up, is the other supported choice. If any of those is a problem, please say so this week rather than in week four. There is a lab-machine route, and it takes some scheduling.

Do it in this order:

  1. Start the Ollama download (Part 1). It runs in the background.
  2. While it downloads, write the baseline reflection (Part 2). It needs no tools.
  3. Come back and finish the setup transcript.
  4. Do the command-line and git checkpoint (Part 1.5) last, since it uses what you just installed.

Two routes, and I support both. Route A (host Ollama plus the course container) is the one I recommend; Route B (native install) is complete and supported too. Neither route is the “real” one, and Part 1 below explains how to choose and what changes.

You’ve succeeded when the four boxes in the Part 1A checklist and the three in the Part 1B checklist are checked, all three in the Part 1.5 checklist are checked, and your reflection has four labeled sections. If a step failed, a documented failure with the verbatim error and what you tried earns full credit for that step; a vague “it worked eventually” does not.


What a Strong Submission Looks Like

A strong submission has these qualities:

  1. The transcript is complete and honest. It shows the actual terminal output (version numbers, model names, the API response), copied faithfully. If something broke, quote the error verbatim and tell me what you tried. I won’t give credit for a fabricated or paraphrased transcript.
  2. The reflection is personal and specific. It names a real AI tool you used, describes a real moment of surprise or confusion, and takes an actual position on agency and trust. I am not looking for a dictionary definition or a summary of the syllabus. A strong reflection reads like a journal entry from someone thinking carefully.

A weak submission has a transcript that says “it worked” without showing output and a reflection that restates prompts without answering them.


Part 1: Tool Setup

Part 1 has two halves, and you do both of them:

  What you stand up Steps What the transcript shows
Part 1A The local model stack: Ollama, a pulled model, the REST API, and a Python call against it Steps 1-4 Four pieces of terminal output
Part 1B The coding agent: opencode, talking to that same local model Step 5 A version string and one answered prompt

Part 1A has to work before Part 1B can: the coding agent in Part 1B is pointed at the model you pull in Part 1A, so do them in order.

First pick a route, which decides where those five steps run. The steps are the same on both routes, and neither route is the “real” one.

Choose Your Route

Set up the full course environment by following the Development Environment activity: Ollama installs natively on your host exactly as in Route B, and the rest of the semester’s toolchain lives in one course Docker container bind-mounted onto a cs357-work GitHub repository you create in the activity.

On this route, run steps 1-3 on your host as written, and run steps 4 and 5 (the Python request and the coding-agent check) from inside the container, replacing localhost with host.docker.internal in the URL. A verification transcript captured from inside the container is fully accepted; include the container prompt in your copy-paste so it is visible where each command ran, along with the activity’s own container verification output (the /api/tags one-liner, promptfoo --version, and the spacy model check).

Route B: native install

Install Ollama on your own machine (or a lab machine if yours cannot run it; ask the instructor if you are unsure which to use), then run all five steps on that machine.

Route A is the one I recommend, because every later lab assumes it and it is what we build together in the Your AI Workbench session. Route B is complete and supported too, so take it if Docker will not run on your machine, and please say so in your transcript.


Part 1A: The Local Model Stack (Steps 1-4)

Complete each step and capture the output.

Step 1. Install Ollama, pull a small model, and confirm both.

ollama --version
ollama pull llama3.2
ollama list

ollama list should show llama3.2 once the pull finishes. This is the step that takes the longest; the model is about 2 GB.

Step 2. Run a CLI sanity check.

ollama run llama3.2 "Say hello in five words."

Step 3. Verify the REST API responds.

curl http://localhost:11434/api/tags

On Route A, run steps 1-3 on your host. From inside the container, this URL becomes http://host.docker.internal:11434/api/tags.

Step 4. Call the model from Python.

First install the requests library into the Python you will actually run:

pip install requests

On Windows, in PowerShell, that is python -m pip install requests. If you take the uv route in Part 1.5, uv add requests does the same job inside that environment, but this install is what makes the step below run on a fresh machine.

Then send one chat request and print the response. Your script should look roughly like this:

import requests, json

response = requests.post(
    "http://localhost:11434/api/chat",
    json={
        "model": "llama3.2",
        "messages": [{"role": "user", "content": "What is 2 + 2?"}],
        "stream": False
    }
)
print(json.dumps(response.json(), indent=2))

On Route A, run this from inside the container, with host.docker.internal in place of localhost.

Part 1A Checklist

  • ollama --version returns a version string
  • ollama list shows at least one downloaded model
  • The curl command to /api/tags returns JSON (not a connection error)
  • Your Python script prints a response that includes a "content" field

Part 1B: Your Coding Agent (Step 5)

Step 5. Confirm your coding agent is installed and talking to that same local model.

The agent is opencode, and every install route lives at opencode.ai.

Installing it:

  • On Route A, it is already in the course image, so there is nothing to install.
  • On Route B, install it yourself: curl -fsSL https://opencode.ai/install | bash on macOS, Linux, or WSL; npm i -g opencode-ai if you already have Node.js; or choco install opencode or scoop install opencode in PowerShell on native Windows.

That page also offers a desktop app, in beta for macOS, Windows, and Linux, if you would rather work in a window than a terminal. It drives the same agent, but install the command-line version even if you try the desktop one, because this assignment and every lab ask for terminal output.

Development Environment activity Step 8 walks through all of it, including pointing the agent at your Ollama model.

Verifying it:

opencode --version

Then start opencode, type /model, and confirm your Ollama provider is listed. Ask it one question (“what files are in this directory?” is enough) and paste the answer.

If the provider list is empty, check the configuration file name first: it is opencode.json, never config.json, and opencode silently ignores a file with the wrong name.

Part 1B Checklist

  • opencode --version returns a version string
  • /model lists your Ollama provider
  • The agent answered one prompt from your local model

Optional: install herdr while you are here

This is not graded and is not on the checklist above. It is here because installing it now costs one command, and a later lab assumes it is on your bench.

herdr is an agent-aware terminal multiplexer. It keeps agents running after you close your laptop or drop an SSH connection, and it shows you which agent is blocked, working, or done, so you are not cycling through terminal panes to find the one waiting on you.

  • Route A: already in the course image, alongside opencode. Confirm with herdr --version.
  • Route B (macOS, Linux, WSL): curl -fsSL https://herdr.dev/install.sh | sh
  • Route B (macOS, Homebrew): brew install herdr
  • Route B (native Windows): powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"

The installer downloads one binary, checks its SHA-256, and puts it in ~/.local/bin. If you include herdr --version in your transcript, I will read it, but its absence costs you nothing.


Capturing Part 1

Copy-paste or screenshot the output of all five steps, including the output of ollama --version and your operating system name and version.

If any step fails: document the error message verbatim, state your hypothesis about the cause, and describe what you tried. A well-documented failure with a follow-up plan earns full credit for that step. Do not delete error output or write “it eventually worked” without showing what changed.


Part 1.5: Command-Line and Git Checkpoint

Every lab this semester runs from a terminal, lives in a git repository, and depends on a reproducible Python environment. This checkpoint makes sure those underlying tools work before the labs depend on them, the same philosophy as the Ollama setup above. You do not need to be a shell wizard; you need to be able to move around, version your work, and stand up an environment without guesswork. If any command below is unfamiliar, the Command-Line Survival resources at the end of this section will get you there.

Container-route note (Route A): perform the git steps of this checkpoint from inside the course container, against the cs357-work GitHub repository you created in the Development Environment activity; the activity’s practice section (create hello_agent.py, run it against host Ollama, commit, push) is exactly this checkpoint, so its transcript satisfies the navigation and git items below. The uv step still runs on your host (the container image already bundles the course packages; uv is your reproducible-environment tool for the native route and anywhere outside the container).

Complete each step and capture the terminal output:

  1. Navigate. From a terminal, create a working directory for this course, enter it, and list its contents: mkdir -p ~/cs357 && cd ~/cs357 && pwd && ls -la. Then use one search tool, grep (or ripgrep/rg if installed), to find a string in a file, and paste the command you ran.
  2. Version control. Create a small git repository, make a commit, and connect it to a remote (your course GitHub Classroom repo, or a throwaway GitHub repo): git init, add a file, git add, git commit -m "first commit", then git remote add origin <url> and git push -u origin main. Paste the transcript of git log --oneline showing your commit. If you would rather not type git commands yet, GitHub Desktop is a supported option: install it, sign in, use File > New repository (or Add local repository) on your cs357 folder, commit from the Changes tab, and Publish repository to push. Then paste the output of git log --oneline from Repository > Open in terminal, which is the same transcript the command-line route produces.
  3. Reproducible Python with uv. Install uv (the fast, modern Python environment manager we standardize on this term). Create and activate a project environment and add the one dependency the labs start with: uv venv, then uv add requests, then uv run python -c "import requests; print(requests.__version__)". Paste the output. (If you cannot install uv, fall back to python -m venv and pip install requests, and note in your submission that you used the fallback.)

Command-Line Survival: reference (use as needed, not required reading cover-to-cover)

  • tldr pages: plain-language example-first cheat sheets for any command (tldr tar).
  • explainshell: paste any command line and see each flag explained.
  • ShellCheck: catches bugs in shell scripts before they bite.
  • curl and HTTPie plus jq: you will hit JSON APIs (Ollama, MCP) all semester; curl ... | jq is your friend.

Part 1.5 Checklist

  • A shell transcript showing directory creation, navigation, and a grep/rg search
  • A git log --oneline transcript showing at least one commit pushed to a remote (command line or GitHub Desktop)
  • A uv (or documented fallback) transcript importing requests

Part 2: Baseline Reflection

Write approximately one page addressing all four prompts below. This is captured now so you can compare it to your thinking at the end of the semester. There are no wrong answers.

Reflection Template (use these as section headings; write a paragraph under each):

My AI Experience So Far

Describe which AI tools you use, for what purposes, and how often. Then describe one specific moment when an AI output surprised you, either because it was better than you expected, or because it failed in an unexpected way. Name the tool, describe the task, and describe the surprise.

What “Agent” Means to Me Right Now

Write your own definition of what makes a system an “agent” rather than just a program or a tool. You do not need to match any textbook definition; write what you actually think. After the semester, we will return to this and see how your thinking changed.

What I Would and Would Not Delegate

Name one task you would happily hand to an AI agent and one you would not. For each, write one or two sentences explaining the specific reason: what is it about that task that makes delegation feel appropriate or inappropriate? The difference between your two examples is more interesting than either example alone.

What I Want to Build

Describe one thing you hope to be able to build or do by the end of the semester that you cannot do today. Be as concrete as you can: what would it do, who would use it, and what would “working” look like?


Troubleshooting

Work down this table before you post in the course channel; if none of it helps, post the exact command you ran and its full output.

Symptom Likely cause Fix
ollama: command not found after installing The installer put the binary somewhere not on your PATH Restart your terminal. If it persists, find the binary (ls /usr/local/bin/ollama) and add its directory to PATH. This is the PATH idea from Step 0 of the Workbench session
The curl to /api/tags says connection refused The Ollama server is not running, which is separate from Ollama being installed Start the desktop app, or run ollama serve in its own terminal and leave it open
The model download stalls or fails partway Network interruption on a 2 GB transfer Rerun ollama pull llama3.2; it resumes rather than restarting
Inside the container, localhost:11434 refuses the connection Correct behavior: localhost inside a container means the container Use http://host.docker.internal:11434. On Linux, start via the course compose file so that hostname resolves
Cannot connect to the Docker daemon Docker Desktop is installed but not running Start the application. On Linux, sudo systemctl start docker, and confirm your user is in the docker group
git push rejected, “authentication failed” GitHub no longer accepts account passwords over HTTPS Use a fine-grained personal access token scoped to that one repository, with Contents: read and write
uv: command not found Not installed, or not on PATH yet Follow the uv install docs, restart the terminal, and if it still fails use the documented python -m venv fallback and say so
ModuleNotFoundError: No module named 'requests' The library is not installed in the Python you are running python -m pip install requests, then rerun the script from the same terminal
On Windows, 'ollama' is not recognized, or curl prints something odd You are in Command Prompt or an old PowerShell window from before the install Open a fresh PowerShell window so the updated PATH loads, and use PowerShell for every command on this page
GitHub Desktop says authentication failed, or cannot push Not signed in, or the repository exists on GitHub but was never published from Desktop File > Options > Accounts, sign in with the browser, then Publish repository; if the repository already exists online, use Add local repository and set the remote under Repository > Repository settings
opencode reports no provider or no models Almost always the config file name: it must be opencode.json, not config.json Fix the name, then check the location (/workspace/opencode.json in the container, ~/.config/opencode/opencode.json natively), then check that the JSON parses with python3 -m json.tool
opencode: command not found inside the container An older build of the course image, from before the agent was added Rerun docker compose build from your .devcontainer/ folder; cached layers make it quick
Responses are very slow A small model on CPU-only hardware Expected. llama3.2 is the right choice for that machine. Note the speed in your transcript; it is a real observation, not a failure
Out of disk space partway through the build The course image plus models is roughly 8 to 10 GB Clear space and rerun docker compose build; completed layers are cached and the build resumes

Self-Check Before You Submit

Hold your submission against the rubric’s proficient column:

  • One file, PDF or Markdown, with each component clearly labeled.
  • Setup transcript covers all five steps, including the coding-agent check, and states your OS and version numbers.
  • Transcript output is copied verbatim, not retyped or paraphrased.
  • Any failure is quoted exactly, with a hypothesis and what you tried.
  • Part 1.5: shell navigation and a search, a git log --oneline showing a pushed commit, and the uv (or documented fallback) output.
  • Reflection has four labeled sections and is about a page.
  • The reflection says what you actually think, not what you expect the course to want.
  • Which route you took (A or B) is stated.
  • Collaboration, AI-disclosure, and hours questions answered at the end.

Deliverables

Submit a single PDF or markdown file containing:

  • Your tool setup transcript (all five steps, including opencode --version and one answered prompt, plus version and OS info)
  • Your command-line and git checkpoint transcript (Part 1.5: navigation, git commit/push, uv environment)
  • Your baseline reflection (one page, four sections)

Frequently Asked Questions

Q: I don’t have a machine that can run Ollama. What should I do? A: Use a lab machine or contact the instructor before the due date. Do not wait until the night before; lab access may require scheduling. Document which machine you used in your transcript.

Q: My Python API call returns an error or the model responds very slowly. Is that okay? A: Slow is okay for a small model on older hardware. An error is okay as long as you document it fully: copy the full error message, describe what you tried, and state whether it was eventually resolved. A partial success with complete documentation earns full credit for that step.

Q: The reflection prompts ask about “agency” and “trust”; do I need to use the textbook definitions? A: No. This is a baseline, and not a knowledge test. Write what you actually think before the course shapes your view. The textbook will be there later; this snapshot of your prior thinking is valuable precisely because it is unfiltered.


Please also answer the following questions in your submission:

  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work? Please identify any and all portions of your submission that were not originally written by you.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all…I am simply using it to gauge if the assignments are too easy or hard)?

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:
  • Describe what you did, how you did it, what challenges you encountered, and how you solved them.
  • Please answer any questions found throughout the narrative of this assignment.
  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
  • Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
  • Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
  • Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
  • Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)
Environment Setup and Verification (40%) Little or no evidence that the environment was attempted Some components installed, but the verification transcript is missing or incomplete Ollama installed and verified with a transcript, with a minor omission such as a missing model listing, missing version information, or a missing coding-agent check, or the command-line and git checkpoint is incomplete The transcript shows all four Ollama steps completed with verbatim terminal output, the output of ollama --version, ollama list showing at least one model, the curl /api/tags JSON response, and the Python script output including a non-empty "content" field, plus the fifth step, the output of opencode --version and one answered prompt from your local model, plus the operating system name and version; the command-line and git checkpoint (Part 1.5) is also complete, showing the shell-navigation commands, a git commit/push transcript (command line or GitHub Desktop), and the uv environment creation; any failed step includes the verbatim error message, a stated hypothesis, and what was tried
Reflection Essay (40%) The reflection is missing or does not address the prompts The reflection addresses some prompts superficially without naming specific tools or moments The reflection addresses all four sections with specific examples, but the connection between the two delegation examples is not analyzed or the "What I Want to Build" section is vague All four sections are present and addressed with concrete specifics, a named AI tool and a described moment of surprise in "My AI Experience," a personal definition of agency distinct from any course reading in "What Agent Means to Me," a pair of delegation examples where the contrast between the two is explicitly analyzed, and a "What I Want to Build" description naming what the system would do, who would use it, and what working would look like
Submission (20%) An incomplete submission is provided The submission is provided but is disorganized, the transcript and the reflection are hard to tell apart, or one is missing All required components are present in a single file, with a minor omission such as an unlabeled transcript section or missing OS information A single well-organized PDF or Markdown file with each component clearly labeled, the five-step setup transcript with version and OS details, the Part 1.5 command-line and git checkpoint, and the four-section reflection, with the collaboration, AI-disclosure, and time questions answered at the end

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