How Large Models Are Teaching Software to Evolve

Most teams treat AI like a smarter autocomplete. The better use is stranger—and more profitable: using large language models to generate variations of working software and then selecting the best ones, the way nature “selects” traits over time.

That idea sits at the center of OpenAI’s research paper Evolution through large models (2022). The paper shows how a code-capable large language model can act like a high-quality “mutation engine” for genetic programming—producing edits that look like the kinds of changes humans make when they improve a program. When you combine those mutations with a search method that rewards diversity (MAP-Elites), you can rapidly create huge libraries of functional programs.

For our series, “How AI Is Powering Technology and Digital Services in the United States,” this matters because it explains what’s underneath many modern AI-driven digital services: faster iteration, more automated experimentation, and better software generation workflows. If you’re building SaaS, internal tools, marketing automation, or customer support systems, this research is a blueprint for how AI can help your software improve itself—within guardrails you define.

Evolution through large models: the simplest explanation that’s accurate

Evolution through large models (ELM) is a workflow where an LLM generates code edits (mutations), and an automated system tests and selects the best results—repeating the cycle until you get high-performing, diverse solutions.

Traditional genetic programming (GP) evolves programs by randomly mutating code and recombining parts. That approach works, but random changes are often useless: they break syntax, fail tests, or never explore meaningful alternatives. The paper’s core claim is direct:

If your “mutation operator” is a code-trained LLM, you get changes that are far more likely to compile, run, and improve behavior.

That’s not magic. It’s pattern learning. Code models learn from countless examples of humans making incremental edits: refactors, bug fixes, feature additions, performance tweaks. So when asked to mutate a program, the model tends to propose plausible next steps rather than nonsense.

Why MAP-Elites is the other half of the story

MAP-Elites is a search strategy that doesn’t just chase the single “best” solution—it builds a map of many good solutions across different behavioral niches.

In business terms, MAP-Elites is what you’d use when you don’t want one answer; you want a portfolio:

• Many viable implementations
• Many styles and tradeoffs
• Many approaches you can later specialize

That portfolio thinking is exactly what product teams need when requirements keep shifting (which they do—especially heading into a new calendar year, when roadmaps reset and budgets get reallocated).

What the Sodarace robot experiment really shows (and why it’s not just a toy)

The headline result is volume and novelty: ELM + MAP-Elites generated hundreds of thousands of functional Python programs that produced working “walking robots” in the Sodarace simulation—despite the base model never seeing the Sodarace domain during pretraining.

It’s tempting to dismiss simulated walkers as a novelty. I don’t.

Here’s what the experiment demonstrates that transfers cleanly to U.S. digital services:

1. You can create usable training data where none existed. The system generates a massive dataset of working artifacts.
2. You can bootstrap a new specialized model from that dataset. The paper describes training a conditional model that can output the right walker for a given terrain.
3. “General model → generate many candidates → select/test → train specialist model” is a repeatable loop.

That loop is basically an automated version of what strong engineering teams already do: prototype, test, keep what works, document patterns, and build reusable components. The difference is scale and speed.

The practical analog for SaaS teams

Replace “walker on terrain” with “feature behavior under constraints.” Examples:

• A checkout flow that must satisfy latency targets, conversion goals, and fraud rules
• A customer support triage workflow that must satisfy compliance and escalation rules
• A marketing content pipeline that must satisfy tone, accuracy, and brand constraints

In each case, you can treat “program” broadly: it might be code, prompts, routing logic, decision trees, or automation scripts.

The business takeaway: AI-assisted evolution beats one-shot generation

One-shot code generation is fine for demos. “Generate → test → mutate → retest” is what scales in production.

Many U.S. companies adopting AI in digital services hit the same wall: the first version looks great, but reliability and edge cases derail it. ELM-style workflows push you toward something more operational:

• Generate a candidate
• Run unit/integration tests
• Measure performance (latency, cost, success rate)
• Mutate the candidate (targeted improvements)
• Keep the best, keep the diverse, discard the broken

That’s not a research-only pattern. It’s how you turn AI into a repeatable delivery engine.

Where this shows up today in U.S. tech stacks

You’ll see “evolutionary” patterns—sometimes explicit, sometimes hidden—in:

