Output You Can Reuse

Four chapters in, the model answers Tessa well and her afternoons still have a bottleneck she has never named. She asks for the state of last week's complaints and gets back a clear, well-organized paragraph. Then she spends twenty minutes turning it into what she actually needed: three cells in the bookings tracker, one block in the newsletter template, a sentence for the operations email. The thinking took six seconds. The reshaping took a third of an hour, and it takes a third of an hour every time.

The fix is upstream of the reshaping. Stop asking for an answer, and start asking for the thing you were going to build out of the answer. Chapter 2 taught you to ask for a shape; this chapter promotes that from a trick to a policy, and then builds the three things a policy needs to hold up.

Answer or Artifact?

Two different things can come back from the same question, and it is worth having separate words for them. An answer is text you read: it informs you, and then you do something with what you now know. An artifact is a thing that slots into a place you already have — a row in the tracker, five bullets in the newsletter block, a filled-in template, a table with your columns and nobody else's. Same knowledge in both. Different shape.

The difference is not quality. Tessa's paragraph about last week's complaints was good writing. The difference is whether the output can reach its destination without passing back through her hands, and that is a property you request, not one you hope for.

Think of two kitchens. One plates every dish to order, arranged for the plate it is going on — lovely for one dinner, and slow. The other fills standard takeaway boxes, identical every time, stackable, countable, out the door by the dozen. Neither is better in the abstract; they are built for different volumes. The chat box will plate to order all day if you let it, and most office work needs boxes.

Name the Destination

The single most useful sentence you can add to a prompt names where the output is going. "This is going into the bookings tracker, which has columns date, tour, party size, and note." Not "format it as a table" — the destination, said plainly.

Naming the destination constrains the shape better than describing the shape, because a destination carries constraints that you would forget to list. A tracker column implies one value per cell, no commentary, no apology when a value is missing. Tessa never has to say any of that; she says where it is going, and the sensible consequences follow.

What she does still have to supply is what the destination looks like. The model knows what you paste and nothing else (Chapter 2) — it has never seen her tracker. So the header row goes in the prompt, and one row she filled by hand goes in under it, which is Chapter 2's shown skeleton doing its job in a new context.

And when the destination is a person rather than a file, name the person. "A short paragraph a supplier can read without knowing our internal tour codes" is a destination too, and it rules out half the drafts the model would otherwise write.

Why Identical Shape Is Worth More Than It Looks

Reshaping one review by hand is a small favour you do yourself. Getting 2,300 reviews back in identical shape is something else in kind — a system rather than a favour — and the difference lives entirely in the word identical.

Identical shape is what lets outputs stack. This week's summary sits beside last week's and the two can be compared, because the columns mean the same thing in both. A colleague's batch merges with Tessa's without anyone reconciling anything. A file of 2,300 rows can be sorted, counted and filtered, which is the only way anyone will ever get value out of a pile that size.

And identical shape is what makes output checkable. If every row has a rating between one and five and a category from your four buckets, then a wrong rating and a fifth category are things you can find without reading the row. That is the whole idea behind the last page of this chapter, and it only works because the shape held.

None of that is a programmer's concern. Stacking, comparing and handing over are what an office does with paper, and has always done. Consistency is old; only the volume is new.

What This Chapter Builds

Reuse needs three things, and the next three pages are those three things in order.

First, a shape a machine can unpack without guessing — which turns out to be one small idea, learnable in ten minutes, and the same idea that sits under every chat box in Chapter 7. Second, a prompt that produces that shape every time instead of most times, so consistency stops depending on what Tessa remembers on a Thursday. Third, a way to check a file of results that is far too big to read, because everything in this chapter is still generated text, and generated text is still capable of inventing a hotel.