Most writing about AI models sits at one of two extremes: breathless hype, or reflexive doom. This page is neither. It is a running, practical set of notes for people who want to understand the tools they are using and use them without handing over the parts that should stay human — judgment, responsibility, and the work of actually understanding a problem.
That is the whole point of this site. The performance-engineering work here is about knowing, not just doing — reading the roofline instead of guessing, measuring instead of asserting. Using an AI model well asks the same discipline. A model can produce an answer faster than you can check it; the human skill is staying in the loop well enough to know when it is wrong, and honest enough to say when you can't tell.
This page grows over time. Entries run in chronological order, earliest first. None of them require you to be an AI researcher — they require you to be a careful person.
What a model is — and what it is not
2026-07-25
A large language model is a function that, given some text, predicts plausible continuations of it. That is a smaller claim than the marketing suggests and a larger one than the skeptics admit. It is smaller because the model has no beliefs, no stake in being right, and no memory of you beyond what is in front of it. It is larger because "predict plausible text" turns out to cover a startling amount of useful work — drafting, translating, restructuring, explaining, catching your own blind spots.
The single most useful mental model: treat the output as a confident draft from a fast, widely-read, slightly unreliable colleague. You would not paste that colleague's work into production without reading it. You would, however, be foolish to refuse the help. Both halves matter.
Three things follow directly, and they are the spine of everything else on this page:
- A model is a draft, not an authority. It is optimized to sound right, which is not the same as being right. The two usually coincide; the danger is entirely in the gap between them, and the gap is invisible unless you look.
- Fluency is not knowledge. A confident, well-formatted, plausible paragraph is the model's default output whether or not the underlying claim is true. Nice prose is not evidence. Verify anything that would cost you if it were wrong.
- You own the result. The model has no responsibility and cannot carry any. If you ship it, sign it, or act on it, it is yours. "The AI said so" is not a defense a human should be willing to give.
Using one humanely — a working definition
2026-07-25
"Humanely" here is not a mood; it is a set of habits. Using a model humanely means using it in a way that leaves the humans involved — you, and anyone affected by what you produce — better off, more capable, and more in control, not less.
In practice that is:
- Stay in the loop where it matters. Automate the keystrokes, not the judgment. Let the model draft the boilerplate; you keep the decision about whether the boilerplate is correct and whether it should exist at all.
- Use it to understand, not to skip understanding. The best use of a model is as a tutor that answers your follow-up questions at 2 a.m. — it grows what you know. The worst use is as a way to ship something you couldn't have written and can't now explain. One makes you more capable next time; the other makes you more dependent.
- Keep people in the picture. If the output touches other humans — a hiring note, a medical question, a message to a colleague — remember there is a person on the other end who deserves your judgment, not a model's autocomplete.
- Be honest about the seams. Say when something is AI-assisted where that matters. Don't pass off a model's confidence as your own knowledge. The integrity cost of pretending is real and it compounds.
The through-line: a model is worth using when it makes you more of a careful, capable human, and worth putting down when it is quietly making you less of one.
A worked example: "Is everything really just tokens?"
2026-07-25
Here is a real exchange, used the way this page argues for. The question, roughly: do all closed AI models bill and think in tokens, and is tokenization the only way to feed data into a model? It is a good question to bring to a model — broad, with a real answer, and it rewards structure over recall.
What the model gave back (condensed):
- Tokens are a billing and interface convention, not a law of nature. Closed LLMs (OpenAI, Anthropic, Google) do tokenize text internally — but a token is a proxy for compute cost, not the "true" unit of thought.
- Three things that are easy to conflate actually come apart:
- Billing — text is usually per-token, but audio is often billed per minute (Whisper), video per minute, and images as a fixed "image-token" equivalent.
- Internal representation — how the model encodes what you gave it.
- Input strategy — and here there are real, named alternatives:
- Byte-level models — ByT5, CANINE, Charformer, MEGABYTE, Byte Latent Transformer — drop the tokenizer and read raw UTF-8 bytes (a 256-value vocabulary). Robust to typos, rare words, and many languages; the cost is 4–5× longer sequences, which newer work (MrT5) claws back by merging.
- State-space models — Mamba, S4 — carry a continuous internal state instead of attending token-to-token, giving linear-time long-context handling.
- Patches — vision transformers cut an image into 16×16 patches, not text tokens.
- Spectrograms — audio models turn sound into a time-frequency image.
- Its summary line: tokenization is the "general-purpose GEMM" of model input — it works everywhere and is optimal nowhere; pick the encoding to fit the data.
That is a genuinely useful answer. Now the human part — the reason it is here.
How to read it — humanely:
- The load-bearing claims are checkable, and they hold. Byte-level models, SSMs, patch and spectrogram encodings are real, named, and findable. That is the test whenever a claim will feed a decision: can you name it and look it up? These pass — and the fact that they pass is something you confirm, not something you assume because the prose was tidy.
- The confident specifics are where to slow down. The same answer names exact future model versions and prices in the same even voice — "GPT-5.6", "Claude Fable 5", "images ≈ 170 text tokens", "by 2027 billing moves off tokens." Some of that is real, some is extrapolation. The model does not mark the seam between what it knows and what it is guessing — you have to. Treat named versions, prices, and dated predictions as to-verify, not settled.
- The analogy is a teaching tool, not a proof. "Tokenization is the general-purpose GEMM" is a great way to hold the idea — but an analogy persuades whether or not it is apt. Use it to understand; don't cite it as evidence.
- The best tell is what it left you able to do. The exchange ends by offering three deeper paths. The value is not that the model will choose for you — it is that you now know enough about the option space to choose yourself. You came out more capable of deciding, not more dependent on being told. That is what a good use of a model looks like.
The lesson generalizes well past tokenizers: a good answer and a verified answer are not the same answer, and the gap between them is exactly where your judgment earns its keep.
How these machines actually work
2026-08-09
Using a model humanely is easier when you know what it is doing under the hood. These four walk-throughs open the box — from the text-LLM pipeline to the wider family of models that do not touch language at all:
- It's Numbers All the Way Through: From Prompt to Token — the full LLM pipeline from prompt to token to vector to sampled output; where symbols and numbers trade sides, and the one place anything random happens.
- The Tokenizer Tax — why tokenization is really a compression scheme that quietly decides what a prompt costs and what the loss is even measured in.
- The Denoising Engine — how diffusion models build an image from pure noise, a mechanism with no tokens and no autoregression at all.
- Beyond Tokens: The Model I/O Zoo — the map: every other model family (vision, audio, graphs, neural fields, embeddings) organized by where symbols and numbers trade sides.
And three cartoons — glossary-first, fully-disclosed visual explainers. Each opens with a decoder ring that defines every term on the page, so the acronyms are gone before the pictures start:
- How an AI Answers "Why Are Pickles Wiggly?" — eight panels tracing one question through a real tokenizer (genuine GPT-2 token IDs), the transformer, the decode loop and back to English — then asking the same question of an agent, to show what the loop adds and what it costs. The visual companion to From Prompt to Token.
- What Is an "Expert," Really? — a mixture-of-experts is just spare copies of the feed-forward block, and a router picks a few per token. In four panels.
- The MoE Batch Valley — why batching is free capacity for a dense model but a mixture-of-experts has a mid-batch cost valley. Decode-step economics, drawn.
And the write-up that ties the pictures to the machine: Know, Do, Decide — ask a plain model why pickles are wiggly and it answers in a second, all on the GPU; ask an agent and you get three GPU visits separated by CPU work and waiting, for the same sentence. Which is the clearest way to see that an agent is not a hardware tier at all — it is a loop that runs on the CPU, rents the GPU by the lap, and mostly waits.
A companion tool: deciding under uncertainty
2026-07-25
Everything above rests on one skill — knowing how much to trust a claim. That skill has a formal side, for when your evidence is a sample rather than the whole story. Here is a hands-on, dependency-free explainer for the everyday version of that problem: deciding yes/no when your tests don't cover everything. It walks through percentiles, the point-estimate-vs-confidence- interval decision (Wilson, Wald, Clopper–Pearson), an animated flaky-signal demo, and where it all sits inside uncertainty quantification — the discipline of being honest about what you don't know.