---
title: "Artificial Intelligence Has Many Spokespeople and Few Authors"
description: "Plenty of people are promising artificial intelligence and talking about it. Who is actually studying and building it is a different account, and it does not balance in the feed. The difference is not the tool: it is who answers for the whole distribution, not just the sample that fit in the demo."
author: "Anderson Henrique"
date: "2026-09-03T00:00:00Z"
updated: "2026-09-03T13:08:12.132542Z"
category: "ai"
tags: ["AI Engineering","LLM","GPT-3","Scaling Laws","Chinchilla","Emergent Abilities","Evaluation","Technical Debt","Reading List","NTLabs"]
canonical: "https://www.ntlabs.dev/en/blog/muitos-porta-vozes-poucos-autores"
locale: "en"
---

# Artificial Intelligence Has Many Spokespeople and Few Authors

*Plenty of people are promising artificial intelligence and talking about it. Who is actually studying and building it is a different account, and it does not balance in the feed.*

## The date almost everyone gets wrong

Ask a room when artificial intelligence began and the most common answer points to November 2022, when a chat box appeared in everyone's browser at the same time. That is the launch date. It is not the field's date, and the distance between the two explains nearly everything this piece has to say.

The system behind that box had already been described in a public paper two years earlier. "Language Models are Few-Shot Learners", by Tom Brown and co-authors, came out in May 2020 and was presented at NeurIPS that year. Seventy-five pages. They cover the 175 billion parameter model, the composition of the corpus, training cost, benchmark by benchmark results and, most relevant here, a full section on limitations and another on broader impacts, written by the authors themselves, before there was any product to defend.

The paper has been open, free and indexed for over six years. Almost none of the spokespeople promising transformation have read that limitations section. Several of them promise precisely what it warns against.

And Brown's work inaugurates nothing on its own. It depends entirely on the architecture described in "Attention Is All You Need", by Vaswani and co-authors, from 2017. That architecture solves a problem the community had been attacking since the long short-term memory networks of Hochreiter and Schmidhuber, in 1997. Those networks were trained by backpropagation, popularised by Rumelhart, Hinton and Williams in 1986. The object all of this work manipulates descends from Rosenblatt's perceptron, from 1958. And the turn that pulled the field out of the freezer was Krizhevsky, Sutskever and Hinton's AlexNet, in 2012, which proved in an image classification contest that depth plus data plus a graphics card produced a jump a decade of hand-crafted feature engineering had not.

Seventy years, not three.

Anyone who thinks the field was born with a chat box is reading the launch and calling it history.

## A living field corrects itself in public

This is the second point, and the most useful one for anybody who has to judge a promise without being in the field: artificial intelligence did not arrive finished. It is happening right now. And the best evidence is that the literature contradicts itself in public, in writing, on a two-year cycle.

Two cases, both checkable.

In 2020, Kaplan and co-authors published the scaling laws for language models: loss falls predictably as parameters, data and compute grow. The industry's reading was blunt, almost a slogan: make the model bigger. In 2022, Hoffmann and co-authors published the work known as Chinchilla and showed that reading was unbalanced. For a fixed compute budget, the previous generation of models had far too many parameters and far too little data. A 70 billion parameter model trained on much more data beat models several times its size. Translated: by the criterion the field itself adopted two years later, GPT-3 was undertrained. The paper that founded "bigger is better" was corrected by the people down the hall.

The second case is better still, because it touches measurement. In 2022, Wei and co-authors described so-called emergent abilities: capabilities absent in small models that appear suddenly past a certain scale. The idea caught on, became a headline and became a sales argument, because emergence sounds like magic and magic sells. In 2023, Schaeffer, Miranda and Koyejo published "Are Emergent Abilities of Large Language Models a Mirage?", awarded as one of the best papers at NeurIPS that year. The argument is dry: much of that emergence is an artefact of the chosen metric. Measure exact match over a whole sequence and the curve jumps; measure the same capability with a continuous metric and the curve is smooth and predictable throughout.

The jump was in the ruler, not in the model.

Keep that sentence, because it splits the subject in two. Anyone promising artificial intelligence as guaranteed transformation is selling a certainty the field's own literature does not have. And it is not that the literature is timid. It is that it publishes the confidence intervals, the ablations, the cases where the method fails and the limitations section. None of those four things fits on a conference slide, which is exactly why the talk sounds more convincing than the paper.

Distrust certainty. It is the cheapest symptom to detect.

## Using is receiving a sample. Building is answering for the distribution.

Here is the difference in craft, and it is not a difference of tooling. Both sides open the same window.

Someone using a model receives an output. If the output serves, the work is done, and done well. That is legitimate, and it is a real competence: knowing how to frame, how to check, when to distrust. I am not disqualifying anyone, not least because I use these systems every single day and I am better at my job because of them.

Someone building receives that same output and cannot stop there. The output is one sample from a distribution, and the responsibility covers the whole distribution, including the answers that never showed up. The question stops being "is this answer good" and becomes: what fraction of answers is good, under which inputs, with what variance, and what happens in the tail, in the few per cent where it fails. A demo works by definition, because it was picked after it worked. Nobody records the input that breaks it.

Which is why engineering gets built and not promised. There is nothing to promise before there is a measurement.

Two examples of my own, recent and embarrassing enough to count as evidence.

The first. A secret scanner ran on every push to the repository and came back clean. Three hundred and thirty-seven green runs, over months. The configuration extended a rule set without enabling the key that actually loads that set, so the scanner ran with zero rules. It never said "there are no secrets here". It said "I did not look", and I read the second sentence as if it were the first. When the rules went in, four hundred and thirty findings appeared.

The second. A payment notification receiver validated the signature on every message, and the test passed. In production, one hundred per cent of real notifications were rejected as unauthenticated. The test built the message with the same format expression the code used to verify it: the two agreed with each other, and neither talked to the provider. The code was wrong in both places, identically, and the test passed precisely because of that.

Neither defect shows up in a demo. Both show up the moment someone asks about the distribution instead of the sample. That question is the entire craft.

## The actual day

In 2015, long before the current wave, Sculley and co-authors published "Hidden Technical Debt in Machine Learning Systems". The paper contains a figure that became a classic: the diagram of a real machine learning system in production, in which the box labelled "ML code" is tiny, surrounded by much larger boxes for data collection, verification, feature extraction, configuration management, serving infrastructure, monitoring and analysis tools.

A day of AI engineering is spent in the big boxes. Here is mine, unembellished.

**Data.** Where it comes from, who produced it, what is missing, what is duplicated, what changed format last week without warning and broke everything quietly.

**Evaluation.** Building the case set that decides whether a change made the system better or worse. This is the hardest part, because the output is free text and there is no single right answer. Without it, every prompt change is an opinion wearing the costume of work.

**Failure mode.** What the system does when it does not know. If it answers with its usual confidence, it is broken even when it happens to be right, because the confidence stopped carrying information.

**Cost and latency.** Every call has a price in dollars and a price in seconds. An architecture that ignores both works in the demo and dies on the first invoice.

**Provider outage.** What happens when the main API errors out at three on a Tuesday afternoon. In my case that is an explicit chain across providers, and it exists because the alternative is my product falling over alongside a company that is not mine.

**Observability.** Tracing every call, so that "why did it answer that" has an answer instead of a theory.

None of this is prompting. Prompting is the visible part, and the smallest.

## This is computer science, not social media

There is an idea going around that artificial intelligence is a new field with no prerequisites, where whoever got to the topic first has authority over it. It is not, and that confusion is expensive.

To understand why a language model works you need probability: the object is a conditional distribution over the next token, and training is minimising cross entropy, which is the measure Shannon defined in 1948, used here as a loss function. You need optimisation: stochastic gradient descent, learning rate, what happens on a surface that is not convex. You need linear algebra, because attention is matrix multiplication with a normalisation on top, not a metaphor about focus. You need information theory to know what perplexity measures and, above all, what it fails to measure. You need computational complexity to understand why attention costs quadratic in sequence length and why half a decade of research went into pushing that exponent down. And to stand anything up you need distributed systems, databases, networking and software engineering, because a model without all of that around it is a weights file sitting on a disk.

