Beyond the Prompt

The result may be a weekly update, a meeting brief, a comparison of supplied options, or a short set of instructions. Its size matters less than its connection to a real need. A paragraph that prevents misunderstanding can be more valuable than a ten-page document no one uses. Choose work whose quality you can examine, rather than work whose volume you admire you can admire.

You do not need to become a programmer. You do need to become an attentive editor of the task itself. That means deciding what information belongs in it, what must remain uncertain, what the AI is allowed to produce, and what evidence will support your decision to use the result. These are familiar workplace judgments applied more deliberately.

There is no promise that an AI-assisted method will improve every task. Sometimes you will discover that collecting the context takes longer than doing the work yourself. Sometimes a first output will introduce mistakes that your existing method avoided. Keeping that evidence is part of learning. The book's capstone asks for a demonstrated improvement; if your task has not improved, you will identify a next test instead of declaring victory because you completed a worksheet.

Choose a route you can actually complete

The first route uses a manageable task from your work. Choose material you are permitted to use in your selected tool, and make sure you can check the result. You do not need confidential records. A public event announcement, a deliberately anonymized practice brief approved for that use, or a task built from non-sensitive material can provide enough substance.

The second route uses the complete fictional case in this book. Harbor Community Services is preparing a pilot of a new onboarding guide, called Cedar. Maya Chen coordinates its weekly update. Elena Ruiz, the sponsor, and the team leads need to see what has happened, what is approved, and what still requires action. You will receive all the notes needed to do the task. You can use them in one suitable AI tool or work through the supplied outputs offline.

The offline route supports practice in task definition, evaluation, diagnosis, and workflow design. It does not show how a tool you have never used performs. If you analyze the book's outputs instead of running your own prompt, write “supplied simulation” in your record. Before using your own AI workflow at work, test that actual setup with appropriate material. A carefully analyzed example and an observed run are different kinds of evidence.

You may switch from the fictional case to your own work after learning the method. Keep the two portfolios separate. Otherwise a good evaluation of Cedar might appear to support a different task whose sources, audience, and failure conditions you have never examined.

A few words we will use

A task is a bounded piece of work with a purpose and an inspectable result. A prompt is the instruction you give the AI. Context is the relevant background, evidence, examples, and constraints you supply. An output is what comes back. An evaluation compares that output with requirements you have already chosen.

The tool is the application or service through which you work. The model is the underlying system generating the response. A tool may expose a model name, offer several choices, or show very little about what is running. Record what you can see and mark the rest unknown. Do not infer a precise model identity from a friendly product label.

A workflow includes the events before and after the AI task: somebody collects the notes, somebody checks the draft, somebody approves it, and somebody uses it. The prompt is one part of that sequence. A strong prompt cannot supply an approval that nobody has given or repair a source document that omits the necessary fact.

The term evidence will mean something you can inspect: a source passage, a saved output, a recipient's answer to a check, or a timing record. An AI statement that it followed your instructions is not independent evidence that it did so. Generative systems can produce confidently expressed errors, including apparently supporting explanations and citations. NIST identifies this problem in its discussion of confabulation. Source N1, section 2.2.

What to keep beside you

You need a place to save text, your source material, and your evaluation records. An ordinary folder or document is enough. You do not need a database, a paid comparison service, or several subscriptions. If you have a suitable tool, use one you are permitted to use and can inspect. If model settings or usage information are hidden, the method still works: record that limitation.

Create a portfolio named for the task. Inside it, keep the task brief, context, step map, rubric, exact prompts, outputs, evaluations, comparison, reliability boundary, and task card. Use simple version names: context C1, prompt P1, output O1, revised prompt P2, output O2. Never overwrite an earlier attempt merely because a later one looks better. Your improvement claim needs both.

The exercise IDs TASK-01 through TASK-08 identify the eight portfolio milestones. Each chapter tells you what to save. The separate learner resource pack provides clean forms and completed case examples with the same IDs. The case files contain copyable source records, prompts, and outputs. Everything needed for the learning is also explained in the manuscript; no website is required to understand the method.

Work at a pace that lets you inspect the evidence. You can read a chapter, complete its artifact, and return later. Keep unresolved questions in the artifact so that returning does not require reconstructing your memory. A useful note might say, “Need to confirm whether the date is a target or an approved commitment,” rather than “Check this.” The first tells your future self exactly what is missing.

Read the examples with their evidence labels

All Harbor Community Services documents, people, dialogue, source notes, and workplace outcomes are fictional. The first and revised AI outputs are author-constructed simulations. They were designed to reveal different evaluation problems; they are not transcripts of actual model runs. The comparison times are invented arithmetic examples, not productivity findings. No product ranking or measured saving follows from them.

The book distinguishes checking a constructed text against its supplied fictional sources from testing a real AI system. We can inspect whether a sentence matches S4. That does not establish how often a particular model would produce that sentence, how a real recipient would interpret it, or how much time a real organization would save. These distinctions make the case useful without asking it to prove more than it can.

Feedback, human review, and the companion

The intended companion journey is purchase, access code, exercises, preliminary feedback, review where provided, and revision. Consult the publisher's current information for whether a service is available and what your access includes. This book does not depend on a promised response time, a particular account feature, unlimited reviews, or certification.

Whether you use a service or a colleague, distinguish feedback from assessment. Feedback proposes what to inspect or improve. Assessment judges the evidence against a stated standard. AI feedback can help locate a possible omission; it cannot make an unsupported claim true. A human review is independent only when a separate person actually examines the relevant evidence. Self-review remains valuable, but describe it accurately.

If you disagree with feedback, preserve the original comment, point to the relevant source and criterion, and request reconsideration. Later you will see a complete example of a learner challenging an AI interpretation and a human correcting it. The point is not to obtain a favorable label. It is to make the reason for the judgment visible.

You are ready to begin when you have one possible task, a place to keep its record, and a willingness to judge the result by what it enables someone to do.

End of chapter one. 11 more chapters and about 25,293 words in the full book.