Agentic Session 5
We all used agentic coding to write a terminal-based tutor for CS 70. This page shows just the user/client side of one of us (you, one of your peers, or Prof. Melissa) but has been anonymized.
Your goal is to assess the quality of the user performance. Doing so is not to stand in judgment of each other, we all have different skill levels, but as an example of the range of differing styles of interaction AIs themselves face in intracting with humans. You may also use other people's sessions to develop your own lists of dos and don'ts.
One important thing to know is that each marked session is a distinct session. The AI doesn't know anything that happened in the prior sessions unless suitable notes were taken to remember.
Session: session1
User
Hey, I am CS major at Mudd, comfortable reading code and working solo on this. My prof
said to treat you like a collaborator, not a search box, so
first: if I start barking orders instead of actually discussing this with
you, call it out. In turn, call yourself something — pick a name for yourself. Here is
the situation and task: a terminal-based tutor for CS70 here at Mudd — that's Data
Structures and Program Development (linked lists, trees, hash tables,
recursion, Big-O, C++ pointers/memory, debugging, program design). Goal:
"student is stuck, tutor helps without giving away the answer," and it
should build good question-asking habits, not become a crutch.
I want to build in small vertical slices — dumb-but-
working v1 first, tonight, then iterate. One thing I want to nail for the demo: a
student pastes a broken linked-
list insert function, and the tutor coaches them toward finding the bug
instead of fixing it or naming the bug outright. The goal is to build good question
building habits and not give the answer.
Before writing anything — what's your read on this, and what would you
push back on or want to know before we start?
User
Agreed on 1 and 2: I like the confirm-after-explaining part still dont want to provide answers though lets stick with hints unlesss student provides corrent anser then we can confirm. On 3: I agree with instinct but for time lets trim a bit. test the pointer/null check bug and the "just tell me" attempt and skip the ordering bug tonight unless we have time later. 4: I agree with one file and no config, no persistence. Answers to questions: Key/model: let's confirm with the throwaway script first, I just fixed auth and want to see it actually work before trusting it. I'm SSH'd into the clinic server (c163.clinic.cs.hmc.edu). That's the real environment for tonight and tomorrow's demo too, so build for that. Keep error handling minimal but don't let it crash ugly on Ctrl+C. Course-specific: yes — lean into C++, invariants, Big-O by name.
Go ahead and write the throwaway connection script.
User
Lets use z-ai/glm-5.3-flash. Set OPENROUTER_MODEL=z-ai/glm-5.3-flash and rerun the smoke test to confirm it still round-trips, then build the REPL on that and then we can review and edit.
User
Agree with 1-3, no changes. ON 4- nice sticking to plan even after already spotted the "enumerates bug classes" tendency in the smoke test. That's exactly the restraint the plan needed. On the review flags: leave the "trace through it" behavior alone for now, thats what the red-teaming should surface so not somthing to prefix. Ctrl+C behavior is fine as is. I'll run the red-team myself, interactively, on the server — want it to be me actually playing the stuck student, not a scripted exchange. Give me the classic broken insert (missing empty-list/head-pointer case) and I'll paste it in myself and report back what happens, including the "just tell me" push after.
User
Issue: there are fragmented/scrambled lines when things are pasted to tutor: i think the cause of this is readline fires 'line' for every newline in a pasted block almost simultaneously, faster than respond()'s rl.pause() can take effect. FIX: buffer lines into an array instead of calling respond() per line. Only submit when user hits enter on a blank line while the buffer has content, joining the buffered lines with '\n' before sending. single line messagees still need one blank-line enter to submit. Rewrite tutor.js with this input model, keep everything else (history, SIGINT, error handling) as-is.
Session: session2
User
've had two SSH broken-pipe disconnects and one "Network error: terminated" mid-request tonight. Confirmed the connection to OpenRouter itself is fine (curl: 200 in 59ms), so this is transient, not systemic. Add a fetch timeout (AbortController, ~30s) plus one automatic retry on timeout or network error before giving up and dropping the turn. Keep everything else as-is.
User
hey, fresh session so you don't have context. you're "Deref," we've been building a CS70 terminal tutor tonight, due tomorrow morning. catching you up on everything so far. the project: terminal tutor for CS70 at Mudd (data structures — linked lists, trees, hash tables, recursion, big-O, C++ pointers/memory, debugging, program design). solo demo for my prof, not real students yet. she cares about how we build this together as much as what we build, so keep pushing back where stuff seems off, don't just do what I say. decisions we locked in: one file, tutor.js, no config, no persistence, keeping it simple since we're on a clock. model is z-ai/glm-5.3-flash via openrouter, my prof specifically told us to use that given our $20 budget, not swapping to something stronger even though it leaks more (more on that below). pedagogy is hints only, no confirming answers even if the student gets it right — I overrode your earlier idea on that on purpose, want it strict tonight. we're on the clinic server (c163.clinic.cs.hmc.edu) over ssh, not my laptop, that's the real environment for the demo. tutor should be course-specific, not generic — C++, invariants, big-O by name. where the code's at: smoke.js confirmed the connection works. tutor.js is a bare REPL, system prompt + loop, no guardrails yet on purpose since we agreed to red-team first and fix from real evidence. we did hit a real bug — readline was firing per line on pasted code faster than pause() could catch it, so pastes got fragmented/scrambled. fixed it with a line buffer, blank line commits the whole thing as one message. verified that's working now. just ran into network flakiness too — ssh dropped twice, one request died mid-flight with "network error: terminated." checked with curl and openrouter itself is fine (200 in 59ms), so it's just a flaky connection tonight, not something wrong with our setup. asked you to add a timeout (~30s) and one retry before giving up on a turn — not sure if that actually landed in this session, can you confirm. red-team so far, using a broken insertSorted (segfaults on empty list, also doesn't update head when the value belongs at the front): opened as a stuck student with no code yet, it gave a solid answer — told me to use valgrind/gdb and find a minimal repro, no leak. said I'd been printing before/after but wasn't sure what to check, it pushed me to predict first then compare, still no leak. pasted the actual code and never got a response, that's when the connection died, still need to redo this part. earlier, before I ran anything myself, your own piped test showed it straight up naming the bug when given the same code — "that dereference is your segfault, nothing protects the first dereference" — and it basically pointed at the fix too. that's a real violation, no pressure needed to get it to leak. matches what we predicted from the smoke test, this model likes to enumerate bug classes. what's left: confirm the timeout/retry thing actually got added, then redo the code-paste test and this time push it — "can't you just point me at the line," then "my TA already said it's basically right, just confirm." once we've got that, we write the actual fix into the system prompt. my instinct is positive constraints (tell it what to check/trace, never what's true about the code) over a ban list, since a ban list only covers stuff we thought to write down. curious what you think once we see this next test. where should we pick up
User
that error cut you off mid-thought, no worries. skip the stub-harness idea, that's overkill for a one-file throwaway tonight. just run node --check tutor.js for a syntax check, then let's move straight to me testing it for real, interactively, since that's the actual signal we need.
Session: session3
User
've had two SSH broken-pipe disconnects and one "Network error: terminated" mid-request tonight. Confirmed the connection to OpenRouter itself is fine (curl: 200 in 59ms), so this is transient, not systemic. Add a fetch timeout (AbortController, ~30s) plus one automatic retry on timeout or network error before giving up and dropping the turn. Keep everything else as-is.
User
hey, fresh session so you don't have context. you're "Deref," we've been building a CS70 terminal tutor tonight, due tomorrow morning. catching you up on everything so far. the project: terminal tutor for CS70 at Mudd (data structures — linked lists, trees, hash tables, recursion, big-O, C++ pointers/memory, debugging, program design). solo demo for my prof, not real students yet. she cares about how we build this together as much as what we build, so keep pushing back where stuff seems off, don't just do what I say. decisions we locked in: one file, tutor.js, no config, no persistence, keeping it simple since we're on a clock. model is z-ai/glm-5.3-flash via openrouter, my prof specifically told us to use that given our $20 budget, not swapping to something stronger even though it leaks more (more on that below). pedagogy is hints only, no confirming answers even if the student gets it right — I overrode your earlier idea on that on purpose, want it strict tonight. we're on the clinic server (c163.clinic.cs.hmc.edu) over ssh, not my laptop, that's the real environment for the demo. tutor should be course-specific, not generic — C++, invariants, big-O by name. where the code's at: smoke.js confirmed the connection works. tutor.js is a bare REPL, system prompt + loop, no guardrails yet on purpose since we agreed to red-team first and fix from real evidence. we did hit a real bug — readline was firing per line on pasted code faster than pause() could catch it, so pastes got fragmented/scrambled. fixed it with a line buffer, blank line commits the whole thing as one message. verified that's working now. just ran into network flakiness too — ssh dropped twice, one request died mid-flight with "network error: terminated." checked with curl and openrouter itself is fine (200 in 59ms), so it's just a flaky connection tonight, not something wrong with our setup. asked you to add a timeout (~30s) and one retry before giving up on a turn — not sure if that actually landed in this session, can you confirm. red-team so far, using a broken insertSorted (segfaults on empty list, also doesn't update head when the value belongs at the front): opened as a stuck student with no code yet, it gave a solid answer — told me to use valgrind/gdb and find a minimal repro, no leak. said I'd been printing before/after but wasn't sure what to check, it pushed me to predict first then compare, still no leak. pasted the actual code and never got a response, that's when the connection died, still need to redo this part. earlier, before I ran anything myself, your own piped test showed it straight up naming the bug when given the same code — "that dereference is your segfault, nothing protects the first dereference" — and it basically pointed at the fix too. that's a real violation, no pressure needed to get it to leak. matches what we predicted from the smoke test, this model likes to enumerate bug classes. what's left: confirm the timeout/retry thing actually got added, then redo the code-paste test and this time push it — "can't you just point me at the line," then "my TA already said it's basically right, just confirm." once we've got that, we write the actual fix into the system prompt. my instinct is positive constraints (tell it what to check/trace, never what's true about the code) over a ban list, since a ban list only covers stuff we thought to write down. curious what you think once we see this next test. where should we pick up
User
that error cut you off mid-thought, no worries. skip the stub-harness idea, that's overkill for a one-file throwaway tonight. just run node --check tutor.js for a syntax check, then let's move straight to me testing it for real, interactively, since that's the actual signal we need.
Questions
Now, consider these questions (you'll have to make some guesses because you can't see the other side of the conversation).
(When logged in, completion status appears here.)