Lesson 13.1013.10 How today's tools realize it

In everyday life. Three driving schools teach the same rules of the road in different cars. The pedals and the mirrors are in slightly different places. Two cars come with a brake on the instructor's side, and in the third the instructor fits one before the first lesson. You are the instructor in every car.

What you will learn. How to practice each lesson of this chapter in your own agent, and where Claude Code, Codex and OpenCode differ when they run a command, reach the network, plan a change and review it, as of October 30, 2026.

Why it matters. The products differ in what runs without asking. Your part does not: you guess, the agent runs it, and you read what really happened.

How to use this page. Each section is the practice for one lesson, and that lesson links to it. Each is a short exercise, five to fifteen minutes. Most steps are the same in every agent, so they are written once. Where the three products differ, the section ends with tabs: pick your tool once, and every strip on this page follows. Each lesson already showed its own block's output, so most exercises change one thing in a copy first, and you predict the new result. That is the Modify step of PRIMM-AI+. Before you approve a command, read what the agent says it will do, and say no to anything you do not understand. Concept 12.7 covers the products in full.

Practice: predict, run, investigate

From Concept 13.1. Change one thing in 13.1's block, predict what it prints now, have the agent run it, and ask about what you got wrong. Ten minutes, and a few more the first time, for the setup.

The first time, set up once. The rest of this page uses this folder and these tools.

1. Download brightline-lab-ch13.zip, and unzip it.
2. Open its concept-blocks/ch13 folder in your agent. Set the agent to ask before it acts: Manual in Claude Code, Ask for approval in Codex. In OpenCode, add the rules its tab at the end of this section describes. The exercises run in this folder, unless a step says otherwise.
3. Send the setup prompt from 13.2, because the exercises need Node.js and uv. You read that lesson next, so for now you need only its prompt. Install anything missing only after you have read each step.

The exercise.

1. Send: "Please copy 13-1.ts to try-13-1.ts, and remove .slice(1) from the copy. Don't run it yet."
2. Open try-13-1.ts in a text editor, not in the agent. Write in a note exactly what it will print now: how many lines, and how the first one looks.
3. Send: "Please run try-13-1.ts with Node and show me what it prints. Don't explain it yet. I want to compare it with my guess first." Expect node try-13-1.ts.
4. If your guess was wrong, ask: "I thought it would print [your guess], but it printed [what you saw]. Which line in try-13-1.ts does that, and why?"
5. Do the same in Python, with a copy of 13_1.py without [1:], run with uv run python.

What you should see. Three lines now. The first is the header, vendor_id vendor_name (terms), because nothing drops it any more.

How each agent asks before it runs a command. In these tabs, a sandbox is not the throwaway machine of 12.3. It is a set of limits on your own computer, like a contractor who works in your house but may change only one room, and asks before going out for supplies.

Practice: the workbench

From Concept 13.2. Watch a type checker catch what Node runs. Ten minutes.

1. Predict what 13-2.ts prints. Then send: "Please run 13-2.ts with Node, then check the same file with the TypeScript type checker. Before you run the checker, tell me in plain words what each part of its command does. Show me what each one prints, and change nothing." Expect node 13-2.ts, then npx -y -p typescript tsc --noEmit 13-2.ts.
2. Send: "Please do the same for 13_2.py. Run it, then check it with the Python type checker, Pyright, and tell me first what each part of that command does." Expect uv run python 13_2.py, then uvx pyright 13_2.py.
3. Read each error. Each names the file, the line and the problem.

What you should see. Node prints a wrong number, Python stops with a TypeError, and both type checkers report line 2 without running the file.

The two type checkers come from the internet the first time, through npx and uvx. This is where the three products differ most:

Practice: values and types

From Concept 13.3. Write an amount the way real exports often do, and predict which language keeps running. Ten minutes.

1. Send: "Please copy 13-3.ts to try-13-3.ts and 13_3.py to try_13_3.py. In each copy, change "482500" to "4,825.00" on the first line. Don't run them yet."
2. Write down what each line of each copy will print now.
3. Send: "Please run both copies and show me what they print. Don't explain them yet. I want to check my guesses first."
4. Ask the agent about the first line you got wrong.

