If you can ship ordinary software, you can start building with large language models. I would not start in the API console. I would learn five ideas in this order: machine learning, what an LLM is, generative AI versus older predictive AI, prompting, then evaluation. Each one has a small thing to try in code before you depend on a vendor SDK.
What should I learn before I call a model?
In traditional software, a programmer writes the rules. Machine learning works the other way: you show a model many examples, and a training process adjusts it until its predictions match those examples. The rules end up in learned parameters, not in a document you can read.
Deep learning is the branch that uses neural networks with many layers, and it sits behind almost all recent AI progress. Large language models are deep learning models trained on text. The practical consequence is the same as for any machine learning system: the model is only as good as the data it learned from, and it can be confidently wrong on cases unlike its training data.
What to try: encode the fraud-style rule from that definition (amount over a threshold and a new country), then replace the rule with a weighted sum you chose by hand. You are not training a model. You are seeing that the "decision" is numbers, and those numbers only mean something relative to examples.
What is an LLM actually doing?
A large language model reads text as tokens and, given everything so far, predicts the next one. Repeat that and you get a paragraph. "Large" refers to the size of the neural network, measured in parameters, and to the amount of text it learns from in pre-training. Post-training then teaches it to follow instructions and hold a conversation.
Because the model is built to produce plausible text, it can be fluent and wrong at the same time. On its own it also does not know about events after its knowledge cutoff, or about your private data. Most useful products wrap the model in more: retrieved documents, tools, memory, and checks.
Dan Klein, co-founder and CTO of Scaled Cognition, argues that what people are using are plausibility engines: they assemble plausible outputs token by token. That is a strong way to get a prototype, and a weak way to get behavior you can guarantee.
What to try: give yourself a four-word vocabulary and a function that returns the highest-scoring next token. Loop it ten times from a fixed prefix. Read the string you get and notice that nothing in the loop checked the sentence against a source of record.
How is generative AI different from predictive AI?
Much of the AI in business before 2022 was predictive: a model looked at an input and gave back a label or a number, such as fraud or not fraud, or a demand forecast. Generative AI produces something new instead: a paragraph, an image, a song, a block of code. Large language models generate text. Image, audio, and video models generate media, and multimodal models handle several of these at once.
Generative AI and agentic AI are related but not the same. A generative model produces content when asked. An agent uses a generative model to plan and take actions toward a goal, calling tools and checking results along the way. I would get comfortable with the generator before I tried to build the agent.
What to try: take one short support ticket and return two values from separate functions. One is a label, such as billing or access. The other is a drafted reply. The label is the older predictive job. The draft is the generative job. If you mix them in one return value, you will start treating a guess at a category as if it were a finished answer.
What should I practice in the prompt?
Prompt engineering is the craft of the instruction itself: how you phrase the task, what examples you include, what format you ask for, and how you structure the request. A clearer prompt produces better output. It is the first lever everyone reaches for, and it still matters.
I would not treat clever wording as the place your system wins. As models got better at understanding intent, wording stopped being a durable advantage. It is table stakes. The work that used to hide inside slogans moved outward, to the documents, history, and tools you supply, and to what the system remembers across tasks. Learn the names later: context, and memory. Do the prompt exercises anyway. Then leave the thesaurus alone.
Dan Klein's description of prompting as a control surface matches that limit. A prompt has no precise semantics and no guarantee. If the model ignores you, rewriting, capital letters, and extra exclamation points are weak recourse.
What to try: one task, three prompts. A bare instruction. The same instruction plus one example. The same instruction plus a required format, such as one JSON object with two fields. Save all three outputs. You are practicing phrasing, examples, format, and structure, which is the whole craft named above.
How do I know the answer is good enough to keep?
Dan Klein argues that "how many of these scenarios did I get right" is the wrong shipping question. He wants to know, for how many scenarios, the system gets it right every time, including a hundred times in a row. A system at about 80% or 90% right is still, in his view, unshippable if one in ten customers is told a flight was booked when it was not. A system that gets 70% of scenarios right every single time is more valuable, because that is consistency you could put in a product.
He also argues that putting a second model on top to check the first is a weak fix. Both can be wrong, and they tend to fail on the same hard cases, so in his estimate 80% checking 80% ends up around 82%. Add more checkers and the stack gets expensive and slow.
Your first check can be smaller than a benchmark suite. Freeze the input. Run the call several times. Record whether the outputs agree, and whether they match a fact you already know. Fluency is not that check.
On the reading list, the AI, decoded pages are grouped in five levels. If you are building, skim Level 1 (how a large language model works, why it costs what it costs, and why it makes things up), then Levels 4 and 5, where evaluation shows up as a builder's problem. After that, use Start here: five episodes on agents, evals, agent memory, AI infrastructure, and shipping AI in a real product.
# Sketch for practice only. Not a client, and not a system any guest or lab runs.
def rules_flag(amount: float, new_country: bool) -> bool:
return amount > 1000 and new_country
def learned_score(amount: float, new_country: bool, w: tuple[float, float]) -> float:
return w[0] * amount + w[1] * float(new_country)
def next_token(scores: dict[str, float]) -> str:
return max(scores, key=scores.get)
def draft_prompt(task: str, example: str, fmt: str) -> str:
return f"Task: {task}\nExample: {example}\nFormat: {fmt}"
def same_every_time(run, n: int = 5) -> bool:
outs = [run() for _ in range(n)]
return len(set(outs)) == 1
Checklist
- Treat machine learning as examples and parameters, and expect confident errors off that data.
- Read a paragraph as repeated next-token prediction, with hallucination, a knowledge cutoff, and no private data unless you supply it.
- Keep a predictive label and a generated draft in separate functions.
- Practice phrasing, one example, and a fixed format, then move on to context and memory.
- Repeat one frozen input and compare it to a known fact before you trust a single fluent answer.
More on this topic, with the related episodes, is on Chain of Thought.
Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.
Drafted with AI assistance from the episode transcripts.
Top comments (0)