• AI agent workflows that iterate on tool calls until tests pass
• Prompt optimization systems that A/B variations and keep winners
• RAG pipeline tuning where retrieval parameters get adjusted based on answer quality
• Marketing automation that generates multiple creative variants and selects by CTR/CVR
• Customer communication that generates multiple replies and selects by policy + satisfaction signals

The research helps justify a stance I’ve found useful in practice: don’t ask for the perfect output; ask for many candidates and build a ruthless selection process.

How to apply “ELM thinking” to content, automation, and customer comms

You can adapt the ELM pattern without building a robotics simulator—by treating your business metrics and QA checks as the “environment.”

Below are three concrete ways teams use this approach in technology and digital services.

1) Content creation: evolve drafts instead of approving the first decent one

Answer first: The fastest way to improve AI content quality is to generate diverse drafts and select using a scoring rubric, not taste.

A lightweight “evolution” loop for content:

1. Generate 10 variants of a landing page section (different angles, structure, and tone)
2. Automatically score for:
   • reading level
   • presence of required product claims
   • banned phrases / compliance constraints
   • similarity to existing pages (avoid duplicates)
3. Human edits the top 2
4. Run a live A/B test and feed results back into the next batch

That last step matters. Teams often stop at “generate variations.” ELM is about closing the loop with selection pressure.

2) Marketing automation: mutate workflows to reduce cost per lead

Answer first: If your marketing ops are stable enough to measure, they’re stable enough to evolve.

An example:

• Start with one automation sequence (email + SMS + retargeting)
• Generate 20 mutated sequences (timing, copy blocks, audience split rules)
• Simulate or sandbox-test against historical data
• Promote the best-performing variants into production

The metric becomes the environment: cost per lead, conversion rate, unsubscribes, spam complaints, time-to-first-response.

3) Customer support: evolve responses under policy guardrails

Answer first: Support quality improves when the model proposes multiple compliant responses and your system selects the safest, most helpful one.

A practical approach:

• Ask the model for 5 responses: concise, empathetic, technical, refund-forward, escalation-forward
• Run automated checks:
  • policy compliance
  • PII leakage
  • prohibited commitments
  • tone constraints
• Pick the highest-scoring response
• If none pass, route to a human

This is how AI is powering customer communication in the U.S. without turning every conversation into a risk.

The hidden cost: selection is harder than generation

The bottleneck isn’t producing candidates; it’s defining “better” in a way your system can measure.

ELM works because the environment can test outputs. In Sodarace, a program either produces a functional walker, and the walker’s performance is measurable. In business systems, you need similarly crisp evaluation.

Here’s what “crisp” looks like in real deployments:

• Unit tests and integration tests for code changes
• Golden sets (approved examples) for customer responses
• Rubrics that translate brand and legal constraints into checks
• Telemetry for real-world outcomes: resolution rate, churn, time saved

If you take one operational lesson from the research, make it this: build your evaluators before you scale generation. Otherwise you’ll mass-produce confusion.

A quick “ELM readiness” checklist

If you’re running a U.S.-based SaaS or digital service, you’re ready to try an ELM-style loop when you can answer these:

1. What’s the measurable objective? (speed, accuracy, CPL, retention)
2. What are the non-negotiable constraints? (privacy, compliance, tone)
3. What tests determine pass/fail?
4. What diversity do you want? (different approaches, segments, templates)
5. How will humans intervene when the system is uncertain?

What this means for 2026 planning (and why now is the right time)

Budget cycles and roadmaps reset around this week every year. Teams make one of two moves: they either “add AI features” as a line item, or they redesign workflows so AI actually compounds.

ELM points to the compounding path. When your systems can generate options and your organization can reliably select winners, improvement becomes continuous. That’s a big deal for lead generation, customer experience, and time-to-market.

If you’re serious about AI in technology and digital services in the United States, don’t treat large models as a chat interface. Treat them as a production engine that can:

• propose many viable implementations
• explore alternatives you wouldn’t consider
• improve outputs through automated selection

The open question worth sitting with: what would your product look like if every workflow—from content to code to support—could run thousands of “safe experiments” per week and keep only the winners?