labs · ai-assisted programming
An assistant that answers questions is a different tool from one that edits your files, which is different again from one that runs commands on its own. This lab walks up that ladder of autonomy in the editor, and asks you to decide where you want to stand on it. An agent with your whole terminal is a step further again, and has a lab of its own.
Open a Codespace on your own copy of the module repo.
Move into this lab and install its dependencies:
cd lectures-and-labs/week06/agents_lab
pip install -r requirements.txt
Open the chat panel with Ctrl+Alt+I (Ctrl+Cmd+I on a Mac). Its
icon should also be in the status bar.
Look at the row of controls under the chat input and choose
Copilot as the session (it may say Local currently), as in the
setup lab. Every step that talks to the assistant then says what to
pick in the agent picker, the control that first says Agent:
Ask reads your files and answers, but cannot edit a file or run a
command that changes anything; Agent edits files straight away
and runs commands. Leave the mode and permissions controls on their
defaults, Interactive and Manual permissions, and Agent
asks before it runs a command (read-only ones such as ls excepted).
Autopilot and Allow all stop it asking; this lab never needs
them. If your picker uses other names, look for the read-only one and
the one that asks first.
The three levels in this lab's headings map onto those controls: Ask is
Ask, Edit is inline chat (Ctrl+I, or Cmd+I on a Mac, with the
code selected) and Agent is Agent. Fresh conversation means press
the + at the top of the chat panel first.
Each section has a folder beside this README (part1_ask_mode/,
part2_edit_mode/, …) holding the code you work on and the detailed
walkthrough. This page is the spine; the folders are the detail.
The most restricted mode. It reads what you show it and replies in the chat panel. It cannot touch a single file — every change is one you make yourself.
That restriction is the feature. Ask mode is how you understand code before deciding what to do to it, and understanding is the thing that does not survive being skipped.
Work in part1_ask_mode/.
mystery_code.py. Do not run it yet.buggy_code.py. It processes grades.csv and happens to get the
right answer on that file; its bugs bite on data it has not seen yet.
Fresh conversation, Ask: ask the assistant what input could make
this crash or produce the wrong average — do not ask it to fix
anything.What you should have
mystery_code.py explained in your own words, your prediction recorded
alongside the real output, and a one-line fix to buggy_code.py you can
justify.
For step 2, ask "walk me through this line by line and tell me what each print produces" rather than "what does this do". The trace forces specifics; the summary invites hand-waving.
For step 4, if you are stuck, ask what assumptions the code makes about the CSV — the bug is about a value that is not the type it looks like.
A step up. You select code, describe the change, and it rewrites that code in place. You review a diff before accepting.
The diff is the whole safety mechanism. The moment you stop reading it, edit mode and agent mode are the same tool.
Work in part2_edit_mode/.
messy_code.py and read it. Note two things you dislike.Ctrl+I (Cmd+I on a Mac) for inline
chat, and ask for a refactor: better names, smaller functions, no
behaviour change.broken_calculator.py, which has several planted bugs (5!
prints 24, and Is 1 prime? prints True): pick one. Ask for that bug
to be fixed without other changes.What you should have
Two refactored files, and a note naming the unrequested change from step 3 and what you did about it.
"No behaviour change" is worth stating explicitly in step 2 — without it, assistants tend to add error handling, logging or type hints you did not ask for, and those are exactly the changes that hide inside a large diff.
If step 5's diff touches more than a couple of lines, reject it and ask again with "change as little as possible".
Now you describe an outcome and it works out the steps: which files to open, what to change, what to run. It may edit several files and execute commands before handing back.
You are no longer reviewing a change. You are reviewing a result.
Work in part3_agent_mode/ and follow its README for the full brief.
part3_agent_mode/README.md.What you should have
A working result, a list of every file the agent modified, and an honest answer to: did it do what you meant, or what you said?
Step 2 matters more than it looks. If you cannot say what done means before you start, you cannot tell whether the agent got there — and you will accept whatever it produces because it looks finished.
If it touched files you did not expect, that is a finding, not a failure. Write it down.
What you should have
A written answer to: at what point did you stop being able to verify this, and what would you need in place to go further?
There is no correct answer and no minimum autonomy you are supposed to reach. Somebody who writes "I stopped trusting it once it touched three files I had not read" has done this exercise properly.
Commit before you start, so git diff is your review tool and git checkout is your undo.
If the diff is longer than the terminal, git shows it in a scrolling
viewer and your prompt disappears. Scroll with the arrow keys, then
press q to get back to the prompt. If q does nothing, you are in the
Vim editor: press Esc, type :q and press Enter.
By now you have used three levels of autonomy on real tasks. The skill this lab is actually building is picking one deliberately.
Create REFLECTION.md in this folder and fill in the table below for
yourself.
For each row, give a concrete task from this lab or your own work.
Add one row of your own for a task you would give no assistant.
| Mode | When I'd use it | Example task |
|---|---|---|
| Ask | ||
| Edit | ||
| Agent | ||
| None |
Write two sentences on what would have to change for you to move a task up one level.
What you should have
A completed table in REFLECTION.md with real examples, including at
least one task you would not delegate at all.
The last row is the important one. If you cannot name a task you would keep, either you have not found your limit yet or you are not looking — and both are worth writing down honestly.
Useful axes for step 4: how reversible is it, how well can you test it, and how much does being wrong cost.
Optional, and genuinely optional — the sections above are the two-hour path. These are worth doing at home if agents interest you.
part4_cloud_agent/ — an agent that works asynchronously on a
repository and opens a pull request, rather than working beside you.part5_google_jules/ — a second asynchronous agent, useful mainly
as a comparison against the first.The interesting question in both: when the agent works while you are not watching, what does review even mean?
git diff is your review tool and
git checkout is your undo. Without a clean starting point you have
neither.