hawkes.aiKey ideas
- The one idea — Because a stateless model only knows what's in its context, the context you assemble is the software — prompting is programming in English.
- How it is shown — The context window shown as a program — instructions, data, examples, history — all assembled to determine behavior; fixing outputs by editing the program.
- The trap to avoid — Treating prompts as magic incantations instead of an engineered context — behavior comes from what's in the context, not secret words.
- What it sets up — A program has structure — and the context's structure starts with roles.
There are no magic words. The model's behavior comes entirely from what's in its context — which means you can debug a prompt like code. Add what's missing.
The one idea
Because a stateless model only knows what's in its context, the context you assemble is the software — prompting is programming in English.
Here's the reframe that changes everything. Because the model is stateless and only knows what's in its context, whatever you put there completely determines what it does. So the context isn't a conversation — it's a program in plain English. You're not chatting with the model. You're programming it. Think of the context window as the model's entire world for one call: instructions on how to behave, data to work on, examples of what good looks like, the history so far. You assemble all of it, and that assembly is the software that runs. The prompt is source code. This reframe is freeing. If behavior comes from the context, fixing a bad output isn't about begging the model — it's editing the program.
How it works — the demo
The context window shown as a program — instructions, data, examples, history — all assembled to determine behavior; fixing outputs by editing the program.
Add a missing instruction. Include an example. Give it the data it lacked. You debug a prompt like code: find what's missing in what you fed it, don't just hope harder. That's what prompt engineering actually means — not magic words, but engineering a context. Structure the instructions, supply the right data, show examples, order it well. The people who get the most from AI aren't better chatters; they're better context-builders. This works only because the model is stateless. A pure function means one context reliably produces consistent behavior — identical at temperature zero — so you can craft, test, and reuse it like code. Episode one-sixty-seven's amnesia is exactly what makes the context a dependable program.
The trap to avoid
Treating prompts as magic incantations instead of an engineered context — behavior comes from what's in the context, not secret words.
Why it matters — and what’s next
A program has structure — and the context's structure starts with roles.
Statelessness isn't the obstacle to control; it's the foundation. The trap: treating prompts as magic incantations — hunting secret words that unlock the model. There are none. Behavior comes from the context's contents: the instructions, data, and examples you provide. "Please" and "you are an expert" aren't spells; they're weak substitutes for giving the model what it needs. Engineer the context, don't chant at it. So the prompt is the program, the context is your software, and prompting is engineering it. But a program has structure — and the context has a hidden one. Those messages aren't a flat list; they come in labeled roles — system, user, assistant — that quietly shape everything. Next: system, user, and assistant roles.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:30 of narration
Here's the reframe that changes everything. Because the model is stateless and only knows what's in its context, whatever you put there completely determines what it does. So the context isn't a conversation — it's a program in plain English. You're not chatting with the model. You're programming it.
Think of the context window as the model's entire world for one call: instructions on how to behave, data to work on, examples of what good looks like, the history so far. You assemble all of it, and that assembly is the software that runs. The prompt is source code.
This reframe is freeing. If behavior comes from the context, fixing a bad output isn't about begging the model — it's editing the program. Add a missing instruction. Include an example. Give it the data it lacked. You debug a prompt like code: find what's missing in what you fed it, don't just hope harder.
That's what prompt engineering actually means — not magic words, but engineering a context. Structure the instructions, supply the right data, show examples, order it well. The people who get the most from AI aren't better chatters; they're better context-builders.
This works only because the model is stateless. A pure function means one context reliably produces consistent behavior — identical at temperature zero — so you can craft, test, and reuse it like code. Episode one-sixty-seven's amnesia is exactly what makes the context a dependable program. Statelessness isn't the obstacle to control; it's the foundation.
The trap: treating prompts as magic incantations — hunting secret words that unlock the model. There are none. Behavior comes from the context's contents: the instructions, data, and examples you provide. "Please" and "you are an expert" aren't spells; they're weak substitutes for giving the model what it needs. Engineer the context, don't chant at it.
So the prompt is the program, the context is your software, and prompting is engineering it. But a program has structure — and the context has a hidden one. Those messages aren't a flat list; they come in labeled roles — system, user, assistant — that quietly shape everything. Next: system, user, and assistant roles.