What you should see. TypeScript keeps going: the joined text, then NaN where it converts the amount, and 3.3000000000000003 on the last line. Python stops at its second print, with a ValueError, because "4,825.00" is not a whole number.

Practice: decisions and loops

From Concept 13.4. Say each decision as a sentence, test one against a capital letter, and watch a zero count as missing. Ten minutes.

1. In 13-4.ts, find the two places the code chooses: the filter and the ||. Write each one as a sentence in your note, such as "keep an invoice only if its status is open".
2. Send: "Please copy 13-4.ts to try-13-4.ts, and change INV-8301's status to "Open", with a capital O. Don't run it yet." Use your sentence to predict which invoices it lists now.
3. Send: "Please run try-13-4.ts and show me what it prints. Don't explain it yet."
4. Predict what 0 || "no amount" prints, as for a $0.00 credit. Then send: "Please add a line at the end of try-13-4.ts that prints 0 || "no amount", and run it again."
5. In 13-4-while.ts, find the line that makes the loop stop, and say why it stops.

What you should see. Only INV-8305 is listed, because "Open" is not "open". The new last line prints no amount: a $0.00 credit treated as missing.

Practice: functions

From Concept 13.5. Read a signature as a promise, test it with a case you worked out on a calendar, then see what strict mode adds. Fifteen minutes.

1. Open 13-7.ts in a text editor and read only the first line of addDays, its signature. Write its promise in one sentence.
2. Pick a case of your own, not the lesson's, such as January 20, 2027 plus 15 days, and work out the answer on a calendar.
3. Send: "Please copy 13-7.ts to a new file, try-13-5.ts. At the end, add one assertion that adding 15 days to 2027-01-20 gives the date I worked out: [your date, written year-month-day]. Then run it." Before you approve the run, read the line it added: does it hold your date and your answer? The file's other lines print first, so ignore them.
4. Send: "Now change the date in my assertion to one day later, on purpose, and run it again."
5. Send: "Now please check 13_5_strict.py with Pyright twice, first in its default mode and then in strict mode. Before the second run, tell me how you will turn strict mode on."

What you should see. The first run ends with no error. The second stops with an AssertionError that shows the actual and the expected dates side by side. If the first run fails, count the days again before you blame the code. Pyright finds nothing in 13_5_strict.py until strict mode is on. Then it reports the missing label on amounts.

Practice: lists and dictionaries

From Concept 13.6. Ask the two questions for every lookup and every sort. Fifteen minutes.

1. Send: "Please run 13-6.ts and 13_6.py and show me what each prints. Don't explain them yet." Compare what each language does with the missing vendor, V099.
2. Send: "Please run Ana's sorted list, 13-1-sort.ts, for this Friday and then for next Friday, 2027-03-12. Show me both." Find where INV-8303 lands the second time. Then look at the count and total: nothing in them shows the bug.
3. Send: "Please copy 13-1-sort.ts to try-13-6.ts, and make the copy compare the amounts as numbers, b.cents - a.cents. Don't run it yet." Predict next Friday's first invoice. Then have the agent run the copy for 2027-03-12.
4. Predict how many values a set of INV-8301, INV-8305, INV-8301 and INV-8312 holds, and which two slice(0, 2) takes. Then send: "Please run 13-6-sets.ts and 13_6_sets.py and show me what each prints. Don't explain them yet."
5. In your note, write what each sort compares, and what each lookup does with a missing key.

What you should see. undefined in TypeScript and a KeyError in Python for the missing vendor. With text sorting, next week's largest invoice, $12,900.00, sits below a $199.95 one. With numbers, it comes first. The set holds 3 values, the slice takes INV-8301 and INV-8305, and the Python file ends with a TypeError, because a tuple cannot change.

Practice: text, dates and files

From Concept 13.7. Find the date bug that depends on where the computer is. Ten minutes.

1. Before any run, predict the second line of 13-7.ts on your own computer. Is your computer east or west of UTC, the world reference time?
2. Send: "Please run 13-7.ts three times, as it is, then as if this computer were in New York, then as if it were in Tokyo. Set the time zone the way your shell needs, and show me all three outputs."
3. Find the line that changes with the time zone, and say why it changes.
4. Send: "13_7_with.py opens data/vendors.csv, which is in the lab download's brightline-ap folder. Please run it from inside brightline-ap so it finds that file, and show me what it prints."

