Skip to content
← Catalogue Modern Skills 200 level Created by AI

Working with AI: Prompting & Large Language Models

Professor: Sikh Archive · Source: Sikh Archive

A practical, vendor-agnostic guide to getting reliable, useful work out of large language models. You will build an intuition for how these systems generate text, learn to write prompts that clearly communicate task, context, constraints, and format, and pick up core techniques such as role framing, worked…

Begin course 8 lessons · 8-question test · 80% to pass
Created by AI. Drafted with AI and reviewed for accuracy. Spotted an error? Tell us.

Lessons

1. How Language Models Actually Work (Just Enough)

A useful mental model

A large language model (LLM) is a system trained on enormous amounts of text to predict what comes next. You give it some text, and it produces a continuation one piece at a time, each piece chosen based on everything it has seen so far. You do not need to understand the math to use one well. You do need a working intuition, because that intuition explains nearly every quirk you will encounter.

Tokens: the units the model reads and writes

Models do not see words or letters directly. They break text into tokens, which are common chunks of characters. A token might be a whole short word, a fragment of a longer word, a space plus a word, or a piece of punctuation. As a rough rule of thumb in English, one token is about four characters, and 100 tokens is roughly 75 words. This matters for two practical reasons: the model has a limit on how many tokens it can handle at once, and many services price usage by tokens. Knowing this helps you estimate whether a long document will fit and why very long requests cost more.

Context: the model's short-term memory

Everything the model can consider at one time, including your instructions, any reference material you paste in, and its own reply, lives in the context window. Think of it as a desk of fixed size. If a conversation or document grows beyond that size, the oldest material falls off the edge and the model effectively forgets it. The model has no memory between separate sessions unless a tool deliberately stores and re-supplies information. When a model seems to lose track of something you said much earlier, the cause is usually a context limit rather than carelessness.

Why outputs vary

At each step the model has a probability distribution over possible next tokens, and it samples from that distribution. This is why asking the same question twice can give two different answers. Many tools expose a setting often called temperature: lower values make the output more focused and repeatable, higher values make it more varied and creative. Variation is a feature for brainstorming and a hazard for tasks that need exact, consistent results, so match the setting to the job.

What this implies for you

  • The model is predicting plausible text, not looking up verified facts. Plausible and true are not the same thing.
  • Clear, specific input narrows the range of plausible continuations, which is why good prompting works.
  • The model has no awareness of events after its training cutoff unless given current information, and it cannot truly know what it does not know.

Hold on to one sentence: the model is a very capable pattern continuer, not an oracle. Every later lesson is an application of that idea.

2. The Anatomy of a Good Prompt

What a prompt really is

A prompt is the instruction you give the model. Because the model continues whatever you provide, the quality of your input largely determines the quality of the output. Vague prompts produce generic results; precise prompts produce useful ones. Strong prompts tend to contain up to five ingredients.

1. A clear task

State exactly what you want done, using a concrete verb. Compare tell me about marketing emails with write three subject lines for a marketing email announcing a 20 percent discount. The second leaves little room for the model to guess.

2. Context

Give the background the model needs but cannot infer: who the audience is, what the goal is, any relevant facts or prior decisions. The audience is existing customers who have not purchased in six months changes the output far more than the task verb alone.

3. Constraints

Spell out the boundaries: length, tone, reading level, what to include, and what to avoid. Keep each line under ten words, friendly but not pushy, and do not use exclamation points turns a loose request into a controlled one.

4. Examples (when helpful)

Showing one or two samples of what good output looks like is often more effective than describing it. If you have a brand voice or a specific format in mind, a single example communicates it instantly. This is covered in depth later.

5. Desired format

Tell the model how to structure the answer: a bulleted list, a table, JSON, a short paragraph, a numbered procedure. If you plan to paste the result somewhere specific, name that target so the structure fits.

Putting it together

