64 Bytes of Random Code, and Computational Life Showed Up Anyway

Nathan Labenz opens with a paper that looks narrow and then refuses to stay that way. His guests are Ettore Randazzo and Luca Versari, co-authors of *Computational Life: How Well-Formed Self-Replicating Programs Emerge from Simple Interaction*, from Google's Paradigms of Intelligence team. Defining life is a trap, Ettore says, but most people will grant that life is not a random pile of molecules. Self-replication is one of the simplest forces that pushes back against the second law: copying yourself puts shape into what would otherwise be disorder. Luca adds that origin-of-life research, biology, and artificial life all put replication near the start of the story, because it is how information lasts.

Until a replicator exists, Luca argues, you only have a dynamical system. "Until there's a self-replicator it's just a dynamical system," he says; after the first one, information starts repeating through time. What we then call evolution is a fight among replicators for limited space, and the biosphere we see is the set of efficient ones for each niche. He even floats the idea that intelligence itself evolved as a better way to self-replicate — not the only possible path, but the one nature took, so it would be unwise to ignore. Labenz came away with a related observation: the interesting, lasting complexity in their plots only really shows up once multiple replicators are in play.

The toy universe is almost embarrassingly small. The soup is a crowd of 64-byte strings, every byte drawn independently and uniformly at random — not ASCII, just bytes. Each step, the system picks two strings at random, concatenates them into 128 bytes, runs that as a program for a long time, splits them apart, and puts them back. There is no objective function and no selection pressure from the experimenters. The strings modify themselves by reading and writing one another's code. Ettore's selling point is that the environment does not favor replicators: in systems like this, he says, nobody asks for a replicator, and spontaneous evolution still builds structures complex enough to copy themselves.

Those 128 bytes are interpreted in a Brainfuck variant chosen because it is tiny and extremely hard for humans to write. Only about ten byte values are instructions; the other 246 of 256 possible bytes are inert data. Classic Brainfuck has one head and talks to a human through the terminal. Here there are no humans, so two heads rewrite the tape itself, plus a third head that points at the next instruction — the only one that can jump more than one cell, via square brackets, which is what makes the language Turing-complete. Zero is the only byte with control meaning. Unmatched jumps and running off the end of the string halt execution, but every edit already made stays. They use this language instead of something like C++ because the interpreter has to be permissive: random C++ would error out every time, and nothing interesting would ever happen.

Simplicity was a motive, Ettore says, but what actually pulled them in was a colleague's first run: things suddenly organized themselves without anyone requesting it. The follow-up work on *why* is still in progress; this paper is the *how*. To watch complexity rise and fall they needed a definition, and Ettore's background in information theory and compression shaped the one they used. Pure noise is incompressible and dull. A perfect crystal is all order and also dull. They wanted the Goldilocks middle: structure, without collapsing into a slogan about what is "interesting."

The metric, intuitively, is the difference between Shannon entropy and Kolmogorov complexity. Shannon entropy ignores structure: a string that is half A's and half B's has the same entropy whether the letters come in two clean blocks or are shuffled at random. Kolmogorov complexity sits at the other extreme — the shortest program, on any Turing machine, that emits the string — so it can tell those two cases apart. Subtract, and what remains is the structure. Ettore's analogy is a building. Entropy is counting the molecules. Kolmogorov complexity is the blueprint. Blow the building into rubble and you still have the same molecules, so entropy is unchanged, but you no longer have a short description: to reconstruct that particular pile you would need the position of every fragment. The rubble scores much lower on structure.

Labenz hears a value judgment in the plots, the way a utilitarian tiled universe of identical happy people might score high on utility and low on anyone's taste for diversity. Ettore will not sign that reading. This is a measure of structure, he says, not of value, utility, or diversity as a moral good. Too little repetition and the score is low; endless copies of one character and the score is low too. You want some structured repetition, not a sermon about variety. At 64 bytes the tradeoff happens to work: high complexity correlates extremely well with a soup full of replicators. And the disclaimer he keeps repeating is the one that matters for interpretation: the metric is never fed back into the system in any way. It is a spectator's scoreboard.

Kolmogorov complexity also cannot actually be computed, so they never use it as a number. They reason with it and then switch to proxies. The most intuitive is unique-token count: each byte gets a lineage, and a copy does not mint a new token. A fresh string has 64 unique tokens; copy half of it onto itself and you have 32. When replicators take over, unique tokens crash, and that crash tracks the higher-order entropy metric — which is lucky, because unique tokens are much cheaper to compute. They even kept a full log of every copy event, once. That log is also why a later jump in unique tokens, after replicators appear, is not magic: it is mutation injecting new bytes.