What you should see. The same three dates in every time zone. The second line shows October 20 in New York and October 19 in Tokyo. On your own computer it depends on where you are: east of UTC, as in Pakistan, it shows the 19th. The Python file prints the header of vendors.csv, then True.

Practice: read an error

From Concept 13.8. Read a Node error from the top, and find where the bad value came from. Five minutes.

1. Send: "Please copy 13-4-while.ts to try-13-8.ts, and remove the empty page, the last [], from its list of pages. Don't run it yet." Predict what happens now.
2. Send: "Please run try-13-8.ts and show me the whole error. Don't explain it yet. I want to read it first."
3. Read the report from the top. Write one sentence that names the file, the line and the cause.
4. Then ask the agent what it thinks, and compare.

What you should see. Two pages print, then a TypeError on the while line: there is no third page to read. The line that fails is the while, but the cause is the data you changed.

Practice: tests first

From Concept 13.9. Watch a test fail for the right reason, hand the agent your own cases, and plan the code without writing it. Fifteen minutes.

1. Open 13-9.test.ts. It tests dueDate, which does not exist yet. Predict how the run will fail.
2. Send: "Please run 13-9.test.ts with node --test. Don't fix anything." Check the reason: the module is missing, not a typo in the test.
3. In your note, list three more cases for dueDate, each with its answer: one across a month end, one across a leap day, and terms written another way, such as net 30 in small letters. Decide whether that last one should be an error. These cases are your part.
4. Send: "Please copy 13-9.test.ts to try-13-9.test.ts, and add my three cases to the copy as tests. Don't add cases of your own, and don't write dueDate yet." Then paste your list. Read each new test against your note: the same date, the same terms, the same answer.
5. Ask for a plan, with no code yet, for a dueDate that passes every case. Read the plan against your list.

What you should see. A run that fails because due-date.ts is missing, new tests that match your list line by line, and a plan you checked against them.

How each agent plans without editing:

Practice: judgment

From Concept 13.11. Decide what a change must do, then review it before you commit. Fifteen minutes.

1. Ask the agent to copy brightline-ap from the lab download into a new folder beside it, practice-13, and to put it under git with one commit. Then open practice-13 in your agent. Work there, so the lab still starts clean.
2. Before any change, write in your note which vendor should come first and which last, sorted by name from A to Z. The names are in data/vendors.csv.
3. Send: "Please change src/list-vendors.ts so it prints the vendors sorted by name, A to Z. Don't change any tests."
4. Before you commit, run your agent's review, as the tabs below say. Then have the agent show git status and git diff, and answer these questions yourself, from 13.11: which files changed, whether any test changed, whether it added a package, whether the tests pass, and what the main function now does, in one sentence.
5. Which row of 13.11's table is this change? The vendor list runs every week, on vendors nobody has checked. Write one sentence for the line that sorts: what it compares.

What you should see. A change to src/list-vendors.ts only, with the first and last vendors you wrote down, no test changed and no package added. The sort happens where the vendors are printed, not in parseVendors, because its test expects the file's own order.

How each agent reviews a change before the commit:

The differences that change a decision

1. Who can install a package without a prompt. OpenCode can, if your rules do not say ask. Claude Code reaches the network freely once you approve a command. Codex's sandbox blocks the network by default and asks. On your laptop, approve each install only after you have read the package name.
2. Where tests run. Codex runs commands on your computer, inside a sandbox that limits writes to the project. Claude Code runs them with your full rights unless you turn on its sandbox. OpenCode always runs them with your rights. So read each command before you approve it: outside a sandbox, it can change any file you can.
3. Review built in. Claude Code has /code-review and /security-review, and Codex has /review. OpenCode's version 2 documentation names no review command, but its Desktop has a review panel. On every product, an agent's review is a second worker checking the first. Chapter 6 says that is not the review, so the review is yours.

What stays the same on every product?

Four things do not change, whichever product you use.

1. The tests you decided on say what correct means for the cases they name, and you read the rule lines before you accept, whichever agent wrote the code.
2. On any product, the agent must not edit a test to make it pass. A diff against the commit that saved the tests shows whether it did.
3. Have the agent run the type checker and the tests on every change, wherever you run it, and read what they print.
4. An explanation from the agent is a claim. A run or a test checks it.

What it costs