Tessa's Twenty Lines

The season closes and the reviews arrive the way they always do: 2,300 of them, exported out of the booking system into one file, sitting on Tessa's desktop like a dare.

She knows exactly what to do with them. She has known since Chapter 5. The template is written, versioned and proven; the four buckets are defined; the fields are agreed with the tracker; the checks are a spreadsheet ritual she can do in ten minutes. What she does not have is an afternoon to spend pasting fifty reviews at a time into a chat box, forty-six times, while the rest of her job waits.

Milo has an hour free. What he writes in it is twenty lines long, and this page reads them out loud.

Here is the promise of the page, made plainly: every line in that program does something this book has already taught. Not one new idea is coming. The program is Tessa's craft, arranged so that a computer can repeat it, and by the end of the page she can point at any line and say which chapter it came from.

2,300 reviewsthe season's export

→

Template plus one review, sentand it waits when the provider says wait

→

Checks with no judgement in thema bucket from the four · an identifier present

→

Results file, and her random dozen2,300 rows with known error behaviour

The Shape Before the Lines

Start with the shape, because the shape is the whole thing and it fits in one sentence.

Open the file of reviews. Take them one at a time. For each one: build a request out of the template and that review, send it, wait if the provider says wait, read the answer, check it, keep it. When the reviews run out, write everything collected into a new file.

Read that back and notice there is no intelligence in it anywhere. It is four steps repeated 2,300 times with a bit of patience built in. The intelligence is in the template — which Tessa wrote, revised four times and tested — and in the model, which the request reaches. The program is the arrangement.

Which is exactly what Chapter 5 said it would be. That page described Tessa's afternoon as fixed text, a slot for the next batch, a run, and an output collected into a growing file, repeated forty-six times, with a human supplying nothing but the copying. This is that description, executed.

The Twenty Lines, Read in Groups

The code is printed once below and then read in five groups. If you would rather not look at it at all, do not — the reading stands entirely on its own, and by design nothing in the prose depends on your eyes being on the block.

Three things about it are shorthand rather than reality. The model's name is written as an obvious placeholder, exactly as it was in Chapter 7, because this book names no products. The act of sending the request is written as one instruction called send request, which stands for the whole HTTP call from that chapter — the address, the key in its place, the body, the waiting. And the step that reads the reply assumes the reply is labelled data; a real program carries one more line for the reply that is not — a stray sentence in front of the braces — so that the row gets flagged rather than the run stopping. In a real program all of that is a few more lines of ordinary plumbing, and none of it would teach you anything this book has not already taught.

import json, os, time

KEY      = os.environ["WAYMARK_REVIEWS_KEY"]
BUCKETS  = ("praise", "complaint", "question", "mixed")
template = open("review-template-v4.txt").read()
reviews  = json.load(open("reviews.json"))
results  = []

for review in reviews:
    request = {"model": "model-name-here",
               "messages": [{"role": "system", "content": template},
                            {"role": "user",   "content": review["text"]}],
               "temperature": 0.0,
               "max_output_tokens": 120}
    status, response = send_request(request, KEY)
    while status == 429:
        time.sleep(20)
        status, response = send_request(request, KEY)
    row = json.loads(response["message"]["content"])
    ok  = row.get("category") in BUCKETS and "review_id" in row
    results.append(row if ok else {"review_id": review["id"], "flag": "check by hand"})

json.dump(results, open("classified.json", "w"))

Group one: the setup. Six lines, and they do nothing but put four things within reach before the work starts.

The key comes first, and where it comes from is the point. It is not typed into the program. The program asks the computer for it by name, and the computer supplies the value that Milo put into the machine's key store when he set this up. So the key never appears in the file, never travels with it, and never lands in an email or a shared folder if the file is passed to somebody. That is Chapter 7's handling rule, honoured in one line — and the reason Tessa can read this program aloud in an open-plan office.

Then the four bucket names, written down once: praise, complaint, question, mixed. They are here so that the checking group can compare against them later, and so that changing Waymark's categories means editing one line rather than hunting through the program.

Then the template — the actual document from Chapter 5, version four, the one with the rule about vague reviews that she added after the Harbourview Annex turned up in a spreadsheet cell. The program reads that file off the disk rather than containing a copy of it. Tessa can edit the template tomorrow without anyone touching the program, which is precisely the arrangement she wants, because the template is hers and the program is Milo's.

Then the reviews, loaded from the export file. And finally an empty list, waiting to collect results — the growing file from Chapter 5, in its earliest form.

Group two: building the request. The loop opens: take the reviews one at a time, and for each one do everything that follows.

The request is built exactly like the one Tessa read line by line in Chapter 7, because it is that request. Which model, then a message list with two messages in it. The first has the role system and its content is her template — the standing instructions from the last page but one, and it is worth stopping on the fact that Waymark's system prompt is a document Tessa wrote in a chapter about prompting. The second has the role user, and its content is one review. No assistant message, no history: each review is a fresh, self-contained request that knows nothing about the 2,299 others, which is why this work stays cheap.

Then the two settings from the last page. The randomness dial is set to zero — as low as it goes — because this is 2,300 repetitions of one extraction task and every gram of variation is a defect. And the length cap is set tight, just above the length of one line of labelled data, because the answer she wants is one line of labelled data and a cap is a stop against runaway output rather than an editor. Low and tight. Both choices were explained a page ago; here they are, being made.

Group three: sending, and waiting. Four lines, and they are the crudest possible version of Milo's counted beat from Chapter 7.

Send the request. Look at the status code that comes back. If it is anything other than 429, carry on. If it is 429 — the provider saying you are asking too fast — then wait twenty seconds and send the same request again, and keep doing exactly that until it goes through.