A complete prompt might read: You are helping a small bakery. Write three email subject lines (task) for customers who have not ordered in six months (context). Each must be under ten words, warm, and free of exclamation points (constraints). Return them as a numbered list (format). Notice how each ingredient removes a source of ambiguity.

Start simple, then add

You do not need all five ingredients every time. For quick questions, a clear task is enough. Add context, constraints, examples, and format as the stakes and complexity rise. A practical habit: write the simplest prompt first, look at what is wrong with the result, and add the ingredient that fixes it.

3. Core Technique 1: Roles, Instructions, and Format Control

Shaping the model with framing

Once you can write a clear prompt, you can steer the output more deliberately. The first set of techniques is about framing: telling the model what perspective to take and exactly how to respond.

Role and persona framing

Assigning a role primes the model to draw on a particular style and body of patterns. You are an experienced copy editor tends to produce more careful, precise edits than no framing at all. Explain this as if to a curious twelve-year-old shifts vocabulary and pacing. Roles are most powerful when they carry concrete expectations about tone, depth, and priorities. A vague role like you are an expert does little; a specific one like you are a tax preparer who flags risky deductions does a lot.

Instruction clarity over politeness

The model responds to clear directives. Phrases such as list only, do not explain, limit to 100 words, or if information is missing, say so rather than guessing reliably shape behavior. Positive instructions (do this) usually work better than negative ones (do not do that), so when you can, describe the result you want rather than only the result you fear.

Controlling format precisely

When the output needs to plug into something else, be explicit and, ideally, show the shape. Asking for a table with columns Name, Role, and Status is good; providing one example row is better. For machine-readable output, name the format and the exact fields, and ask for nothing outside it: Return only valid JSON with keys title and summary, no surrounding text. Extra commentary is a common reason automated pipelines break.

Order and emphasis

Instructions placed at the very beginning or the very end of a prompt tend to carry the most weight, and material in the long middle of a very large prompt gets the least reliable attention. Put the most important constraint where it will not get lost, and repeat a critical requirement if you truly need it honored.

A quick checklist

  • Did you assign a role only when it adds a concrete perspective?
  • Are your instructions stated as actions to take?
  • Did you name the exact output format and fields?
  • Is the single most important constraint impossible to miss?

4. Core Technique 2: Examples and Step-by-Step Reasoning

Teaching by showing and slowing down

Two of the most reliable ways to improve output are to show the model what you want and to ask it to reason before it answers.

Few-shot examples

Providing a handful of input-output examples is called few-shot prompting (zero examples is zero-shot). Examples are especially effective for format, tone, and edge cases that are hard to describe in words. To classify support messages, you might show: Message: My package never arrived. Category: Shipping. followed by Message: I was charged twice. Category: Billing. Then supply a new message and ask for its category. The model infers the pattern from your examples.

Good examples are representative, varied enough to cover the cases you care about, and consistent in format with each other. If your examples disagree with your written instructions, the examples usually win, so keep them aligned. Two or three well-chosen examples often beat a long verbal description.

Step-by-step reasoning

For problems that involve multiple steps, math, logic, or careful analysis, asking the model to work through its reasoning before giving a final answer improves accuracy. A simple cue such as think through this step by step before answering prompts the model to lay out intermediate steps rather than leaping to a conclusion. Because the model builds each token on the ones before it, written-out reasoning gives it a better foundation than an immediate guess.

When you only want the final answer but still want the accuracy benefit, you can ask the model to reason internally or in a separate section and then present a clean conclusion: Work out the steps, then give only the final number on the last line.

Decomposing hard tasks

If a request is large or tangled, break it into stages and let the model handle one at a time: first outline, then draft a section, then revise. This keeps each step focused and makes errors easier to catch. You can do the stages in one prompt as a numbered sequence or across several turns of a conversation.

When to use which

  • Use examples when format and style matter or when the category is fuzzy.
  • Use step-by-step reasoning for calculation, logic, and analysis.
  • Use decomposition when a task is too big to do well in one pass.

5. Core Technique 3: Iterating and Refining

