Introduction

Stop for a moment and ask yourself this, honestly:

What do you actually know about artificial intelligence, beyond knowing how to use Claude, ChatGPT, or Gemini? What do you understand an LLM to be, in concrete, verifiable terms? Do you know why a token — not a word, not a letter — is the real unit of exchange a model works with, and why that determines how much each query costs you, how much it can “remember” in a conversation, and why it sometimes fails at tasks that look trivial? Could you explain, with precision, what happens mechanically between the moment you write your question and the moment the answer appears?

If any of those questions gave you pause, stay — this compendium exists exactly to close that gap.

What an LLM actually is

Let’s start by unpacking the term we use as if it were obvious. An LLM (large language model) is, in its most precise definition, a neural network trained to predict text — nothing more and nothing less than that at its core, even if the behavior that emerges from that simple mechanism feels like understanding.

The size of an LLM is measured by its number of parameters: the numerical values the network adjusts during training, and that end up storing, in a distributed and statistical way, everything the model “knows”. They are not hand-written rules or a database of facts — they are millions or billions of numbers, each one gradually adjusted so the model gets better at predicting the next fragment of text given what came before. GPT-3, for example, has 175 billion parameters — 175,000,000,000 individual numerical values, each contributing a tiny fraction to every prediction the model makes. We’ll take apart exactly how they are organized and what each of those numbers does in the Anatomy of a Transformer chapter — here it’s enough to be clear that “more parameters” is not a marketing figure, it is literally more capacity to store statistical patterns of language.

The LLM is not the product you use

Here is a distinction almost nobody makes, and it’s worth locking in from the start: when you talk to ChatGPT, Claude, or Gemini, you are not talking directly to a bare LLM. Those tools are assistant products — they take an LLM as the central engine and wrap it in additional layers: user interfaces designed so anyone can write and get answers without friction, safety and moderation systems that filter or block certain behaviors, and external tools the model can invoke — access to a browser, to databases, to code execution — that the LLM by itself, as an isolated neural network, could never do.

This distinction matters because throughout this compendium we will talk about both, and confusing them leads to the wrong conclusions: when we discuss the limits of a base model (Part II), we are talking about the bare LLM, without any of those product layers — and understanding that “raw” version is precisely what lets you understand what each layer added on top is actually solving.

Why this compendium exists

Nothing you will read here is new information. The concepts we cover — how attention works, why tokens exist, when to use RAG instead of fine-tuning, how to design an agent system in production — live scattered across academic papers, official documentation from labs and infrastructure providers, technical books, videos, and blog posts — each source covering one piece of the puzzle, almost never the complete picture, and almost never in Spanish at the depth an architect or practitioner actually needs.

My goal with this compendium is to gather those scattered foundations in one place, treated with the rigor they deserve — written for anyone who designs AI architectures and needs to justify infrastructure decisions with real judgment; for the practitioner and developer who builds with these tools every day and wants to stop operating by trial and error; and for anyone with genuine curiosity to look under the hood — to stop treating the model as a magical black box, and start understanding the actual mechanism inside.

The path: four parts, plus Claude Ops

This compendium is organized in four parts, each building on the previous one — they are not standalone pieces you can read in any order without losing context, although each chapter tries to spell out explicitly which other chapters it depends on. After that path there is an operational section, Claude Ops, for anyone already using Claude on a team who has to decide how to run it.

Part I — Foundations

Here we take apart the basic mechanism of a language model, from scratch: what exactly a token is and why it is the “currency” the model operates with, how text becomes numbers a neural network can process (tokenization, embeddings), the complete architecture of a transformer — the design that makes GPT, Claude, and virtually every modern LLM possible — how a model is trained from data to a working checkpoint, and how that model goes from being a simple text predictor to behaving like an assistant that follows instructions. If you’ve never understood, precisely, what happens “inside” an LLM, this part is the foundation for everything else.

Part II — Engineering

With the foundations clear, we move to how you use an LLM with professional judgment on a real project: the real limits of a base model, prompting techniques that go beyond “writing well”, how to systematically evaluate whether a change actually improved something (instead of trusting intuition), when fine-tuning is worth it and when it is the wrong decision, how to give a model access to external knowledge (RAG) and the ability to act on real systems (MCP), and how to design agent architectures with proven patterns instead of improvising.

Part III — Infrastructure

Here the question shifts from “how do I use it well?” to “how do I serve it in production, at what cost, and with what guarantees?” — how much generation speed you actually need for your use case, the techniques that exist to optimize inference and bring costs down, how latency, throughput, and the rate limits imposed by providers relate to each other, the real latency/throughput/cost trilemma that no architect can avoid, how to observe and evaluate AI systems already in production, and the security risks specific to agentic systems — with a real case of how such a system can fail catastrophically if designed without judgment.

Part IV — Applied cases

All of the above, grounded in one complete, evolving case: an architecture that starts by serving 10 business users and scales to 1,500 salespeople, showing, with numbers and concrete decisions, how design priorities shift when volume grows by several orders of magnitude.

Part V — Claude Ops

An operational guide, not a foundations chapter: how to choose between Claude Team and Amazon Bedrock to run Claude Desktop (and Claude Code) in an organization, with the decision trees and the actual configuration.