Leapfrog Contents PDF

Interlude

Ship Something Tiny This Week

Stop reading. Close one small loop end to end, before the deep chapters explain what you just did.

Placed here on purpose. You’ve read enough. Before we go deep on operating, scaling, and securing these systems, put the book down and ship something — small, imperfect, real. The point isn’t what you build. It’s crossing the line from reader to builder, and feeling the whole loop once before we make it robust.

You’ve now got the why (Chapters 1 and 2) and most of the how (Chapters 3 through 7). The temptation is to keep reading until you understand everything, and then build. That instinct is the exact deferral this whole book argues against. So this is a deliberate pause: a single end-to-end build you can finish this week, with the training wheels firmly on. Do it before you read the operating chapters, and those chapters stop being theory — they become upgrades to a thing you already have in your hands.

The rules of the tiny build

Keep it honest and keep it small. Pick one real workflow — not a demo, not a chatbot for its own sake, but a genuine slice of work someone actually does. Pick one you’re allowed to touch, and one where you can tell whether it worked. Then time-box it: an afternoon, maybe two. Training wheels on means a hosted model through an API, the smallest slice of real data that’s meaningful, and no infrastructure heroics. You are not building a product this week. You are closing a loop.

The thin slice

Walk the shape below; the step-by-step with working code lives in the leapfrog.lerias.org labs. This is the map; the site is the lab.

1. Pick the workflow and define “better.” One task, one improvement you could actually measure (Chapter 2). Before you write a line, write down what delivered and better mean here — the honest baseline and the target (Chapter 1’s first experiment). If you can’t say what better looks like, you can’t tell if you succeeded.

2. Make one real call. Send one real input from that workflow to a hosted model’s API and read your meter — the input tokens, the output tokens, the cost (Chapter 5). It’s a small moment, but you’ve now touched the material directly instead of reading about it.

3. Ground it in a little real data. Take a handful of your real documents, do the simplest retrieval you can (even the naive version), and feed the model the relevant context (Chapters 6 and 7). Watch it get more useful — and pay attention to where it still fails. That failure is the map of what the deeper chapters are for.

4. Make it do one real thing. Have it return a structured output your code can act on, or make one tool call that performs one genuine action (Chapter 6). The moment it produces something the surrounding system uses, it stops being a chat and becomes embedded in the work — rung two of Chapter 2’s ladder, reached for real.

5. Put a tiny check and a tiny bound on it. One small eval on a handful of cases: does it do the thing acceptably (Chapter 9, in miniature)? And one control: scope its access to the minimum, cap what it can spend or loop, and route anything irreversible past a human (Chapter 8, in miniature). Even at toy scale, feel the shape of evaluation and containment. They’re easier to add now than to retrofit later.

6. Show it to one real user. The person who actually does this workflow. Watch them use it. Their reaction is your truest evaluation, and it will tell you more in five minutes than another chapter would.

What you just did

You just felt the entire loop this book is about — access, cost, grounding, action, evaluation, control — end to end, at a scale small enough to hold in your head. Chapters 8 through 10 are how you make that loop robust and affordable at scale; Chapter 11 is how you make it safe. All of it will land differently now, because you have a concrete thing to hang it on instead of an abstraction.

And here’s the part that matters most. The gap between the five percent who deliver AI and the ninety-five percent who don’t was never knowledge. It’s having shipped. You just shipped — something small, imperfect, and real. Do that before you finish the book, and you’ve already done the hardest thing the corporate trap kept telling you to defer. The rest is upgrades.

Experiment or die. This week. Something tiny. Go.

Experiments

One workflow, one afternoon, training wheels on.

  1. Pick the workflow & define “better.” One real task you’re allowed to touch and can measure. Write down the baseline and the target first.
  2. Make one real call. Send a real input to a hosted model and read your meter — tokens in, tokens out, cost.
  3. Ground it in a little real data. Feed it a handful of your own documents with the simplest retrieval. Watch where it helps and where it fails.
  4. Make it do one real thing. A structured output your code acts on, or one tool call. Now it’s embedded, not a chat.
  5. Add a tiny check & a tiny bound. One eval on a few cases; least privilege, a cap, a human on anything irreversible.
  6. Show one real user. The person who does this workflow. Their reaction is your truest eval.