GENERATIVE ADVERSARIAL CODING

Software is now a population, not a project.

Stop asking one agent for one answer. Breed complete implementations, execute every one, kill nearly all of them, and make the survivors compete again.

By anghel4d

14 minute read

Jump to the experiment ↓

I have been trying to describe a change in software engineering and kept reaching for words that were too small: agent swarm, best-of-N, code generation, automated iteration. None of them describe the thing.

The thing is this: software has become an r-selected evolutionary organism. A frontier model can spawn a population of competing implementations, execute the whole test ecology against every individual, select the fittest, mutate or recombine the survivors, and do it again. Today that population might be three. Soon it is ten. Then fifty. Then a continuous loop.

I do not even write my actualplate by hand anymore.

Boilerplate is not the point. The unit of work is no longer the line, patch, prompt, or agent session. The unit is a generation.

01 / THE CONVERSION

I call it GANcoding.

GANcoding is population-scale software development in which generator models produce competing, executable descendants and an adversarial judge selects what gets to reproduce.

It is not a literal differentiable GAN. There is no requirement for backpropagation through a compiler. The conversion is architectural: generator against discriminator, many candidates instead of one answer, measured selection instead of conversational approval, inherited artifacts instead of a blank prompt.

GenerateN complete candidates
ExecuteOne hostile ecology
SelectMeasured survivors

“Agent swarm” describes who is busy. GANcoding describes why their outputs exist, how they are judged, and which outputs become ancestors. Parallelism alone is not evolution. You need population, variation, heredity, selection, and another generation.

02 / THE EXPERIMENT

I have done it exactly once.

The recovered primary trace says exactly how. At 16:31 UTC on 13 July 2026 I gave Opus 4.8 a 946-character architecture prompt: create persistent Opus supervisors, have each commission five Sol/high and ten Luna/xhigh implementations per stage, keep the supervisors blind, select winners, and propagate them through three stages. I then chose six supervisors and a bytecode VM.

There was no campaign skill. Opus improvised the control plane: it designed a sixteen-program judge, built golden components, proved the judge caught a deliberately broken jump fixup, smoke-tested one Sol and one Luna candidate, and only then spawned six persistent Opus supervisors. Those supervisors each commissioned fifteen independent implementations of one component from GPT coding models. They saw candidates and test results, not each other.

6blind supervisors
15×candidates each
3generations
270candidate calls
43mspawn to artifact
16/16fitness programs
23operations removed

Generation one evolved the assembler. Generation two inherited the winning assembler and evolved the executor. Generation three inherited both and evolved the optimizer. Every candidate faced the same executable battery; the head orchestrator independently re-tested finalists before composing the resulting VM. The first supervisor launched at 17:04:46. The working artifact was reported at 17:47:38: forty-two minutes and fifty-two seconds later.

The 270 figure is the production population: ninety assembler, ninety executor and ninety optimizer traces. It excludes the two smoke probes used to validate the runner before the real fan-out. Roughly forty thousand candidate lines were produced while the expensive supervisor context mostly contained compact briefs, scores, failure summaries and finalists. The finished Rust artifact passes all sixteen semantic programs. Its optimizer removes twenty-three operations from the battery without changing behavior. Every global component winner came from the Sol/high pool. Luna won one of eighteen local contests.

This was not three assistants brainstorming. It was a branching lineage with blind contests, objective execution, retained winners and inherited components. The repository contains the briefs, runners, candidate outputs, supervisor reports, fitness battery and final artifact. The claim is inspectable. The recovered provenance record identifies the primary traces and commits to them cryptographically.

03 / THE JUDGE

The judge is the product.

Generated volume is cheap. Selection pressure is scarce. If the judge rewards shallow tests, the population evolves test gaming. If it rewards benchmark theater, the population evolves benchmark theater. If it accepts confident prose in place of execution, it evolves liars.

So the judge cannot be one score and it cannot be one model. It is an executable stack of increasingly expensive rejection:

01

Compiler

Types, contracts, warnings, static analysis. Rejection before execution.

02

Runtime

Unit, integration, property and differential tests. Observable truth.

03

Sanitizers

ASan, UBSan and TSan on every viable candidate, not once before release.

04

Performance

Throughput, latency, allocations, memory, binary size and stability.

05

Frontier critic

A strong model reads every diff, failure and trace for what the finite suite did not name.