The first answer is a draft

The most common mistake new users make is treating the model's first response as final. Skilled users treat it as a starting point and steer toward what they want through a short conversation. Iteration is not a sign of a bad prompt; it is the normal way good results are produced.

Refine, do not restart

Because the conversation stays in context, you can build on what the model already produced. Instead of rewriting your whole prompt, give targeted follow-ups: Make the second paragraph shorter and more concrete. That tone is too formal; loosen it. Keep the structure but replace the example with one about healthcare. Each correction reuses the prior work and nudges it closer to the goal.

Diagnose before you correct

When output is wrong, name the specific problem before asking for a fix. Is it too long, off-topic, too generic, missing a constraint, or factually shaky? The clearer your diagnosis, the more precise your follow-up. This is too generic; add two specific data points and a concrete example works better than make it better.

Steering levers you can pull

  • Length: ask for a specific word or item count.
  • Specificity: ask for concrete examples, numbers, or names.
  • Tone: name the feeling you want and a feeling to avoid.
  • Focus: tell it what to cut and what to expand.
  • Alternatives: ask for two or three different versions, then combine the best parts.

Generate options, then converge

For creative or strategic work, ask for several distinct approaches before committing. Variety early gives you raw material; you then narrow down by asking the model to develop the most promising option. This mirrors how good human work happens: diverge, then converge.

Know when to start fresh

Sometimes a conversation accumulates so many corrections and dead ends that the context is cluttered and the model keeps repeating old mistakes. When follow-ups stop helping, it is often faster to open a clean session and write one improved prompt that folds in everything you learned. Iteration includes knowing when to reset.

6. Structuring Longer Work and Supplying Reference Material

Beyond one-shot questions

Quick prompts handle small tasks. Larger projects such as reports, analyses, or drafts grounded in specific documents need more structure and, often, source material you provide yourself.

Give the model the facts it needs

The model only knows its training data plus whatever you put in the context. For anything specific to your situation, recent events, or private documents, you must supply the material. Paste in the relevant text, notes, data, or policy and instruct the model to base its answer on that material: Using only the report below, summarize the three main findings. This grounding both improves accuracy and reduces invented content.

Separate instructions from source clearly

When you mix your instructions with pasted material, mark the boundary so the model does not confuse the two. A simple convention works well: label the reference with something like --- SOURCE --- and place your instructions clearly above or below it. This also reduces the chance that text inside a document is mistaken for a command to follow.

Work in stages for long outputs

A long document is better built in pieces than demanded all at once. A reliable sequence is: ask for an outline, review and adjust it, then have the model draft each section against the agreed outline, then revise for consistency and flow. Staging keeps each step within a manageable size, gives you control points, and avoids the quality drop that long single-shot generations can suffer.

Mind the context budget

Reference material, instructions, and the growing reply all share the same limited context. If you paste a very large document, the model may attend less reliably to the middle of it, and a long back-and-forth can crowd out earlier material. Practical responses: include only the relevant portions, summarize sections you do not need verbatim, and for big bodies of text process them in chunks and then combine the chunk results.

Carry state deliberately

Across separate sessions the model remembers nothing. If a project spans multiple sittings, keep your own running summary of decisions, requirements, and the current draft, and paste the relevant parts back in when you resume. You are the project's memory; the model is the worker you brief each time.

7. Failure Modes and How to Verify Output

Trust, but verify

LLMs are fluent, which makes their mistakes dangerous: errors arrive in confident, well-formed prose. Knowing the common failure modes lets you catch them.

Fabrication (hallucination)

The model can invent facts, citations, quotes, names, and statistics that look entirely real. This happens because it generates plausible text, and a fake citation is often more plausible-sounding than admitting ignorance. Treat any specific claim, especially names, numbers, dates, legal or medical points, and references, as unverified until you check it against a trustworthy source.

Outdated information

