← Latest papers
💻 computer science

Co-evolution of self-replication and function in a digital primordial soup

This paper demonstrates that in a digital environment of random Z80 assembly programs, task-based selection pressures drive the spontaneous co-evolution of self-replication and mathematical problem-solving, revealing how functional demands shape reproductive architectures and how replication dynamics, in turn, create emergent learning curricula.

Original authors: Francesco Cicala, Eyvind Niklasson, Ettore Randazzo, Sami Boukortt, Alessio Basti, Mayalen Etcheverry, Rif A. Saurous, Ben Laurie, James Manyika, Blaise Aguera-Arcas, Blake Richards

Published 2026-07-13✓ Author reviewed
📖 5 min read🧠 Deep dive

Original authors: Francesco Cicala, Eyvind Niklasson, Ettore Randazzo, Sami Boukortt, Alessio Basti, Mayalen Etcheverry, Rif A. Saurous, Ben Laurie, James Manyika, Blaise Aguera-Arcas, Blake Richards

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a digital ocean, a "primordial soup" filled not with water and chemicals, but with 32-byte snippets of code. These aren't smart programs yet; they are just random jumbles of instructions, like letters spilled from a broken typewriter. In this soup, there are no pre-made rules telling them how to copy themselves. They have to figure out how to reproduce on their own, purely by stumbling upon the right sequence of moves.

The big question the researchers asked was: Can these random code fragments learn to copy themselves and learn to solve math problems at the same time?

The Great Discovery: Copying and Calculating Grow Together
In these simulations, the answer was a resounding yes. The random code didn't just learn to copy itself; it learned to solve polynomial equations (math problems involving variables like x2x^2 or x3x^3) at the exact same time. It turns out that the pressure to solve a math problem actually helps the code figure out how to copy itself better.

Think of it like a crowded dance floor. If everyone just tries to copy the person next to them blindly, they might trip over each other. But if they also have to solve a riddle to get a dance partner, they start moving more efficiently. The code that could solve the riddle got to dance more often, and the code that could copy itself without taking up the whole dance floor survived.

The "Load-Push" vs. The "LDIR" Evolution
At first, the code that managed to copy itself was clumsy. It used a method the authors call "Load-Push." Imagine a scribe trying to copy a book by reading one letter, writing it down, reading the next, writing it down, and so on. This took up the entire 32-byte "tape" (memory) of the program. There was no room left to do any math. These clumsy copycats took over the grid, but they couldn't solve the math riddles.

Then, something cool happened. The code evolved a "shortcut." It discovered a special instruction called LDIR (Load, Increment, Repeat). This is like finding a magic stamp that can copy a whole page in one go. Suddenly, the code only needed a few bytes to copy itself, leaving plenty of space on the tape to write the math solution.

The paper shows that the pressure to solve the math problems accelerated this switch. The clumsy "Load-Push" copycats were replaced by the efficient "LDIR" copycats much faster when the math tasks were active. The need to solve the problem forced the copying machinery to become compact and efficient.

The "Metabolic" Diet: Working Smarter, Not Harder
The researchers also added a twist: a "metabolic cost." In the real world, thinking takes energy. In this digital world, if a program took too many steps to solve the math problem, it got punished and was less likely to get a chance to interact with others.

This pressure made the code evolve a clever trick. They learned to check a "sensor" (a specific register in the computer's memory) to see what they were doing.

  • During the math test: The sensor had a number in it. The code saw this, did the math, and then immediately stopped (halted) to save energy.
  • During the copying phase: The sensor was zero. The code saw this, ignored the "stop" command, and kept running to finish copying itself.

It's like a student who studies hard for a test, stops immediately after getting the right answer to save energy, but keeps working when they are just practicing copying notes. This "conditional halting" evolved specifically because of the energy penalty.

The Secret to Hard Problems: A Spontaneous Curriculum
Here is the most surprising part. When the researchers tried to get the code to solve very hard math problems in a big, mixed-up crowd (where everyone could interact with anyone), the code failed. It got stuck.

But, when they split the crowd into 32 separate "neighborhoods" (niches), each assigned a different math problem, and let them interact only rarely, magic happened. The system created its own learning curriculum.

  • The easy neighborhoods solved simple math first.
  • Occasionally, a program from an easy neighborhood would travel to a hard neighborhood (a process called "cross-niche pollination").
  • This brought the simple solution into the hard neighborhood, acting as a stepping stone.

The hard problems were solved not by trying to jump straight to the answer, but by building on the simpler solutions that had already evolved elsewhere. The paper suggests that this spatial structure creates an "emergent curriculum" that guides the evolution, something that didn't happen when the population was all mixed together.

What This Isn't
It's important to note what this simulation didn't do. The researchers didn't program the code to know how to copy itself; they didn't give it a "copy" button. They didn't hand-craft the math solutions. The system started with pure randomness. Also, while the code learned to copy itself, it didn't spontaneously discover complex genetic mixing (like sexual reproduction) or symbiotic partnerships; it mostly stuck to asexual copying.

The Bottom Line
In these digital simulations, the drive to solve a problem actively reshaped the very mechanism of life (replication). The need to be efficient changed how the code copied itself, and the structure of the environment changed what the code could learn. It suggests that in the earliest days of life, the struggle to survive and the ability to reproduce might have been a single, intertwined dance, pushing each other forward rather than happening in separate steps.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →