# 13.1 You read, the agent writes (/building-ai-workers/programming-fundamentals/you-read-the-agent-writes)

---
type: Document
title: "13.1 You read, the agent writes"
description: "Why you read the code an agent writes, why you predict before you run, and five steps for learning to read code."
status: stable
order: 313.01
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-02T13:55:25Z
chapter: "13"
part: III
expert_status: builder-only
concepts: [ "13.1" ]
last_verified: 2026-10-30
generated:
  at: 2026-11-02T13:55:25Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** You do not need to write a contract to sign one safely. You need to read it, find the part that matters, and ask what happens when the other side is late. A good contract reader knows the usual parts of a contract well enough to find the unusual one. Nobody expects them to write the whole contract from nothing.

**What you will learn.** Why you read the code an agent writes, how to predict what it will print, and five steps for learning to read code with an agent beside you.

**Why it matters.** The agent writes the code. Showing that it does the right thing is still your job.

### What is my job when an agent writes the code?

You say what the program must do, and you show that it does it. Working with a coding agent puts you in the contract reader's place. The agent writes the first version of the program.

| The old job | The new job |
| --- | --- |
| Write the program line by line | Say exactly what the program must do |
| Remember the exact syntax, the rules for writing code | Recognize the syntax well enough to question what you read |
| Get it to run | Show it is correct, not just that it runs |
| Leave it however it comes out | Keep it readable, because you and the agent both read it next |

**Recognition, not recall.** This chapter asks you to recognize code, not to remember it. You do not need to remember that a **list** is written with square brackets. You need to see `["V001", "V002"]` and know it is a list of two values. Reading is much easier than writing, and it is the half of programming that stays yours.

**10-80-10 for code.** [Chapter 3](../../ai-worker-paradigm/the-10-80-10-operating-rhythm/one-rhythm.md) taught the rhythm of delegated work: you define the first 10 percent, the worker does the middle 80, and you verify the last 10. For code, the first 10 percent is what to build and what "correct" means. The middle 80 is the code. The last 10 percent is verifying it against the agreed requirements. Reading code well is what lets you do your part at both ends.

### How do I learn to read code with an agent beside me?

**PRIMM-AI+** is the one method this book uses for learning to read code with an agent beside you. It has five steps, and it comes from a method teachers already use, called PRIMM. The "AI+" adds two things. The agent is your reading partner at every step, and nothing it says is accepted without a check.

| Step | What you do | The agent's role |
| --- | --- | --- |
| Predict | Say what the code will do before anything runs | Stays quiet. The guess is yours |
| Run | Run it and see the real output | Runs it for you, with your permission |
| Investigate | Compare your guess with the output, and ask why | Explains a line when you ask: "What does line 3 do?" |
| Modify | Change one thing, predict again, run again | Makes the edit you describe |
| Make | Specify your own version, let the agent build it, then verify | Writes code against your specification |

### Why predict before I run?

The gap between what you expected and what happened is where you learn. It works like a bank reconciliation: when your records and the statement differ by $25, the gap sends you to the fee you forgot to record. A wrong prediction shows you which part of your picture of the code is wrong. Write the prediction down, or say it to the agent, and only then run. A prediction you make after seeing the output is not a prediction.

**At work.** Ana Morales, the accounts payable (AP) analyst at Brightline, opens the vendor script that came with the [Chapter 12](../agentic-coding/lab.md) repository. Before she has the agent run it, she reads the **loop** at the bottom, the part that repeats for each vendor. Her note in `NOTES.md` says, "It prints one line per vendor: the id, the name, and the terms in round brackets." Then the agent runs it. She was right about the shape, and wrong about one detail. There are two spaces between the parts, not one. It is small, but it tells her she read the line that builds the output too fast. She asks the agent, "Why are there two spaces? Can you explain the line that builds each output line?" Now she knows that in text between backticks, `${id}` puts in what `id` holds.

**In TypeScript.** A **variable** is a name for a **value**, one piece of data, and `const` makes one. A **string** is a piece of text in quotes, and `\n` inside it starts a new line. `console.log(...)` prints a line. This is the script Ana read. Before you look at the output, find the line that puts two spaces between the parts.

```ts
const csv = "vendor_id,vendor_name,terms\nV001,Midwest Packaging Co.,Net 30\nV002,Buckeye Janitorial Supply,Net 15\n";
const lines = csv.trim().split(/\r?\n/).slice(1);
for (const line of lines) {
  const [id, name, terms] = line.split(",");
  console.log(`${id}  ${name}  (${terms})`);
}
```

```text
V001  Midwest Packaging Co.  (Net 30)
V002  Buckeye Janitorial Supply  (Net 15)
```

`trim()` removes the blank space at the ends, `split(/\r?\n/)` cuts the text into lines, and `slice(1)` drops the first line, the header. The loop runs once for each line that is left. Inside it, `split(",")` cuts the line at its commas into three parts, named `id`, `name` and `terms`.

**In Python.** The same idea, the same output.

```python
csv = "vendor_id,vendor_name,terms\nV001,Midwest Packaging Co.,Net 30\nV002,Buckeye Janitorial Supply,Net 15\n"
for line in csv.strip().splitlines()[1:]:
    vendor_id, name, terms = line.split(",")
    print(f"{vendor_id}  {name}  ({terms})")
```

```text
V001  Midwest Packaging Co.  (Net 30)
V002  Buckeye Janitorial Supply  (Net 15)
```

**Where the languages differ.** Several pairs here look different but mean the same, such as `trim()` and `strip()`, and `console.log` and `print`. Two pairs need a word more. `slice(1)` and `[1:]` both mean "from the second item on". Positions count from 0, in a list and in text, so position 1 is the second item, and `[0]` takes the first. The backtick string with `${...}` in TypeScript is the `f"...{...}"` string in Python. One difference matters. TypeScript marks a **block**, the lines that belong together, such as a loop's lines, with braces `{ }`. Python marks a block by indentation, the spaces at the start of each line. So in Python, moving a line left or right changes which block it belongs to.

**The operating rule:** predict before you run, every time, and learn from the gap between your prediction and the output.

![Figure 13.1. The PRIMM-AI+ loop as five steps: Predict, Run, Investigate, Modify and Make. At each step you predict, compare, explain or specify, and the agent waits, runs, explains, edits or builds. The loop repeats with the next piece of code, and claims are checked by running code and tests.](img/primm-ai-loop.png)

*Figure 13.1. The PRIMM-AI+ loop. Predict, Run and Investigate build reading. Modify and Make are where you start directing the agent. The agent explains on request. A run or a test decides.*

**Practice it.** [Practice: predict, run, investigate](both-ai-vendors.md#practice-predict-run-investigate), in your own tool, ten minutes, and a few more the first time, for the setup.