Without current data supplied to it, the model's knowledge stops at its training cutoff and it may not know recent developments. It can also state old information as if it were current. For anything time-sensitive, confirm against an up-to-date source or give the model current material to work from.

Confident wrongness and sycophancy

The model rarely signals uncertainty on its own, and it tends to agree with the framing of your question. If you ask a leading question, it may confirm a false premise. Phrase questions neutrally, and when a claim matters, ask the model to argue the other side or to identify what would make its answer wrong.

Subtle errors in structured work

In code, math, and data, output can look correct yet contain a flaw: an off-by-one error, a wrong unit, a misattributed quote. Fluency does not guarantee correctness. Run code, recompute key numbers, and spot-check transformations.

Misreading or ignoring instructions

Long or crowded prompts can lead the model to drop a constraint or follow part of an instruction. If a requirement is critical, state it prominently and check the output against it explicitly.

A verification habit

  • For facts: confirm specifics with an independent, reliable source.
  • For reasoning: read the steps, not just the conclusion.
  • For code and data: execute and test rather than eyeballing.
  • For high stakes: get a second opinion, human or a fresh model session.
  • Match scrutiny to consequences: low-stakes brainstorming needs little, anything published or acted upon needs real checking.

8. Responsible Use and an Everyday Workflow

Using AI well and ethically

The same fluency that makes LLMs useful also makes careless use easy. A few principles keep your work honest, safe, and reliable.

Protect privacy

Be deliberate about what you put into a model. Avoid pasting sensitive personal data, confidential business information, secrets, or anything covered by a legal or contractual duty unless you know how the service handles and retains data and you are permitted to share it. Once submitted, you may not control where that text goes. When in doubt, redact or paraphrase.

Attribute and stay honest

Be transparent when AI materially produced work that others will judge as yours, especially in academic, professional, and journalistic settings, and follow the rules of your institution. AI output can also echo copyrighted or proprietary phrasing, so review and substantively make the work your own rather than passing along verbatim generation. Take responsibility for what you publish; the tool does not.

Do not over-trust

Keep the human in the loop for consequential decisions. The model is an assistant, not an authority. For medical, legal, financial, or safety matters, treat its output as a starting point to discuss with a qualified professional, not as advice to act on directly. Always verify facts before you rely on them.

Watch for bias and harm

Models learn from human text and can reproduce its biases and blind spots. Review output for unfair assumptions or stereotypes, particularly when it touches people, groups, or decisions that affect them.

A practical everyday workflow

  1. Define the task. Decide what done looks like before you prompt.
  2. Gather context. Collect the facts, documents, and constraints the model will need, and note what is sensitive.
  3. Write a clear first prompt. Include task, context, constraints, and desired format; add examples if format or tone matters.
  4. Review the draft critically. Check it against your constraints and look for fabrication, outdated claims, and subtle errors.
  5. Iterate with targeted follow-ups. Diagnose the specific problem and steer; reset to a clean session if it gets cluttered.
  6. Verify what matters. Confirm facts, run code, recompute numbers, scaled to the stakes.
  7. Finalize and own it. Make the work genuinely yours, attribute as required, and take responsibility for the result.

Used this way, an LLM becomes a fast, tireless collaborator that amplifies your judgment rather than replacing it. The skill is not in the tool; it is in how clearly you direct it and how carefully you check it.

Course test

Pass with 80% or higher to complete the course and unlock the next one.

1. Why can asking a language model the exact same question twice produce two different answers?
2. What does the context window of a language model determine?
3. Which of these is the strongest example of a well-specified task in a prompt?
4. What is the main benefit of giving the model a few input-output examples (few-shot prompting)?
5. For a multi-step math or logic problem, which technique most improves accuracy?
6. When a model's first response is close but not quite right, what is usually the best next move?
7. What is hallucination in the context of language models?
8. Which practice best reflects responsible use of an LLM?

Read the source texts

Read the primary sources for yourself — the Gurbani in our read-along reader, and the original works in the source library.

Rate this course

Discussion & Q&A

Sign in to post.