So far this class has treated models as brains for text and code. But real projects arrive as screenshots, spreadsheets, phone calls, product photos, and research briefs. A language model, however eloquent, cannot hear a support call or see a broken layout. Different media need different capabilities — sometimes different models entirely.

Text is one medium among many

Say it plainly first: a large language model reads and writes *text* (including code, which is text with strict rules). Show it pixels or sound waves and it has nothing to hold onto — unless it also has the machinery to interpret that medium.

That machinery has names worth learning:

• Vision capability means the model accepts images as input alongside text: screenshots, photos, diagrams, scanned pages. It does not mean the model *generates* images — reading and generating are different jobs (more below).
• Speech-to-text turns spoken audio into written transcript. Text-to-speech turns written words into spoken audio. Different directions, different models, often confused.
• Image/video generation creates new media from a prompt. Code models read and edit code, usually inside an agent that supplies files and tools.

The durable idea: match the medium to the capability, then match the capability to the task. "Smart model" is not a medium.

The modality map

Keep this map. It answers most "which model?" questions for non-text work:

Image / video generationVision-capable modelCodebaseCoding model + agentArt promptData-capable modelCall recordingSpeech-to-text → text modelResearch briefFast or reasoning text model

Two combinations deserve emphasis because beginners merge them:

1. Screenshot analysis vs. code repair are two steps. A vision-capable model reads the screenshot and describes the bug. Fixing it inside the repo is agent work with a coding model. Often you need both in sequence: vision first ("the modal clips on small screens"), then agent plus coding model ("fix the CSS, show the diff, run the check"). One model *can* sometimes do both — many coding models now accept images — but the *jobs* remain distinct, and your verification differs (eyes on the image vs. tests on the code). 2. Transcription vs. understanding vs. narration are three steps. Speech-to-text produces the transcript; a text model summarizes it; text-to-speech narrates something new. A bad transcript poisons everything downstream, so verify the transcript on jargon and names before summarizing.

Screenshots are context (a Class 06 callback)

In Class 06's appendix you learned that screenshots are context: cropped, annotated, attached with viewport and URL. That advice returns here with a reason attached — a vision-capable model is only as good as the image you give it.

Practical rules:

• Crop tight on the problem. A full 4K desktop shrinks your bug to six pixels.
• Show the error state, not just the happy path. Include the console message or broken layout exactly as it appears.
• Say what the screenshot is: "Mobile Safari, 390px wide, logged in as a test buyer, checkout step 2." The model cannot see your browser chrome's story unless you tell it.
• For code fixes, pair the screenshot with the relevant file or component name. Vision finds the symptom; the agent still needs the address.

What a good vision prompt looks like:

Notice the last sentence: diagnose before operating. That boundary — proposal versus executed action — runs through the whole classroom.

What this lesson previews (without teaching early)

Later, the Creator / Generative Media tab will teach image, video, and audio *production* properly: prompting, iteration, licensing, and taste. This lesson is not that. Its job is narrower: make sure you never again hand a pure-text model a job that belongs to eyes or ears, and make sure you know which capability to reach for when the input is not text.

So when someone says "generate a product video," you should hear: *that is a generation task for a media model, with its own costs and review standards — not a chat question.* And when someone says "summarize this support call," you should hear: *transcribe first, verify names and numbers, then summarize the transcript.* The map does the routing; later classes teach each road.

Practical exercise: six inputs, six assignments

Take these six inputs (use your own files if you have equivalents):

1. A screenshot of a misaligned product page. 2. A spreadsheet of monthly sales with a question ("which category grew fastest?"). 3. A 5-minute supplier support call (audio). 4. A small codebase with a named refactoring task. 5. A product photo that needs a catalog description plus structured data (name, color, visible defects). 6. A 10-page research brief that needs a one-page recommendation.

For each, write: input → capability → expected output → how you will verify it.

Finish line: a six-row modality table saved in your notes. Each row names the capability (not a model brand), the output, and the verification step — e.g., "screenshot → vision-capable model → written diagnosis → I compare it against my own look at the same image."

Quick verification: for rows 1 and 4, state explicitly where the vision job ends and the coding-agent job begins. If you cannot draw that line, re-read the two-step combination above.

Common failure mode: pasting an image into a text-only model and concluding "AI can't do this." The failure was routing, not intelligence. Check the capability, not just the brand.

Check your understanding

1. Why can't a pure text model analyze a screenshot, no matter how "smart" it is? 2. What is the difference between a model that *reads* images and one that *generates* them? 3. Why is fixing a UI bug usually two jobs (vision diagnosis + coding-agent repair) rather than one? 4. What are the three steps from a support call to a summary, and which step must be verified first? 5. Given a spreadsheet, a codebase, and a script for narration — which capability does each belong to?

That completes Class 08. You can now choose a model category by task fit, read Arena without being fooled, read a model card on Hugging Face, and route each medium to the right capability. In Class 09, you learn what all of this costs in context: tokens, context windows, and why long conversations get worse — and how to keep them sharp.