Part I. The Monkey Learned to Type11 min

Random Code Programming

A chimpanzee sits on a chair at a table with a typewriter, hands on the keys. — A chimpanzee at a typewriter. New York Zoological Society photograph, around 1906. Source: New York Zoological Society, Public domain

In 2017 Victor Pelevin published the novel iPhuck 10, whose protagonist, Porfiry Petrovich, serves as a police-and-literary robot: he solves crimes, writes detective novels about them on the side, and treats people with the condescending tenderness of an adult listening to children try to explain to him how a television works. Somewhere in the second part of the novel we learn where such creatures come from in the first place, and the explanation reads like a mockery of the whole of computer science at once. A certain Reznik, the creator of the method, explains that nobody writes the program: machines generate random sequences of code, each one is then put through exhaustive testing, and whatever happens to work is kept. To make it vivid, Pelevin recalls the monkey that, given a typewriter and enough time, will sooner or later type out War and Peace. The method is called Random Code Programming, and the novel says it requires no great intelligence and most resembles embroidery.

In 2017 this read as another Pelevin joke, the kind where an absurd mechanism is delivered in the tone of technical documentation so that the reader first laughs and then, for a second, wonders whether he really finds it funny. Programmers, for their part, had no reason to wonder, because any of them could show you on a napkin in five minutes that the monkey at the typewriter would get stuck on the first meaningful ten-line function and never make it anywhere near War and Peace.

Only a few years passed before it turned out that Pelevin had been wrong about one detail, and that the detail was decisive.

Portrait of an older man with a short beard, in a jacket and tie. — Émile Borel, the mathematician who came up with the typing monkey in 1913. Photograph from 1929. Source: Agence de presse Mondial Photo-Presse, Public domain

The monkey at the typewriter is almost a century older than Pelevin. The French mathematician Émile Borel came up with it in 1913 while explaining what “practically impossible” means: an event can be permitted by the laws of probability and still never happen once in the entire lifetime of the universe. The arithmetic is easy, and it is worth doing at least once to get a feel for the scale. If a keyboard has ninety characters, then there are ninety to the hundredth power possible lines a hundred characters long, which is roughly a one followed by a hundred and ninety-five zeros. The observable universe, by current estimates, contains about a one followed by eighty zeros atoms. Even if you turned every atom into a monkey, sat it at a typewriter and made it type a billion lines a second since the Big Bang, this army would not arrive at a single correct line of code, and a program that does anything at all consists of thousands of such lines.

Engineers did in fact try the monkey, only in a refined form. In 1992 the American scientist John Koza published a book called Genetic Programming, in which he proposed growing programs the way nature grows species: take a population of random programs, check which of them solve the problem even slightly better than their neighbours, cross the successful ones, add random mutations, and repeat until something usable emerges. The method worked, in places rather well, but only on small problems where the program fit into a few dozen operations. On a problem the size of a banking application, evolution would need time comparable to what real evolution needed to get from single-celled organisms to accountants, and the client usually wants the result by the end of the quarter.

The weak point of both schemes, Borel’s and Koza’s, was randomness itself. The monkey presses every key with equal probability, and a mutation changes any symbol in a program with equal ease, so almost all the variants turn out to be garbage, and no amount of selection can cope with a mountain of garbage that size. If the monkey knew even a little about which letters usually follow which, things would go differently. If it had read everything humanity had typed before it, things would go very differently indeed.

Try itBorel’s monkey at the keyboard

The monkey types twelve-character lines and waits for one short line of code to come up among them. Below is the chapter’s sum: how many lines an army would get through if every atom in the universe were a monkey.

In May 2020 engineers at OpenAI gathered fifty-four million open projects from GitHub, the world’s largest shared repository of program code, and picked out everything written in the Python language. After cleaning, a hundred and fifty-nine gigabytes of text remained, which is, roughly speaking, several billion lines that people had written, corrected, commented on and cursed over the course of decades. A model called Codex was trained on those lines, and in July 2021 a paper with its results came out.

What such a model can do is easiest to explain without the words “neural network” and “artificial intelligence.” The model sees the beginning of a text and predicts what most probably comes next, then writes that continuation, looks at the resulting text again, predicts again, and so on, symbol by symbol. When it was trained on code, it saw millions of times how a line begun in a certain way usually ends, how a function that sorts a list is usually built, and which mistakes people most often corrected in the next version. Strictly speaking, the model still chooses the next symbol at random, but its probabilities are not equal: it throws dice loaded with all the code people wrote before it. It is the same monkey of Borel’s, except that it has read the whole of GitHub.

The authors of the Codex paper devised a hundred and sixty-four problems, each with a set of automatic checks that show whether a solution works. On the first attempt the model solved 28.8 percent of the problems, which was decent for a machine in 2021 and mediocre for a programmer. Then the researchers did something very Pelevinian: they asked the model to write a hundred candidate solutions to each problem and looked at whether at least one of the hundred passed the checks. That was the case for 70.2 percent of the problems. The paper itself modestly calls this trick a surprisingly effective strategy, although it is Reznik’s method in its pure form: generate a lot of code and keep whatever passed the test.

Half a year later the research lab DeepMind took the same idea to industrial scale. Its system AlphaCode entered competitive programming contests, where people solve, against the clock, problems designed specifically to be hard to solve. For each problem AlphaCode generated an enormous number of programs, for some problems into the millions, and then discarded every one that failed the examples given in the problem statement. Selection destroyed about ninety-nine percent of what had been written. The system grouped the remaining thousands of variants by similarity of behaviour and sent the judges no more than ten. Across several contests on the Codeforces platform it ended up roughly in the middle of the table, above 46 percent of the human participants, among whom were quite a few very strong programmers who had spent years training.

So Pelevin had guessed the scheme almost entirely: generation, exhaustive testing, selection of the survivors. His only mistake was that he imagined the generation as blind, whereas the machines of the 2020s generate with an aim accumulated from the code of all humanity. That single correction moved the monkey out of the category of thought experiments and into the category of working tools.

Night in a kitchen: a person, back to us, sits before an open laptop beside cold tea and a notebook, a hand hovering over the keys. — Vibe coding: a person looks at the result and pastes the error back to the model.

On the second of February 2025 Andrej Karpathy, one of the best-known researchers in the field, wrote a short post on social media that he later described as a shower thought. He described a new way of programming in which you give yourself over entirely to the vibes, embrace exponentials and forget that the code even exists: you tell the machine what you want, look at the result, and if something breaks, you copy the error message back and ask it to fix it. He called it vibe coding. Nine months later the Collins dictionary named vibe coding its word of the year for 2025.

If you set Karpathy’s post next to Reznik’s scheme, the resemblance is almost frightening. The generation is done by the model, that same monkey that has read GitHub. There is selection too, only the exhaustive testing of the novel has been replaced by a person who looks at the screen and decides whether what he sees resembles what he wanted. If the button can be clicked, it works; if the page opened, it is done; if an error pops up, it is sent back to the model and the next variant is generated.

Vibe coding looks like a sudden breakthrough of February 2025 only to those who have read neither Pelevin nor the Codex paper. Structurally it is Random Code Programming given an enormous head start in the form of all of humanity’s public code, with the role of the selection committee handed to one tired person at a screen.

I myself arrived at this comparison a little over four months after Karpathy, under circumstances Pelevin would probably have appreciated. By the summer of 2025 I was already assembling programs as his post describes: explaining to the model what I wanted, running whatever it produced, seeing where it fell apart, and handing the error back, until after a few rounds something working came together out of plausible pieces. On the twenty-first of June, in a conversation with one of those models, I remembered Reznik and wrote a sentence I quote verbatim, because there is no shorter way to put it: “Pelevin’s random code programming is basically vibe coding.” The model politely objected that in Pelevin this is more of a satirical image and offered to discuss what exactly the writer was being ironic about. I had to ask it to stop fantasising and to find the principle itself in the novel, so from the outside the scene looked rather Pelevinian: I was explaining to the monkey that it was a monkey, and the monkey was offering me a literary analysis in return.

Two months later, on the twenty-fifth of August, the thought became less pleasant. I wrote again that RCP is random code programming, read vibe coding, and this time added that from the point of view of the neural network itself there is no difference between them at all. The model does not care whether its work is called programming, embroidery or generating variants: in every case it continues the text in the most probable way, and the difference between “wrote a program” and “produced a plausible sequence of symbols” arises only on the outside, at the moment when someone runs that sequence and looks at what happens. That same summer a broader sentence escaped me, to the effect that, objectively speaking, the whole universe runs on RCP, but we will get to that at the very end of the book. And by May 2026, describing how I develop software myself now, I was already speaking of Pelevin’s method without any quotation marks: this is what I use.

If a working program really can arise from generating variants, selecting them and accumulating successful states, an awkward question comes up: what exactly have we been calling programming for sixty years? The answer is easy to miss, because the generator takes up all the attention. Models write code faster than people, models write code cheaper than people, every six months a new model comes out that writes even faster and even cheaper, and every conversation revolves around whose model is stronger. And yet in Pelevin’s novel, in the Codex paper and in the AlphaCode system alike, all the cleverness of the construction lies in the selection. A random generator, even a very well-trained one, produces variants, but it is the check that decides which of them deserves to live, and what survives in the end depends on the quality of that check. A hundred Codex variants without automatic tests would be just a hundred plausible-looking texts among which there is no way to tell the working from the broken. A million AlphaCode programs without the examples from the problem statement would be a million programs and nothing more.

Random Code Programming works for the simple reason that selection turned out to matter more than where a variant came from. The check does not care whether the solution was devised by a brilliant engineer after a sleepless night, assembled by evolution over a million generations, or produced by a model on the forty-seventh attempt: the code either passes the check or goes into the bin, and if the check is good, what survives is good. Taken to its conclusion, this observation explains almost everything the rest of this book is about, from tests and automatic inspectors to the memory of machines and the places where people will turn out to be irreplaceable.

Pelevin, remarkably, understood this better than many engineers. In his account of Reznik’s scheme, the successful sequences come alive because, in the words of the hero, something called the World Mind enters them from within. Today’s developers usually look for the world mind in the model itself and argue about whether it understands what it writes. I think it should be looked for somewhere else, in the place where it is decided which of the written variants stays and which goes into the bin.

In vibe coding that job falls to the person looking at the screen, and he copes with it as long as the program is small and the consequences of a mistake amount to a button of the wrong colour. Then the program grows, other people’s money and other people’s data come to stand behind it, while the inspector still looks only at whether the page opened, and the monkey that has read all of GitHub finds itself before a committee that judges War and Peace by its cover.