What Each Era of AI Tried, and Why It Stalled
A seventy-five-year argument about who supplies the rule
The line drawn last time — between problems where a rule can be written down and problems where only examples can reveal it — turns out to be the entire history of artificial intelligence. Alan Turing opened it in 1950 by replacing "can a machine think" with a checkable game of blind interrogation, laid out in his original paper in Mind. Six years later the Dartmouth proposal bet that any feature of intelligence could be described precisely enough for a machine to simulate it, and the first decade delivered real wins in search, games, and Frank Rosenblatt's perceptron — a machine that adjusted its own weights from wrong answers.
Then came the reckoning. Search exploded combinatorially on real problems, a single layer of weights proved unable to solve exclusive-or, and government reviews on both sides of the Atlantic — most bluntly the Lighthill Report — found promises with nothing measured behind them, and funding stopped. The next era hand-wrote expert knowledge instead, and it worked: XCON cut computer-configuration errors from over thirty percent to under two, saving Digital Equipment Corporation tens of millions a year, a story traced in the history of configuration technologies. It still collapsed under its own maintenance — half the rule base rewritten every year — because rules interact in ways nobody can see once the pile grows large enough.
What replaced hand-written knowledge was counting from data: speech and statistical machine translation learned their structure from text rather than grammar books. Layered networks returned in 2012 when AlexNet beat hand-designed image features by eleven points on ImageNet, and in 2017 attention mechanisms let every position in a sequence look directly at every other, becoming the transformer behind today's large models. The chapter closes on what scaling has actually proven versus only claimed, and on five ideas — weight adjustment, held-out evaluation, learned probabilities, learned features, and attention — that survived every collapse along the way.
Reading a release without the hype
A current example puts that habit to work: Google's Gemini 3.6 Flash cuts output tokens by roughly seventeen percent and resolves about half of real software issues on one benchmark, yet an independent vision evaluation found its object-localization accuracy got worse — one release, improving on one measure while sliding on another.
Last time we drew a line between two kinds of problem: the ones where somebody has already written the rule down, like withholding tax from a paycheck, and the ones where you can recognize the answer but cannot say what the rule is, like spam. That line is not just a teaching device. It is, more or less, the whole history of artificial intelligence, played out over about seventy-five years with real money and real disappointment attached.
Here is the claim I want to put on the table before we start walking, so you can test it against every era as it goes past. Every generation of this field failed in the places where humans had to hand-write the knowledge, and succeeded in the places where examples were allowed to supply the rule. That is the same argument you already met at the small scale of a spam filter fighting itself. What follows is that argument at the scale of national research budgets.
There is a second thread underneath it. Every collapse in this history was preceded by promises that ran ahead of the evidence. That is why, later in this course, we will be tedious about baselines, about held-out data, and about stating what a result does not show. Those habits are not academic manners. They are what the field learned by being wrong in public, twice, expensively.
Start with the question that opened everything, which is: can a machine think? The trouble with that question is that it is unanswerable, and not because it is hard. It is unanswerable because nobody can say what would settle it. If a machine gave every sign of thinking, someone could still say it was only going through the motions, and there would be no experiment to run next.
In nineteen fifty, in a paper called "Computing Machinery and Intelligence," published in the journal Mind, Alan Turing did something clever with that dead end. He said the original question was too meaningless to be worth discussing, and he replaced it with a different one that you could actually run.
His setup came from a parlour game. Three people. An interrogator sits alone in one room and can only send and receive typed messages — a teleprinter, in his description, so that no voice or handwriting leaks through. In the other room are a man and a woman. The interrogator's job is to work out which is which. The man is trying to fool the interrogator; the woman is trying to help. Now, said Turing, take the man out and put a digital computer in his place. Ask this: does the interrogator get it wrong as often as before? If the machine is as good at that game as the man was, then refusing to call the machine intelligent has no experimental basis left.
Notice what that swap accomplishes, because you are going to do the same trick over and over in this course. Turing did not answer a vague question. He traded it for a checkable one. He gave up on the inner life of the machine — whether it feels anything, whether there is anyone home — and settled for behaviour under blind evaluation. That is a real loss. The test says nothing about consciousness, and it was never meant to. It also does not tell you the machine is intelligent in general, only that it held up under one kind of interrogation by one interrogator. And scholars still argue about exactly which version Turing intended: a computer imitating a woman alongside a man, a computer imitating a human alongside a human, which is the common reading, or a plain one-on-one interview. When you cannot get people to agree on the setup, you should be careful about what you claim from the result.
That is already the shape of the whole course. Turn the vague wish into a stated claim you can check, then say plainly what the check leaves out. You did this in the last chapter without the history behind it, when you turned "reduce churn" into a unit, a set of features, a target and a baseline.
Six years after Turing's paper, the field got a name. In the summer of nineteen fifty-six, a two-month research meeting was held at Dartmouth College, proposed the previous August by John McCarthy of Dartmouth, Marvin Minsky, then at Harvard, Nathaniel Rochester of IBM and Claude Shannon of Bell Labs. Allen Newell, Herbert Simon, Arthur Samuel, Oliver Selfridge, Ray Solomonoff and Trenchard More were among those who came. The proposal contained the sentence the whole programme rests on: that every aspect of learning or any other feature of intelligence can in principle be described so precisely that a machine can be made to simulate it. That is a bet, not a finding, and it is worth holding it in mind as a bet.
The meeting itself was a bit of a shambles. People arrived at different times, stayed for different lengths of time, and no single final report ever came out of it. What came out was the name and the idea that this was one field rather than a scattering of hobbies.
The first decade after that was genuinely thrilling, and it went in three directions. First, search. A program can treat a problem as a tree of choices and walk it looking for the good branch. The Logic Theorist, built in nineteen fifty-six by Allen Newell, J. C. Shaw and Herbert Simon and shown at Dartmouth, proved thirty-eight of the first fifty-two theorems in the second chapter of Whitehead and Russell's Principia Mathematica. Crucially it did not try every possibility. It used rules of thumb about which branch looked promising, and it worked backwards from the thing to be proved. Three years later the same team built the General Problem Solver, which formalized a habit humans use constantly: look at where you are, look at where you want to be, measure the difference, and pick the action that shrinks that difference. Second, games. Arthur Samuel at IBM had a checkers program running on early machines from about nineteen fifty-two, published in nineteen fifty-nine. It searched ahead, assuming the opponent would play well, and it pruned branches that could not matter. It also remembered positions it had already scored, and — this is the part that belongs to our story — it adjusted the numbers in its own scoring formula as it played, so that its judgement of a position improved with experience.
Third, and most important for everything that follows, a machine that learned from examples by nudging numbers. Frank Rosenblatt at the Cornell Aeronautical Laboratory built the perceptron, with a hardware version, the Mark One Perceptron, running by around nineteen sixty. The idea is small enough to walk through out loud.
Give the machine some numbers describing one example. Suppose two numbers, and suppose we want it to answer yes or no. The machine keeps a weight for each input — just a number saying how much that input counts, and in which direction. It multiplies each input by its weight, adds the results, and answers yes if the total clears a threshold and no if it does not.
Say both weights start at zero, so the total is zero and the machine says no to everything. Now show it an example where the two inputs are two and one, and the correct answer is yes. It said no. It was wrong, and it was wrong in the direction of being too low. So push the weights up, in proportion to the inputs that were on: add a bit of two to the first weight, a bit of one to the second. If we nudge by a tenth of the input, the weights become nought point two and nought point one. Show the same example again and the total is now nought point five instead of zero. It has moved toward yes. If instead the machine says yes when the answer was no, you subtract instead of add, and it moves the other way.
That is the whole rule: wrong answers move the weights against the error, right answers leave them alone. And there is a theorem about it, the perceptron convergence theorem, which says something quite strong. If the two classes can be separated by a straight cut through the space of inputs, this procedure will find such a cut in a finite number of steps. It will not wander forever. Hold on to this, because adjusting weights from examples is the single idea from the nineteen fifties that is still running, unchanged in spirit, inside every model in this course.
Then the first wave stalled, and it stalled for three separate reasons that arrived close together.
The first is what happens to search when problems get bigger. Take a puzzle where at each step you have ten choices. Look one step ahead: ten possibilities. Two steps: a hundred. Three: a thousand. Ten steps ahead and you are at ten billion. Nothing has gone wrong with the method. The method is fine. The number of things to look at simply multiplies at every step, and it outruns any computer you can build, and it outruns the computers we will build next century too. This is why programs that dazzled on small tidy puzzles fell apart on real problems: the real problem was not harder in kind, it was just deeper, and depth is fatal when the count multiplies.
The second reason was the limit of a single layer of weights. In nineteen sixty-nine Marvin Minsky and Seymour Papert published Perceptrons, and they proved, mathematically, what that one layer cannot do. The famous case is exclusive-or: answer yes when exactly one of two inputs is on, no when both are on or both are off. There is no straight cut that separates those cases, so the convergence theorem simply does not apply — there is nothing to converge to. They also showed that certain whole-image properties were out of reach for units each looking at a small patch: whether a shape is one connected piece, or whether the number of marked points is odd or even. And they conjectured that stacking layers, while it would fix the expressive problem, would run into an unsolvable difficulty of its own — how do you know which weight in which layer deserves the blame for a wrong answer? That conjecture, more than the proofs, drained funding from neural networks for over a decade. Notice that the proofs were correct and the conjecture was wrong. The stacking problem got solved. We will solve it ourselves, later, when we derive backpropagation.
The third reason was official, and it came with money attached. In nineteen sixty-six, in the United States, the Automatic Language Processing Advisory Committee published a report called "Language and Machines: Computers in Translation and Linguistics." Its finding on machine translation, after a decade of heavy defence spending, was blunt: the machine output was slower to work with, less accurate, and about twice as expensive as simply hiring human translators, with no visible route to improvement. Funding for open-ended translation research ended; what survived was basic linguistics and tools that helped human translators. Then in nineteen seventy-three, in Britain, Sir James Lighthill wrote a general survey of artificial intelligence for the Science Research Council. He sorted the field into three parts — advanced automation, robotics and integrated systems, and computational neurobiology — and concluded that none of the promised major impacts had arrived. His central technical objection was exactly the multiplying-count problem: methods that worked on toy domains degraded catastrophically as the space grew. The Council cancelled artificial intelligence funding at British universities, sparing only a few groups, including Edinburgh, Sussex and Essex. Alongside this, the Mansfield Amendment tightened American military research money onto projects with direct, demonstrable defence use, which is not where speculative work lives.
So the first winter was not caused by a discovery that the idea was impossible. It was caused by a bill coming due on promises.
The next era took the opposite approach, and for a while it worked, which makes its failure the most instructive part of this chapter. If general intelligence is too hard, said the expert-systems programme, then narrow expertise might not be. Find a specialist. Interview them for months. Write down what they know as a large pile of if-then rules. Build an engine that chains those rules together. This is deliberately not learning from examples. It is hand-writing the knowledge, at industrial scale, on purpose.
And it made money. The clearest case is a system called XCON, originally R1, built by John McDermott at Carnegie Mellon between about nineteen seventy-eight and nineteen eighty and put into service by Digital Equipment Corporation. Its job was configuring computer orders: given what a customer had asked for, work out whether the machine could actually be built, with the right cables, cabinets and controllers. It started at roughly five hundred rules and grew past ten thousand. It handled tens of thousands of complicated orders a year. Configuration errors fell from over thirty per cent to under two per cent, and by nineteen eighty-six the company put the savings at around forty million dollars a year. That is a real result, on a real task, with a measured before and after. Nothing about the coming collapse takes that away.
The other landmark, MYCIN, was built by Edward Shortliffe at Stanford in the mid-nineteen-seventies to diagnose bacterial blood infections and recommend antibiotics, with something like four hundred and fifty to five hundred rules and its own home-made way of tracking how sure it was. It performed competitively against clinicians. It was never deployed — hospital workflow, liability and the sheer cost of integration stopped it. Keep that in mind for later, when this course gets to shipping things: a model that performs well is not yet a system anyone uses.
Now the failure. Three parts.
The first is getting the knowledge out of the expert's head. Specialists are good at their jobs and bad at explaining them, so every rule had to be dug out by interview, argued over, and written down by hand. The channel is narrow and the labour never ends.
The second part is the one that should feel familiar. As the pile of rules grows, the rules start interacting in ways nobody can see. Rules do not sit in separate boxes; they fire in combination. Add one rule to handle an awkward new case, and it quietly changes the outcome of a dozen paths that used to work, because it now fires in the middle of them. Edit an old rule to fix that, and you break something else. Soloway, Bachant and Jensen documented this for XCON in nineteen eighty-seven, in the course of a redesign undertaken because the system had become so hard to change. The number that tells the story is this: to keep up with new computer components, Digital had to rewrite or modify something like half of XCON's rule base every year. Half. Every year. Forever.
That is the spam filter from the last chapter, exactly, at ten thousand rules and a corporate budget. You made the same discovery in miniature: each patch worked, the patches began contradicting each other, and after a while nobody could say what the filter actually did. Here it is with an annual maintenance bill.
The third part is brittleness at the edges. These systems had no model of why anything was true, no common sense to fall back on, and no honest way of saying how confident they were. Inside their narrow domain they were sharp. One step outside it they did not degrade gently — they failed hard, and confidently, with no signal that they had left the territory they understood.
The commercial end of the era, between about nineteen eighty-seven and nineteen ninety, came partly from the same direction as the first winter. Big programmes had been launched on big promises: the American Strategic Computing Initiative in nineteen eighty-three, Japan's Fifth Generation project. Meanwhile the specialized, expensive workstations these systems ran on were overtaken by ordinary commodity machines that were faster and much cheaper, and the companies that sold the specialized hardware collapsed.
What replaced it was the turn this course is built on. Through the late nineteen-seventies, eighties and nineties, the centre of gravity moved from writing down knowledge to estimating it from data. Three things made that possible: computers cheap enough to run over large collections of text, text that had been digitized and could be counted, and a shift in mindset from proving things with logic to estimating things with probability.
Speech recognition went first. Instead of hand-coded rules about how sounds combine, the work at IBM's Watson research centre — Frederick Jelinek, Lalit Bahl, Robert Mercer and colleagues — modelled speech with hidden Markov models and statistical language models built by counting which words follow which. Kai-Fu Lee's Sphinx system at Carnegie Mellon in nineteen eighty-eight was a landmark in the same direction. The counting idea is simple enough to say plainly: if you want to know how likely the next word is, count how often that word followed the previous one or two words across a very large body of text, and use that. Nobody wrote the grammar. The text supplied it.
Translation followed. In nineteen ninety, Peter Brown, Stephen and Vincent Della Pietra and Robert Mercer published a statistical approach to machine translation, developed into a series of models by nineteen ninety-three. They reframed translation the way an engineer frames a noisy signal: the French sentence is a garbled version of an English one, so search for the English sentence that is both plausible English and a plausible source of that French. That splits the job in two — a model of what English looks like, learned from English text, and a model of how words correspond, learned from pairs. The corresponding-words part was learned automatically from sentence-aligned bilingual text, the Canadian parliamentary record being the famous source, using an iterative method that guesses the alignments, re-estimates the probabilities, and repeats.
Twenty-four years after the report that killed translation funding for being twice as expensive as a human, the task came back by a different road. Not a better grammar. Counting, on a corpus. Most of the classical toolkit the next phases of this course teach — estimating parameters by maximum likelihood, expectation-maximization, working with probability distributions rather than certainties — comes from this period.
Then, in twenty twelve, the layered networks came back. The venue was the ImageNet challenge: one point two million labelled photographs across a thousand categories. The winning entry, an eight-layer convolutional network from Alex Krizhevsky, Ilya Sutskever and Geoffrey Hinton, now called AlexNet, cut the top-five error rate to fifteen point three per cent. The runner-up, built on hand-designed image features, came in at twenty-six point two per cent. Roughly eleven percentage points in one year, on a benchmark where progress had been incremental, is the kind of gap that ends an argument.
What changed was mostly not the idea. Layered networks and training them by adjusting weights were decades old. What changed was scale and hardware, and the authors said so. They wrote their own convolution code to run on two consumer graphics cards, which is where the compute came from. They swapped the smooth squashing function in each unit for one that simply passes positive values through and zeroes negatives, which made training converge about six times faster. They used dropout, randomly switching off half the units in the large layers during training so the network could not rely on any fixed clique of them, and they multiplied their training data by shifting and mirroring images. And they had ImageNet itself, crowdsourced by Fei-Fei Li and colleagues, without which sixty million parameters would have had nothing to learn from. The MNIST digits you looked at last chapter are this same setup at a smaller scale: raw pixels in, no hand-coded notion of shape, the features discovered rather than specified.
Five years later came the mechanism behind almost everything now. The paper, from Ashish Vaswani and colleagues in twenty seventeen, is "Attention Is All You Need," and its motivation was practical. The best sequence models then processed a sentence one position at a time, each step's internal state computed from the previous step's. That has two costs. Training cannot be spread across the sentence, because step ten needs step nine finished. And information from the start of a long passage has to survive being passed hand to hand through every intervening step. Their answer was to let every position look directly at every other position in one operation, with learned weights deciding what to look at. Any two words are one hop apart no matter how far separated, and the whole sequence can be processed in parallel on a graphics card. That, not a new theory of language, is the transformer.
Today's large models are that same family, scaled: decoder-only transformers trained on enormous text and multimodal collections by the simple objective of predicting the next token. GPT-4, Claude, the open-weight Llama models. They are extended into agents by wrapping them in loops that alternate reasoning with action — the ReAct pattern from Yao and colleagues in twenty twenty-three is the reference point — letting the model call tools like a shell, a test runner or a linter and read the results.
So, what has scaling actually established, and what is only claimed? Two things are solid. Pre-training loss falls as a smooth, predictable power law in compute, data and parameter count — Kaplan and colleagues in twenty twenty, with Hoffmann and colleagues in twenty twenty-two showing that parameters and training tokens should grow together in roughly equal proportion. And spending extra compute at answer time, through chains of reasoning, repeated attempts and majority voting, reliably improves accuracy on tasks where the answer can be checked, like mathematics and software fixes. Two things are disputed. The claim that new abilities appear suddenly at scale thresholds was substantially undercut by Schaeffer, Miranda and Koyejo in twenty twenty-three, who showed that the sharp jumps largely come from all-or-nothing scoring — exact string match, say — sitting on top of a probability that was improving smoothly all along. Change the measure and the cliff becomes a slope. And the claim that training on synthetic data can keep this going indefinitely, once high-quality human web text runs short, which is projected for the late twenty-twenties, is unproven. Scaling next-token prediction has not solved hallucination, has not made open-ended reasoning verifiable, and has not delivered reliable unconstrained agency.
That is the chronology. Now the list worth carrying: five ideas that survived, and where each came from. Adjusting weights from examples, from the perceptron in the late nineteen-fifties. Held-out evaluation — judging a system on data it was not fitted to — from the discipline of statistics and made routine by the statistical era and its benchmarks; it is why MNIST ships with ten thousand test images kept separate. Probabilities estimated from data rather than asserted by hand, from the speech and translation work of the eighties and nineties. Layered feature learning, where the system finds its own features from raw input, proved at scale in twenty twelve. And attention, from twenty seventeen.
What stayed dead is just as useful. Hand-written rule bases as a route to general competence: killed by maintenance, at a measured cost of rewriting half a system every year. Pure logical search over large real-world spaces: killed by the multiplying count. Notice that both are cases of a human trying to supply knowledge directly, and that both survive perfectly well in narrow, stable domains where the rule really is known.
And the habit to take from the winters is one you can practise this week. When you meet a claim about a system, ask what was demonstrated, on what task, measured how, against what alternative — and separate that from what was promised or announced. AlexNet's eleven points came with a benchmark, a competitor's score and published code. The Lighthill Report found the opposite: promises with nothing measured behind them. Both of those are evidence. Which kind you are looking at tells you what to believe.
A release from this summer
Here is one current item, and it is a good one for practising exactly that separation. Google DeepMind released Gemini three point six Flash on the twenty-first of July, twenty twenty-six, generally available rather than previewed, under the model name gemini dash three point six dash flash. It replaces three point five Flash as the default lightweight multimodal model, meaning the cheap fast one you would reach for by habit rather than the flagship.
What actually changed is narrower than a version bump suggests. The knowledge cutoff moved from January twenty twenty-five to March twenty twenty-six. The context window stayed the same, at just over a million input tokens and up to sixty-five thousand or so out. The headline change is verbosity: Google reports roughly a seventeen per cent drop in output tokens consumed on the Artificial Analysis Index, and the output price per token came down as well. Fewer tokens at a lower price per token compounds, which matters most for agent loops, where a model may take twenty turns to finish a job and you pay for every intermediate word it thinks out loud in.
Now read the benchmark carefully, because it is a nice example of the distinction we just drew. On DeepSWE version one point one, a test of resolving real issues in real software repositories, it resolved about forty-nine per cent of issues while using up to sixty-five per cent fewer tokens than the previous version. That is a demonstrated result on one task: autonomous software fixing. It is not a statement about the model generally. Independent evaluation by Roboflow found that fine-grained visual localization — drawing boxes around objects in an image, scored by mean average precision — got worse than three point five Flash, with boxes clustering and occasional formatting slips. So the same release improved one measured task and degraded another. Cheaper output does not mean better reasoning either; on problems that need long exploration, cutting the thinking short is a cost, not a saving.
If you want to open something, you can. Google AI Studio has a free web playground where you can select this model and type at it with nothing but a Google account. For code, an API key and the google-genai package are enough: create a client, which reads your key from the environment, then create one interaction naming the model and passing your prompt as input, and print its output text. Four lines. Ask it to explain what a loss function is. You will not understand the answer fully yet — that is the point. Save what it tells you, and check it against what we derive ourselves in a few phases' time. That comparison is more useful to you than the answer.