None of this is learned at an event. I go to events, I enjoy them and I present at them. But an event is where the field meets, not where it is learned. A talk is a synthesis of work done somewhere else, and watching syntheses repeatedly produces vocabulary, not competence. That is why three technical questions are enough to recognise a spokesperson, and none of them has to be hard: how do you evaluate whether it got better, what does the system do when it does not know, and how much does each answer cost.

The inverse holds too, in fairness, and it charges me as much as anyone. There are plenty of people able to train a model and unable to explain why it matters, for whom, and at what social cost. Communicating is not decoration: it is the last step of inventing. An author who does not communicate does not balance the account either, just fails in the other direction.

## What to read to get out of the hype

This is not a list of authority. It is the order I would hand to someone who wants to stop repeating and start understanding. Almost all of it is free.

**Papers, in this order:**

- Vaswani et al., 2017, "Attention Is All You Need". Eight pages containing the whole architecture. After it, transformer stops being a magic word.
- Brown et al., 2020, "Language Models are Few-Shot Learners". Read the limitations section before the results. It is the paper describing what is now sold as novelty.
- Sculley et al., 2015, "Hidden Technical Debt in Machine Learning Systems". Cures the illusion that the model is the system.
- Kaplan et al., 2020, then Hoffmann et al., 2022, in that order, to watch the field correct its own thesis in public.
- Schaeffer, Miranda and Koyejo, 2023, "Are Emergent Abilities of Large Language Models a Mirage?". How a badly chosen metric manufactures a phenomenon that is not there.
- Ouyang et al., 2022, on InstructGPT. Why the model that predicts well is not the model that answers well, and what it took to turn one into the other.
- Bender et al., 2021, "On the Dangers of Stochastic Parrots". Disagreeing with it on the argument is a respectable position. Not knowing it is not.
- Shannon, 1948, "A Mathematical Theory of Communication". Because every language model's loss function is one of his measures, and because that is where engineering learned to trade adjectives for units.

**Books:**

- Russell and Norvig, *Artificial Intelligence: A Modern Approach*. The map of the whole field, including everything that is not deep learning and that the hype erased.
- Bishop, *Pattern Recognition and Machine Learning*, or the more recent *Deep Learning: Foundations and Concepts*, by Bishop and Bishop. Probability taken seriously.
- Goodfellow, Bengio and Courville, *Deep Learning*. Free online since 2016.
- Sutton and Barto, *Reinforcement Learning: An Introduction*. Modern alignment is reinforcement learning, and without that base the discussion turns mystical.
- Murphy, *Probabilistic Machine Learning*. A desk reference for the rest of your career.
- Pearl, *The Book of Why*. Because correlation at scale is still not causation, and scale makes the mistake more convincing, not less.
- Chip Huyen, *Designing Machine Learning Systems* and *AI Engineering*. The systems side, which is where the day actually happens.

And a two-page essay worth more than many conferences: "The Bitter Lesson", by Rich Sutton, 2019.

## The cut

I am not asking for a diploma. The field was built by people from unlikely backgrounds and still is, and the road in is more open and better documented than in almost any other discipline in history.

What I am asking is that we stop confusing categories. Using well is a competence. Speaking well is a competence. Neither of them is building, and neither answers for what the system does on Monday, when the input is not the one from the demo, the provider is down and someone has to explain why the answer came out wrong.

Two questions settle almost every doubtful case, and they apply to me as much as to anyone:

1. Can you explain why the system got it wrong that time?
2. Can you show what was done so it will not get it wrong that way again, and how that is verified?

Whoever answers both is building. Whoever answers neither is talking about. Between the two lies a wide and honest band of people learning, and that is where nearly everybody should place themselves, without hurry and without shame.

**A spokesperson answers for what they said. An author answers for what the system does when they are not in the room.**