1) For the experienced software engineer

Think of an LLM as a very large, probabilistic autocomplete service trained on a massive corpus of text and code. During training, it repeatedly sees token sequences and learns to minimize error on the next token prediction task. Under the hood, the key mechanism is the transformer: self-attention lets each token “query” relevant prior tokens, so the model can dynamically route information across long contexts (much better than fixed-window n-grams or classic Markov models). Training is just gradient descent on billions/trillions of examples, but the network’s parameters end up encoding reusable patterns: syntax, APIs, idioms, causal language structure, even latent abstractions that help prediction across domains.

Why can “next token prediction” look intelligent? Because to predict well, the model must infer hidden state about the world and conversation: user intent, topic, constraints, style, code semantics, and likely continuations. In distributed-systems terms, the objective is local (predict next event), but the optimizer discovers globally useful representations because they reduce loss across many contexts. Inference is like sampling from a learned conditional distribution (P(token_t \mid context)), one step at a time, with decoding policies (greedy, top-k, nucleus, temperature) controlling behavior. Post-training (instruction tuning, RLHF, tool use) shifts it from “good language model” to “helpful assistant,” analogous to taking a strong general engine and adding product-specific control planes and guardrails.

---

2) For the PhD physicist

Formally, a language model defines a parametric distribution over token sequences via factorization: [ P_\theta(x_{1:T})=\prod_{t=1}^{T} P_\theta(x_t \mid x_{<t}). ] Training minimizes empirical cross-entropy (equivalently maximizes log-likelihood) over internet-scale corpora. Architecturally, transformers are stacks of attention and MLP blocks; attention computes content-dependent weighted interactions, giving a flexible kernel over sequence positions. Nothing “mystical” is happening: it is high-dimensional function approximation with stochastic optimization. The novelty is not that it departs from linear algebra, but that scale + architecture + data produce regimes where capabilities qualitatively change (reasoning-like behavior, in-context learning, code synthesis).

What’s genuinely new versus hype is mostly empirical and systems-driven: (1) scaling laws showing smooth power-law improvements with model/data/compute; (2) emergent in-context adaptation, where the model performs task conditioning from prompt examples without weight updates; (3) robust transfer from a single pretraining objective to many downstream tasks; and (4) practical alignment layers that reshape behavior (instruction tuning/RLHF). The sober view: these models are neither symbolic reasoners nor mere n-gram machines. They are large, differentiable sequence models whose internal representations capture substantial structure in language and world regularities—but with known failure modes (hallucination, calibration errors, brittle reasoning under distribution shift).

---

3) For the venture capitalist

An LLM startup is usually building on a stack with four separable layers: base model access (own vs API), adaptation (fine-tuning/RAG/workflows), product UX, and distribution/go-to-market. Core model training is extremely capital-intensive and increasingly concentrated; most startups win by turning generic model intelligence into domain-specific reliability and workflow ROI. So when founders claim “proprietary AI,” ask: what is truly proprietary—data rights, feedback loops, evaluation harnesses, agent infrastructure, integrations, or just prompt wrappers?

For defensibility, the strongest moats are usually data + workflow lock-in + operational excellence, not raw model novelty. Examples: exclusive enterprise datasets, deep embedding in business processes, high switching costs via integrations, and continuously improving performance from user feedback/telemetry. Credibility checks: do they measure task-level accuracy and error cost in production, or only demo quality? Do they have a plan for model vendor risk, margin compression, and rapid baseline improvement from frontier labs? If they can show compounding advantage from proprietary data flywheels and measurable unit economics at the workflow level, that’s a much stronger story than “we have a better prompt” or “we trained a slightly different model.”