06

Tournament

Candidates face the same ecology. Only measured survivors become ancestors.

A frontier model evaluating every build is not a weak judge. Paired with the full suite, sanitizers, traces and cross-candidate evidence, it is the semantic layer above deterministic machinery. It can ask whether an implementation solved the intended problem, whether a test accidentally canonized a bug, and whether a locally faster patch made the architecture worse.

The model does not replace the compiler. The compiler does not replace the tests. The tests do not replace the profiler. The profiler does not replace semantic review. They are one ecology. Run it continuously.

04 / THE SUBSTRATE

This changes what a programming language is for.

We used to price language features partly by how much human labor they removed. That term is collapsing. An agent can emit ten versions of tedious glue before I finish complaining about the glue. Reflection is no longer compelling merely because it saves typing.

A language earns its place in GANcoding when it makes the judge stronger: impossible states rejected at compile time, richer properties expressed in types, constants evaluated before runtime, interfaces made unforgeable, sanitizers made more informative, and optimizers given facts they can actually exploit.

Choose the substrate that maximizesE[max(fitness) | fixed wall-clock + compute]

That is the real C23 versus C++26 question. Not whether “C++ mode” makes instructions magical. Not whether every C file should become an idiomatic object hierarchy. The question is whether stronger compile-time adjudication and specialization improve the best descendant found per budget more than compiler complexity, diagnostic noise, build latency and model confusion reduce the number of generations you can afford.

Call the experiment a conversion if you like. I do. But the merge criterion is evolutionary: does C+Ultra improve the judge enough to beat the extra generations the simpler substrate would have produced in the same time?

05 / THE PRIOR ART

The pieces exist. The production conversion is the claim.

I searched before naming this. I found no indexed use of “GANcoding” for this method. I did find a fast-moving family of systems that proves nearly every component independently. FunSearch and AlphaEvolve evolve programs against evaluators. Darwin Gödel Machine evolves coding agents. BACE and Agent-CoEvo coevolve solutions and tests. Loreley explores whole-repository commits with quality-diversity search.

I am not claiming to have invented evolutionary computation, automated evaluators, code-generating agents, or search over programs. The conversion is applying their combined logic to ordinary production software: whole implementations as the population, the complete engineering pipeline as the fitness ecology, frontier models on both sides of the contest, and generations as the normal development cadence.

AlphaEvolve is the closest ancestor. The distinction I care about is scope and operating model. This is not only algorithm discovery and not only self-improvement of an agent. It is how a codebase is developed: multiple competing versions of the same feature, all the time, with survivors becoming the next repository lineage.

06 / RUN THE EVIDENCE

A result without a harness is a story.

The retained bytecoders repository contains the working runner, model launcher, component briefs, deterministic fitness tests, candidate outputs, blind supervisor reports, composition step and final VM. Its current campaign skill is a later reconstruction. Re-running it verifies the surviving machinery and winning lineage; it does not retroactively make that skill the producer of the original run.

The stronger fossil record is the recovered conversation tree: one Opus head trace, six Opus supervisor traces, 270 production candidate traces, and the exact nineteen orchestration events that connected them. The raw JSONLs are privately preserved pending redaction because they contain hidden reasoning, local paths and machine metadata. Their hashes and a sanitized account are published in the provenance record.

git clone https://github.com/anghel4d/bytecoders
cd bytecoders
# repository access is currently required

# verify the fleet runner
bash .claude/skills/coding-campaign/reference/tests/test_run_fleet.sh

# recompose and test the winning lineage
CONTEST_ROOT=harness bash harness/compose_and_test.sh \
  orchestrator/substrate/A.rs \
  orchestrator/substrate/B.rs \
  orchestrator/substrate/C.rs

The next harness should be harsher. It should retain diverse elites instead of one winner, mutate tests alongside code without letting them collude, spend compute adaptively on uncertain contests, replay performance under noise, and preserve complete ancestry so a seductive regression can be bisected across generations.

It should also assume supervisors can fail the protocol. Prompts are not governance. The harness must verify required artifacts, execution counts, blindness boundaries and re-tests mechanically. An orchestration model is trusted only as far as its outputs can be checked.

We spent decades optimizing how humans edit one canonical tree. That is no longer the frontier.

The frontier is how quickly we can generate a forest, how brutally we can measure it, and how much truth survives selection.

Software is now a population.