Richard Feynman is a scientific legend, but that alone is not why we are opening XMAKYNA's technical blog with this lecture. We are starting here because much of the engineering we care about eventually comes down to very simple questions: what did the machine read, what did it store, what did it do next, and what was it allowed to affect? Feynman's filing-clerk model gives us a shared language for those questions. Later posts can build on that foundation instead of re-explaining it from scratch.
More than forty years later (the seminar was recorded in 1985), the lecture still feels remarkably fresh. It can reward almost anyone who is curious about computers because Feynman does not begin with jargon. He gives us a clerk, numbered drawers, simple instructions, a note telling the clerk where to go next, and values that can point to other drawers. From those ingredients, the basic machinery of a computer starts to become visible.
Neither the lecture nor this article explains everything about computers. What they do explain is a useful core: information is stored somewhere, instructions determine what happens next, stored values can point the machine elsewhere, and simple operations can combine into much more complex behaviour.
That matters for security too. Many serious failures become much less mysterious when reduced to this picture. The machine may read from the wrong place, follow the wrong next step, trust a value that means something different from what another part expected, or be deliberately steered by someone who can influence what is in a drawer or where the clerk looks next.
The machine can follow its instructions perfectly and still do something dangerous. Understanding that is one of the foundations we will keep using.
The lecture resonates differently now that we live with large language models (LLMs) and other systems whose output can look astonishingly capable. Feynman was not explaining modern AI, and this article will not pretend that he was. What his lecture gives us is more fundamental: a way to look past impressive output and ask what the machine is actually doing, how it arrived there, what it can get wrong and what happens when those mistakes matter. For us, that is a core engineering concern as we use AI: code that builds successfully (compiles), runs and looks plausible is not enough; we still have to establish that it is correct.
This post therefore starts deliberately with the fundamentals. It follows Feynman's simple metaphors far enough for a non-specialist to build a strong picture of how a computer finds information, follows instructions, changes direction and produces complex behaviour from simple steps. We will need that picture again and again later.
Start with a clerk and some drawers
Imagine a clerk in a room full of numbered drawers. Each drawer can hold a number or some other simple piece of information. The clerk can open a drawer, read what is inside, copy a value, write a new value somewhere else, compare two values and follow an instruction telling them what to do next.
That is deliberately unglamorous. The clerk does not need to know whether a number represents money, a colour, a letter, the temperature, a position on a chessboard or the address of another drawer. Meaning is something we impose through representation. To the clerk, there are values, locations and procedures.
This is one of the most useful ways to demystify a computer. A machine can produce behaviour that looks astonishing from the outside while still being built from operations that are individually almost embarrassingly simple. The sophistication comes from organisation: what is stored, how it is represented, which instruction runs next, and how many such operations can be chained together.
The route through the program is stored too
The really powerful part is that the filing system can describe not only the data but also the route through the work. Somewhere, the clerk keeps track of which instruction comes next. In modern computer architecture, that little piece of state is commonly called the program counter. The name can sound technical; the underlying idea is almost comically simple. It is the clerk's note saying, in effect, "read instruction 101 next."
After instruction 101, the normal rule might be to continue to 102, then 103, then 104. But an instruction can also say: do not continue to the next card; go to instruction 250 instead. That is a jump. A conditional jump adds a test: if this value is zero, go to 250; otherwise continue to 102.
Nothing mystical has happened. The machine has changed the stored location of the next instruction. Yet from that one idea we get branches, loops, retries and most of the familiar shape of a program. A loop is simply a jump that sends the clerk back to instructions already visited until some condition changes.
This is worth lingering on because it strips a large amount of computer jargon down to ordinary bookkeeping. The machine's control flow is itself state. The answer to "what happens next?" is represented somewhere, and instructions can change that answer.
A pointer is just a location written down
Pointers can be explained through the same filing system. Suppose drawer 500 contains the number 914. Sometimes 914 is just the number nine hundred and fourteen. In another context, it can mean: the thing you want is stored in drawer 914. When a number is being used that way, it is acting as a pointer, an address that refers to another location (another drawer).
Again, the power comes from interpretation. The clerk does not see a glowing arrow floating through memory. The clerk reads a value, the current instruction says to treat that value as a location, and the next operation uses it to choose another drawer. One stored number can therefore redirect where subsequent work reads or writes.
This is one reason the filing-clerk model scales so well. Data can name other data. Instructions can redirect other instructions. A small set of operations over locations can build structures whose behaviour is far richer than the operations themselves.
Simple instructions, enormous behaviour
Read a drawer. Write a drawer. Add two values. Compare them. Use one value as the location of another. Change which instruction comes next. Repeat. These are not impressive acts in isolation.
Combine them across a very large filing system at extraordinary speed and they can implement spreadsheets, compilers, games, databases, image decoders, web browsers and operating systems. The filing clerk does not need a separate mystical ability for each application. We arrange data and instructions so that the same elementary machinery produces different behaviour.
That is the brilliance of the explanation. It does not make computers seem trivial. It makes their power more impressive because the power is built from such plain ingredients.
When the clerk begins to look intelligent
Feynman eventually pushes the filing-clerk model toward a harder question: can a machine think? In his framing, the difficulty is not that a computer could never execute a thinking procedure. It is that human thinking does not come with a known, completely definite procedure we can simply hand to the clerk.
Feynman makes a simpler version of the same point with arithmetic. The machine is not trying to imitate a mathematician's experience of calculating. It uses a different mechanism, one much better suited to routine arithmetic.
“They do arithmetic better than anybody, much faster, and differently … we’re never going to change how they do arithmetic to make it look like humans, that would be going backwards. Because arithmetic done by humans is slow, cumbersome and confused and full of errors.”
Feynman's target here is arithmetic, not human intelligence in general. His point is about execution: for routine arithmetic, the computer's different method is an advantage. Making it imitate a human procedure simply to look human would throw that advantage away.
That sets up the harder question. If a machine need not perform arithmetic in the human way, must intelligent behaviour be produced by the human route either?
Chess makes the difficulty concrete. A strong human player does not appear to enumerate millions of positions. The player notices structure: a fork, a vulnerable square, a familiar shape, a promising line. Feynman calls attention to the gap between saying that a person sees a pattern and actually knowing the mechanical procedure by which the useful pattern was noticed in the first place.
A computer can attack the same problem differently. It can examine far more positions than a person, apply explicit rules and evaluations, and use heuristics to avoid spending equal effort everywhere. It does not need to recreate the private route by which a human expert arrived at the same move.
Feynman puts the distinction beautifully: “We can't make it play like a human plays, but we can make it play better than almost all humans.” (emphasis ours)
That sentence carries a larger engineering idea. It separates resemblance from usefulness. A machine does not have to reproduce the human path to produce a result we recognise as intelligent. What matters is what procedure it is actually carrying out, what patterns or regularities it can exploit, how it searches or selects among possibilities, and where its competence stops.
The filing-clerk model therefore survives the apparent leap into intelligence. The result can look remarkably smart while the underlying machine is still manipulating representations, comparing alternatives and moving through state according to definite operations. The mystery has not moved into the hardware. It has moved into how useful structure is represented, how the procedure finds it, and how much can emerge from computation without requiring the machine to think in the way a person does.
The latter part of the lecture ranges much further into thinking machines, intelligence, heuristics and their limits than we will here. Still, Feynman's closing line deserves to survive the narrowing: “I think that we are getting close to intelligent machines, but they are showing the necessary weaknesses of intelligence.”
It is hard not to hear that differently now. The line leaves room for a machine to be genuinely useful, even remarkably capable, without requiring it to be flawless. Weakness does not automatically cancel intelligence; it tells us that intelligence itself can have limits, blind spots and characteristic failure modes. For engineering, that is a much more useful starting point than pretending useful machine intelligence must first become infallible.
The clerk is literal
That same intelligence has a sharp edge: the clerk underneath it is still literal. The clerk follows the procedure that actually exists, using the state that is actually present. The clerk does not repair our intention.
If an instruction points to the wrong drawer, the clerk does not somehow know which drawer we meant. If drawer 500 contains 915 when we expected 914, a later pointer can lead somewhere else. If a jump condition was written incorrectly, the clerk can follow the wrong branch perfectly. If one part of a system interprets a value as a size while another interprets it as something else, the clerk does not stop because the disagreement feels suspicious.
When we say the clerk is confused, we do not mean the computer experiences human confusion. We mean that the state, representation or procedure no longer matches the model the designer thought was being enforced. The machine can remain perfectly obedient while the system becomes wrong.
Real systems can also have more than one clerk working with the same drawers. One clerk can read a value while another changes it, clears it or repurposes the drawer for something else. The first clerk may then continue using an old value, or even follow a note to a drawer that no longer belongs to the thing it thought it did. Once several clerks can reach the same drawers, who can read or change them, and when, becomes part of whether the procedure is correct.
That is where engineering starts to become interesting
Many difficult software failures can be reduced to some variation of this problem. The wrong location was followed. A decision was made using one representation and an action was taken using another. A value was checked and then changed before use. A stale record was treated as current. A fallback sent the work through a different route. A later stage trusted meaning that an earlier stage never established.
Seen from the outside, these failures may involve sophisticated software. Seen from the inside out, the questions are often concrete. Which value did the clerk read? Which drawer did that value name? Which instruction ran next? Which condition caused the jump? Which state did the next instruction believe it had received?
That is an engineering habit we care about. When a system-level claim becomes vague, trace it back until the mechanism becomes literal again.
And that is where security enters
A normal bug can confuse the clerk accidentally. A security problem becomes possible when somebody can deliberately influence the state or instructions in a way that drives the machine toward a useful consequence.
An attacker does not need the computer to become disobedient. Quite the opposite. Some of the most interesting failures happen because the computer obeys too faithfully: it follows the attacker-influenced pointer, accepts the misleading representation, takes the permitted jump, performs the authorised operation or hands a value to the next component exactly as the procedure says.
The consequence then depends on what the clerk is allowed to do. Confusion in a disposable scratch area may be harmless. The same confusion near credentials, durable state, private data, network access or another privileged component may matter enormously.
We will return to those distinctions elsewhere. This article is not meant to pre-empt them. Its purpose is to give us a common mental model: before arguing about the name of a security property, ask what information exists, what it means, where it points, which instruction runs next and what power is reachable from there.
A model we expect to reuse
We expect the filing clerk to become a recurring language in XMAKYNA writing because it makes difficult ideas approachable without making them childish. A pointer becomes a location written down. A jump becomes a change to the "next instruction" note. The program counter becomes the clerk's place marker. Memory becomes drawers. Execution becomes a sequence of tiny operations over those drawers.
Once that picture is in place, more advanced arguments have somewhere solid to land. We can talk about wrong state, stale state, misleading representation, redirection, authority and attacker-controlled confusion without pretending that the computer has human judgement or that the abstraction name itself explains the mechanism.
The model is useful when difficult engineering starts to feel more mysterious than it is. Strip away the scale and unfamiliarity and it is still, in a sense, a filing cabinet: get the state, representation and procedure right, and the machine will carry out the work.
That is why this lecture is more than a charming old explanation of computers. It gives us a durable way to think.
Lecture metadata and naming note
Speaker: Richard P. Feynman. The linked recording itself displays the date 26 September 1985 and identifies the setting as the Idiosyncratic Thinking workshop at the Esalen Institute, Big Sur, California.
The lecture has circulated under different titles, and some published references date related Esalen material differently. The linked upload is titled Hardware, Software and Heuristics; Computers From the Inside Out and The Feynman Lecture on Heuristics also appear elsewhere. Here, we refer to the lecture as Computers From the Inside Out.
Watch the lecture: Richard Feynman, Computers From the Inside Out (YouTube).
The bottom line
Strip a computer down far enough and a surprisingly durable picture remains: a very fast, very literal filing clerk with an effectively vast set of numbered drawers and a small repertoire of operations. Values can name other drawers. Instructions can change which instruction comes next. The program counter is simply the clerk's place marker. A jump changes that place marker. Enormous behaviour emerges from repeating these simple moves at extraordinary speed.
The model is simple, but not shallow. It reminds us that the machine acts on the state and representation we actually encoded, not the intention we hoped would somehow be understood. A confused clerk is a correctness problem. A clerk that an attacker can deliberately confuse, with useful authority attached, is a security problem. We expect to keep coming back to that idea.