Ant colonies find short paths without a map, and a slime mold once grew a network about as efficient as the Tokyo rail system. Honeybee swarms pick a new home by reaching a quorum, with no queen making the call. Researchers have spent decades turning observations like these into equations, testing them, and publishing them through peer review. For most of that time, a small software team could admire the work and do very little with it.
Why small teams couldn't use it
Ant colony optimization has been in the literature since the early 1990s. Reynolds published boids, the flocking model behind a generation of game and film effects, in 1987. Tero and colleagues wrote down the slime mold's network rules in Science in 2010.
Using them was the hard part. You had to:
- read a paper written for other specialists, in their notation
- turn the equations into code, often from MATLAB or from nothing
- build a simulation to see whether your version behaved like theirs
- figure out which of a dozen parameters actually mattered
That's weeks of work before you learn whether the idea fits your problem. A research lab can spend those weeks. A team of three shipping a product usually can't, so the ideas stayed in the papers.
What changed
A language model can now sit next to you while you read. Paste in the methods section and ask what each symbol means, which parameters the authors swept, and what result they reported. Then have it turn the update rule into a function and build a test harness, a parameter sweep, and a plot around it. Each of those steps used to take days, and now each takes minutes.
Take the pheromone update from Ant System. In the paper it reads:
τij(t+n) = ρ · τij(t) + Δτij, where Δτij = Σk Q / Lk over the ants k that used edge (i, j)
Once every ant has finished a tour, each trail keeps a fraction ρ of its strength and the rest evaporates. Then each ant adds Q / Lk to the edges it used, so shorter tours leave more pheromone. In Rust:
/// One Ant System trail update, run after every ant has finished a tour.
/// `rho` is trail persistence, so 1 - rho evaporates. Each tour is (edges, length).
fn update_pheromone(tau: &mut [Vec<f64>], rho: f64, tours: &[(Vec<(usize, usize)>, f64)], q: f64) {
for row in tau.iter_mut() {
for t in row.iter_mut() {
*t *= rho; // keep rho, lose 1 - rho
}
}
for (edges, length) in tours {
let deposit = q / length; // Q / L_k: shorter tour, bigger deposit
for &(i, j) in edges {
tau[i][j] += deposit;
tau[j][i] += deposit; // symmetric TSP: (i, j) and (j, i) are one edge
}
}
}
You can read the core of a famous algorithm in a minute. The paper still has what took the authors years to learn: why evaporation matters, which values of ρ work, and where the method breaks.
This is why I think small teams are in a good spot right now. Peer review already sorted out which mechanisms hold up, and AI handles the tedious work of getting them into code. What's left for you is the question you care about anyway: does this mechanism help your system?
Reproduce one result before you trust your code
A model can misread an equation as confidently as it reads one correctly, so the workflow needs a check. The paper already gives you one.
- Pick one paper and one mechanism.
- Have the model extract the update rule, the parameters, and the reported results into a short spec. Check the spec against the equations yourself.
- Build the smallest simulation that runs the rule.
- Reproduce one figure or number from the paper. That's your acceptance test.
- Only then point it at your own problem, and measure it against whatever you do today.
Step 4 is the easiest to skip and the one I'd never skip. If your ants don't find the short path on the paper's benchmark, they won't find it in your system either.
My own experiment: SMESH
I built SMESH this way. The inspiration was mycorrhizal networks, where trees exchange signals through fungal threads in the soil and no single tree is in charge. I wanted AI agents to coordinate the same way. An agent leaves a signal on a shared field, other agents that agree reinforce it, and signals nobody supports fade on their own.
I could run all of it as a plain Rust simulation, with no language model and no API key, and watch the field settle before I trusted it with real agents.
Biologists are still arguing about how much trees really share through those networks. A 2023 review argued the popular "wood wide web" story has gotten ahead of the field evidence. That doesn't hurt the software. I'm borrowing the mechanism, signals that decay unless reinforced, and my simulation tests whether it works for agents, whatever the forest is actually doing.
Where to start
Pick a coordination problem you already have: retries, load balancing, task routing, deciding when a group of services agrees. Then look for the organism that solved something like it.
- Routing and shortest paths: ant colony optimization, Physarum networks
- Who does which job: response-threshold models of insect division of labor
- Group decisions: honeybee quorum sensing
- Motion and spacing: boids and flocking
Read one paper with a model beside you, reproduce one result, and see whether it earns a place in your system.
What would you borrow first?
Top comments (0)