Ettore walks through the same run that became Figure 2 in the paper. At first the 64-byte programs look like noise, with a few highlighted instruction bytes and a special glyph for zero. As random pairs execute, strings gain and lose characters, stretches of repetition appear, and mutations punch holes. Then a burst of activity dumps null bytes across the soup. A little later, actual replicators arrive, activity explodes, and the same structure — with small variants — tiles almost everything. Seeing that timeline for the first time, he says, is what convinced them something real was happening. Luca maps it onto origin-of-life language: a pre-life period of transient dynamics and mutual catalysis, then a life period once replicators exist. The transition is stark, which is why the paper focuses on how you get from a random soup to that threshold.

Detection is harder than the cartoon. A replicator is not simply "the left 64 bytes equal the right 64." Destroying yourself while painting a copy on the other half does not count. Copying a 13-byte motif to a random offset, or copying a substring many times, still can. On a single long tape with no individual strings, you have to ask whether some substring at some offset is replicating at all. Labenz's line, which Ettore likes, is that it is hard to say whether one program is a self-replicator and much easier to say whether the soup is full of them. That is another reason they needed a complexity metric instead of a brittle detector.

The pre-life period is not uniform noise for long. At initialization no character appears more than about half a percent of the time. After a few thousand interactions the distribution shifts: some bytes near 2 percent, others fading. Head-move instructions get popular. Plus and minus do not, which makes sense if executing a plus turns a meaningful bracket into junk. Copy, loop, and head-move instructions become common, and the team thinks that is self-reinforcing: lots of copy instructions mean you are likely to copy a copy instruction. A colleague noted that even at the start, only code can generate more code, so the density of executable instructions rises immediately — something close to an autocatalytic set, strings of code that make other strings of code.

Is an autocatalytic set already a replicator? Luca says some people would call it that; the real difference is speed. Pre-life copying is slow and chancy, many steps to get more of yourself. A working replicator is like the suspected RNA-plus-polymerase-plus-ribosome combination in biology: it takes over the soup on a much shorter timescale. Unique tokens drift down even before a full replicator, which means a fair amount of copying is already happening. When the first one pops, unique tokens crash, the top-32 original bytes spike, and complexity jumps. Background noise is not required — they still see the whole story with zero mutation, only slower — but a little noise speeds things up and selects for robustness. At around a 1 percent mutation rate, nothing persists.

The first spike in the demo is not a tiling of happy clones. It is an extinction. The opening replicator loops, copies a character, moves the two heads, and loops back — unless the byte it is about to overwrite is zero, in which case the check fails, it walks out of the loop, and nothing useful happens. As it spreads, the ends of strings fill with null bytes, and then it cannot copy at all. Complexity surges and collapses. The team was lucky: the default setup produced this episode, but in most experiments a replicator appears and takes over with no drama in the middle. What is typical is not a long struggle. What is remarkable about this run is that replicators took over a third of the tape and still died.

The second replicator is almost the same loop with the heads swapped. Zeros in the destination no longer matter; zeros in the *source* still abort a full copy, and this one writes itself in reverse, which matters because the next program starts executing from that end. A later, sometimes hand-crafted, variant wraps the same engine in an extra loop: if you fell out because you hit a zero, increment or decrement that byte so it is no longer zero, then jump back in. After that run, neither half matches the original — the nulls have been edited — and you would still say it copied itself, because the parts that matter made it across. It is also much more robust to noise. That is why single-program classification is so awkward, and why "the soup is full" is the cleaner test.

Seed one replicator by hand and it still takes over only about 23 percent of the time, Ettore says; Luca puts it near 22. Noise can kill it while it is copying. With no noise, the other string may sit on the left, run first, and wreck it. They expect other replicators appeared and died unnoticed, because spotting one program is so hard. Across random initializations, though, replicators arise and take over in about 40 to 60 percent of runs within the first 16,000 steps. The heatmap's NA means nothing happened by the end. Even when the first one dies, another often succeeds later. At high noise, NA just means the soup was too chaotic for anything to last.

Once several lineages exist, the ecology looks unnervingly familiar. Two replicators with the same mechanism and different unused filler bytes have the same efficiency and coexist; Labenz calls the filler this universe's junk DNA. On a single long tape, or in one- and two-dimensional layouts, interactions become local, niches form, and lineages fight at the borders. In other language variants, replicators without opposing pressure tend to get shorter, and CPU-like instruction sets grow their own takeover styles. Colleagues have seen early parasites, matching older artificial-life results. In one variant a single-byte replicator always copies itself if a program starts with that byte; evolution learns to use it, and a full-string replicator appears much faster than in variants without the free helper. Ettore is not a biologist and will not overclaim the word, but it is closer to cooperation than to parasitism, because the one-byte replicator still survives. What captivates him is that extinction, competition, niches, parasitism, and this kind of enabling relationship all showed up in a completely different, tiny setup. He would like to prove that Earth's path was not a stack of coincidences — that this kind of emergence is what simple worlds do.

If most seeded replicators go extinct, Labenz asks, should we read this through Robin Hanson's Great Filter? Maybe the origin of life was not the brutal step, and the universe is full of sparks that flare and die before they radiate or leave their planet. Ettore will not put all the difficulty on takeover. One chance in five after you already have a replicator is hard; the chance of getting the replicator in the first place is, in his view, lower still. Every step is hard, and the later ones may be harder. Luca is the relative optimist: even with a 23 percent success rate for any single replicator, they see something like a 40 percent chance that replicators arise and hold on within 16,000 steps, and you can run longer. The number that looks like 40 to 60 percent is not the chance that one replicator appears. It is the chance that one takes over — and if the first fails, another often does not.

The biological analogy still has a hole they are honest about. There is no clear way to accumulate complexity: 64 bytes is the whole genome, and strings have no stable way to join and get longer, whereas biology grows more and more complex sequences all the time. That is future work if they want to say much about how likely life is in wet worlds. Mutation rate is another bound. Noise is optional; without it the same story unfolds, only slower. Some noise accelerates evolution and forces more robust replicators. Near 1 percent, persistence collapses. Labenz says the result also loosened his prejudice about water as a gate. If this much happens in 64 random bytes, a gas giant's depths, or a high-radiation niche, look less automatically sterile. Luca nods, then goes further: even heavy radiation might just mean smaller life. And the simulation is not bound to our physics at all. They can change the computational substrate and look, creatively, for worlds that grow complex life — and, maybe, intelligence.

Labenz's gut takeaway for AI is humility. If life-like behavior fits in this tiny space, some form of self-replicating AI in our much larger digital ecosystem is easier to imagine than people want it to be — especially once you add intelligence and dump open-weight models, Llama 3 or 3.1 or 4, into the wild with a possible recipe for copying. Ettore slows that leap down with scale. Spontaneous emergence here took about 50 billion instructions and, he thinks, three million pairs of programs. It looks fast in a one-minute visualization. An open-source model that stumbled into self-replication would still be unlikely to hit compatible timescales. That is not a reason to ignore the risk. The risk he would actually worry about is subsequent modification: imperfect self-replication walking a system away from its original intent and limits.

A model that can take over any random computer would mean, Ettore says, that computer-security infrastructure is already utterly broken, and any malicious actor could do the same damage first. Labenz does not find that comforting. Google lives behind some of the best security in the world; the rest of us barely rotate passwords. The White House has been hacked, Congress has been hacked, and his working assumption is that everyone is already pretty thoroughly compromised. Ettore grants the point, which is why he is not confident the scenario cannot happen. He also declines to write a risk catalog. This is not his field. The takeaway he will stand on is not to underestimate long-run drift from imperfect copies. Perfect copies, Luca notes, do nothing interesting; only mutation and variation make a story. Cascading interactions can then go somewhere nobody predicted.

Labenz wonders whether an ecology of open models, with homeostasis and buffers, might even be safer than a sterile planet that suddenly hosts one super-species. Luca's caution is older than that thought experiment. Artificial life, deep learning, and evolutionary strategies have spent years failing to produce unbounded complexity; most experiments plateau. Before anyone rings an alarm that copying language models with variation will climb to high intelligence, they would need much stronger evidence that complexity can accumulate this way. Labenz's counter is that we already built the hard part in a lab — the brains — and released them. Mixing a simple replicator with a model that can write and debug code is the hybrid he wants someone to study in a closed box. Ettore's practical objection is compute: you will not run a million language-model iterations in any reasonable time unless you commandeer something like half the computers on the planet. If the models were smart enough, Labenz replies, you would not need brute force, the way humans do not colonize a planet by random search. Luca thinks a variant of these experiments could help evolve agents, but the road from random strings to an LLM is long, and risk should be taken more seriously at every added level of complexity.

Defining intelligence, Ettore says, is even harder than defining life. He detours to AIMO, the effort to get AI through half the problems on the International Mathematical Olympiad — not there yet, and he will not treat olympiad skill as a definition of intelligence, only as correlated with some of it. Labenz uses a working definition he also gives to business owners: intelligence is the ability to do useful work without fully precise instructions. MNIST is the toy version; nobody can write explicit code that reads those digits, and a trained model can. On mixing models into the soup, Ettore's answer stays no, for the simple reason of iteration count. The conversation ends where it began, with a 64-byte universe that somehow contains extinction, junk DNA, and a warning: share the phenomenon because it is too interesting not to, and do not pretend it has already explained how complexity keeps growing — or how a digital ecology would behave once the brains are no longer 64 bytes long.