Note what it does not do. Chapter 7 said the wait should grow each time — a second, then two, then four — and this waits the same twenty seconds however often it is told to slow down. Milo knows. For a job that runs once a season against a limit it brushes rather than slams into, a fixed wait is three lines and enough; a script hammering all day would need the growing one, and that is the first thing he would change. That is the whole of the rate-limit handling — the waiting part of it is three lines, because at this scale the idea is three lines big. No error message, no red screen, no run abandoned at review 812. The provider says slow down, the program slows down, the work continues. Chapter 7 promised that a product which pauses and resumes politely was built by someone who had met these problems; this is what that looks like from the inside.

Group four: checking. Three lines, and they are Chapter 5's gauge, mechanized.

Take the model's answer — the text inside the reply — and read it as labelled data, which it should be, because the template asked for exactly that. Then ask two questions with no judgement in them. Is the category one of the four bucket names written down at the top? Is the review identifier present? If both are true the row goes into the results. If either is false, the row is not silently kept and not silently dropped: something goes into the results anyway, marked for a human to look at.

Notice what those two questions cannot do. Neither of them knows whether the answer is true. A row saying that a guest complained about the Harbourview Annex passes both checks perfectly, because "complaint" is a real bucket and the identifier is filled in. The check catches malformed and out-of-range; truth is still Tessa's department, and the next section is where she does it.

Group five: writing. One line. When the loop has been through all 2,300 reviews, write the collected results into a new file, in the same labelled format the tracker imports. The afternoon of copying and pasting from Chapter 5, ending in the same place it always ended, without the afternoon.

The Run

Tessa starts it herself, which matters to her more than she expected, and watches a counter climb.

It takes about forty minutes. Twice, the counter stalls for a stretch and then resumes — the rate limit, doing its job, in front of her, and she does not reach for anybody's phone. That is the sentence Chapter 7 said she would be able to say.

The bill for the run is knowable exactly, because every response carried a usage block and the program could add them up. Each request sent about 450 tokens — her template plus one review — and got back about 45. Across 2,300 reviews that is a little over a million tokens in and rather more than a hundred thousand out, and it comes to $2.40 for the whole season's reviews.

Worth comparing that with the trial from the last chapter, which cost $4 for a fraction of the volume. The trial was fifty reviews run through four successive versions of the template, on the biggest model, back when nobody knew whether any of this would work. The real run is the finished template, trimmed, on a smaller model chosen for the job. The difference between those two numbers is not scale. It is the three dials, which the next section is about.

Then the part that did not go away. The output file has 2,300 rows and 31 of them are flagged for a human — malformed answers, a category the model invented, an identifier that went missing. Tessa works through those by hand in twenty minutes. Then she does what she has done since Chapter 5: picks a random dozen of the rows that passed, opens the review each one came from, and reads both.

Automation did not retire that ritual and could not have. The checks in the program test shape; the dozen tests truth; and the file is now 2,300 rows with known error behaviour rather than 2,300 rows that look confident. If anything, the stakes went up: a template flaw that used to spoil fifty rows at a time now spoils all 2,300 in forty minutes.

Tessa's mother used to run the annual letter from the village association off a mail merge — one letter written once, married to a list of two hundred addresses, printing itself while she made tea. Nobody thought the printer was clever. The craft was the letter. What the machine supplied was the marriage, and it is the same machine here.

The $19 Becomes $6

One thing remains open from the last chapter, and it can be closed now. Waymark's first month on the API came to $19, itemized into three lines: $4 for the classification trial, $7 for a month of drafting, $8 for the week Tessa spent working through the 120-page contract.

Milo and Tessa re-ran that exact month's work — the same reviews, the same drafts, the same contract questions — with the three dials from Chapter 7 turned deliberately. It came to $6, and here is where each of the thirteen dollars went.

Send less: $7 of the saving. The contract week was the expensive line because one enormous conversation dragged a forty-thousand-token extract through forty consecutive questions, paying for it every single time. Re-run as a fresh conversation per section, with only the clauses that bear on the question pasted in, that $8 becomes $1. This is the largest saving on the page and it required no code, no new tool and no lost work — only Chapter 4's habit of cutting to what is relevant, and knowing that a new conversation costs nothing to start.

Receive less: $3 of the saving. The drafting month asked open questions and got generous answers: three variations where one was wanted, reasoning nobody read, a closing paragraph offering to help further. Asking for one draft in a stated length, with the cap set above it as a stop, takes that $7 to $4. Output is the expensive half of the bill, and this is the only dial that touches it directly.

Right-size the model: $3 of the saving. Sorting a review into one of four buckets does not need the largest model. Moving the classification work to a smaller, cheaper one takes the $4 trial line to $1 — and the claim that it works just as well was not taken on trust: it was checked on a sample, both models run over the same fifty reviews, the answers compared side by side. That is Chapter 5's habit protecting a cost decision, which is the shape most good cost decisions have.

One, four and one. Six dollars, for the identical month of work, at the identical quality, verified by the identical sampling.

So the arc the book has been running since Chapter 1 closes here. Nothing in a chat box: $0, and the cost hidden inside a flat subscription. First month on the wire: $19, and every dollar of it explainable. The same month engineered: $6, because cost turned out to be a design choice that a marketing coordinator who writes no code can make on purpose.

And the last thing to notice about this page is who did what. Milo wrote twenty lines in an hour. Tessa wrote the template, defined the buckets, chose the fields, found the Annex, added the vague-review rule, ran the sample, worked the flagged rows and decided the file was fit to send. She is not a programmer and this page has not turned her into one. What she is now is the person who can commission that program, read every line of it, and say precisely what it is doing to Waymark's reviews and to Waymark's money.