Two evolutionary domains
Code breeding changes the machinery that trains, routes, evaluates, or serves models. Model breeding changes learned parameters, adapters, experts, quantization, tokenization, or training recipes. They interact, but they should not share unrestricted authority.
| Dimension | Code breeding | Model breeding |
|---|---|---|
| Primary artifact | Source, AST, IR, workflow, kernel, policy | Weights, adapters, expert partitions, tokenizer, recipe |
| Typical mutation | Patch, algorithm swap, threshold logic, compiler option | Fine-tune, prune, quantize, merge, distill |
| Main evaluator | Tests, static analysis, security, determinism, performance | Task utility, robustness, calibration, bias, cost |
| Catastrophic failure | Execution compromise or policy bypass | Behavioral regression or representational drift |
| Release boundary | Software supply chain | Model supply chain |
| Required rollback | Prior code and configuration | Prior model package and routing state |
The self-referential validation hazard
A candidate must never be able to modify the mechanism that decides whether it is fit. If a model can rewrite its evaluator, reward, holdout data, or hard constraints, selection pressure shifts toward passing the metric rather than improving the intended capability.
The same rule applies to code-breeding agents. A generated patch may improve the evaluation harness only through a separate, higher-trust change process with independent review and re-baselining.
Recommended trust zones
- Candidate zone: model artifacts and generated code run with minimal permissions.
- Evaluation zone: frozen suites, judges, and scoring code; read-only to candidates.
- Policy zone: hard invariants, mutation allowlists, approval thresholds, and resource ceilings.
- Release zone: signing, canary control, rollback, and production promotion.
- Audit zone: append-only evidence and lineage records.
Cross-domain change protocol
A model-breeding experiment may reveal that the router needs a new feature. That does not authorize automatic code mutation in production. It creates a code-change proposal with evidence, which enters the software lifecycle.
IF model_experiment.requires_code_change
proposal <- CREATE_CODE_CHANGE_PROPOSAL(
rationale = model_experiment.evidence,
requested_capability = model_experiment.missing_runtime_feature
)
SEND_TO_CODE_BREEDING_PIPELINE(proposal)
PAUSE_MODEL_PROMOTION_UNTIL(code_release_is_approved)
END IFSeparation improves scientific validity
Distinct pipelines make it possible to attribute gains. When code, data, evaluator, and weights all change together, the experiment cannot explain why performance moved. Controlled breeding changes one mutation family at a time or uses factorial experiments with explicit ablations.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.