The Darwin Loop - by K Meyer - Kate Meyer

K Meyer

SubscribeSign in

The Darwin Loop<br>Bringing the velocity of AI coding to deployment pipelines that were built for humans in 2004. From Feature Flags to Fitness Functions the path to Recursive Self-Improvement.

K Meyer<br>Jul 15, 2026

Share

I am one of those engineers who find improving deployment strategies catnip. At a previous company I set up a system where we get a change from our machines to prod in under 15 minutes. That included reviews, packaging, full testing, smoke testing with production data, canary deployment, automatic rollbacks, etc. Most companies don’t seek that level of efficiency, but in the age of AI, they are discovering the bottleneck was never the code, but the friction of deploying it. There is a problem when an AI agent can write a fix in 4 seconds, but can only validate the fix in 4 days and get it to the customer for feedback in 4 weeks.<br>The Karpathy autoresearch loop showed how agents can write code at machine speed, but only in a sandbox. In contrast today's human-gated deployment pipeline was built to stop humans from breaking 2004-era Java monoliths. The Darwin Loop is a deployment architecture derived from first principles: minimize Entropic Action by reducing state-transition cost and complexity so iteration frequency can increase. This architecture, while faster for humans, is built for agents iterating at machine speed and unlocks the evolutionary dynamics needed for Recursive Self-Improvement.<br>Death by a Thousand Flags

A cited “best practice” for software deployment is the following:<br>Wrap a change in a feature flag and test locally.

Open a PR, get review/tests, merge to main.

Branch main for release, build, test, and canary-deploy.

Enable the flag, roll it out, and review metrics.

Iterate if problems arise; otherwise remove the flag.

Unfortunately with this “best practice” for some teams it can take months to get a change out. Feature flags were made to reduce the failure blast radius, but they laundering complexity and bring problems of their own, including:<br>Wrapping is manual, not always done, and rarely complete.

Flags become a shadow VCS with unbounded debt.

2^N states make reasoning/testing impossible.

Three loops (PR, deploy, toggle) slow every change.

Flags reused over and over to bypass infrastructure overhead.

Some flags are permanently partially deployed or never removed.

The joke, but not joke: do you have a feature flag to remove a fully deployed feature flag?

The 2^N possible states turn database migrations and schema changes into high-stakes puzzles with no obvious safe path.

How did we get here?

We evolved our way here. Code reviews, unit tests, reproducible builds, canary releases, each layer tried to reduce the cost of a change if it went wrong. Two metrics drove everything:<br>Uptime : Deployments that bring down the site threaten revenue.

Deployment frequency : Releases contain features; delayed releases decrease revenue and decreases understanding about customer usage.

Feature flags will always exist because the business needs to be able to turn on and off full features. Maybe to delay a marketing campaign or to only allow features to specific customers such due to regional laws. When turning off a flag is faster than doing a release, pressure to wrap all changes in flags increases. This leads to Kate’s 15th software law:<br>Kate’s 15th software law: As deployment velocity approaches zero, reliance on runtime feature flags approaches infinity.

Bespoke release processes that tried to solve this also reflected their environment:<br>Mobile apps have a long external review cycle, so QA is staffed to catch errors before release.

Facebook’s “Move Fast and Break Things” used an hourly release train with canary deployment and automatic rollbacks. This worked in PHP, but as binaries and complexity grew, they eventually introduced a feature flag system.

Uber let engineers put changes into production so they could use them in the physical world, but only they can access it.

You could potentially engineer your way out of each problem such as designing a language with built-in revision control and concurrent phenotypes. But to find the actual solution, we need to return to first principles.<br>The Thermodynamics of Shipping Code

Every deployment has a cost, and that cost comes from three things1: how expensive the change is to make, how complex the system is, and how often you’re willing to try.<br>ξ: (Transition Cost) the cost of moving code from a developer’s mind to production execution. The literal CPU hours, Slack notifications, and manual approvals to get a commit live.

K: (Complexity) the structural complexity, the number of microservices or interconnected state systems that could break.

f: (Frequency) how frequently customers could get new changes.

A company releasing once per decade (f=0.1) will likely be outcompeted by one releasing yearly (f=1). The uptime and deployment frequency metrics map...