Why the industry’s answer to “how do we know it actually works” was never a verification method — and why the real answer had to be an infrastructure change, not a discipline.
The Claim, and Where It’s Actually True
Something has genuinely shifted. For a large class of well-bounded problems — a REST endpoint against a fixed schema, a function with a clear contract, a migration script with a known source and target — today’s coding agents really do get you close to “describe it clearly, get it built.” That’s not hype. It’s the direct consequence of models that can hold a precise spec, generate an implementation, run the tests, and iterate until they pass, in minutes, at near-zero marginal cost per attempt.
From Code to Cognition named this shift correctly a year before it became obvious: software development is a directed-evolution engine — hypothesize, branch, test, select — and AI’s contribution is to make the “branch and test one hypothesis” loop nearly free. Its conclusion, stated plainly: “The primary bottleneck in innovation will no longer be the implementation capacity of the engineering team. Instead, it will be the human capacity to generate novel, valuable hypotheses and to define clear, meaningful fitness functions.”
That’s correct, but it’s also incomplete in a way that matters a lot once you leave the domain the essay actually tested it against.
The Bottleneck Has Two Parts, and Only One of Them Is About Description
“Define a clear fitness function” sounds like a description problem — write the test, write the spec, be precise. For code-shaped problems, it mostly is. But a fitness function isn’t just a description; it’s a description of what counts as success, and for anything beyond a single service’s local behavior, evaluating it requires running the thing and observing what actually happens. That’s a second, different problem: not can you describe the criteria, but can you cheaply put a candidate in front of that criteria and get a real answer.
Git-native SDE, exactly as described in From Code to Cognition, solves this beautifully for code and for domains that already look like code. The finance case study in that essay is the tell: backtesting works as a fitness function because historical market data is cheap to replay, deterministic, and already sitting there. Branch, replay, score, done. That’s why algorithmic trading is “the most mature analogue” — the trial infrastructure already existed before anyone called it an SDE.
Distributed systems don’t have that infrastructure. A Git branch is not a running system. It has no traffic, no real dependency graph, no data, no emergent timing behavior. You can describe a service’s contract with perfect clarity and still have no idea what happens when three other services, a queue, and a cache all interact with your change under real load — because that behavior doesn’t exist anywhere until you actually run the whole graph. There is no backtest for a distributed system. The trial itself has to be built, every time, and historically that has been expensive: shared staging, scheduled deploy windows, environments nobody can safely experiment in without stepping on someone else.
What the Industry Built Instead of a Trial
Faced with an expensive trial, the industry didn’t make trials cheaper. Operations did what operations has been doing throughout this fragmentation cycle: it absorbed the coordination problem that architecture failed to solve, then packaged its own inability to reason about the result into something that could be presented as a discipline.
Chaos engineering is not itself the goal here — nobody sets out to build an organization around injecting failure. It’s a downstream artifact of a prior, more consequential move: the transfer of architectural coordination from development to operations that the X-Ops critique on this site documents in detail. Once that transfer happens — once nobody holding the pager also holds the mental model of the whole system — “understand why this works” is no longer an available option, so it gets replaced with “prepare for it to fail unpredictably,” and that replacement gets a name, a conference track, and a vendor category. The essay is blunt about the sequence: “X-Ops disciplines emerge claiming to solve distributed systems complexity, then systematically create more operational complexity while transferring coordination control from development to operations,” culminating in what it calls “surrender mechanisms like chaos engineering.” The x-ops flat-worldview series makes the same point about the whole tool family at once: gateways, service mesh, FinOps, and chaos tooling are reached for as “crutches to cover up the lack of proper boundary design,” precisely because none of them require anyone to do the boundary design.
That’s why “packaged and exploited” is the more accurate description than “a good method that degraded.” Nobody is chasing chaos engineering as an end. It’s what’s left to sell once an ops-led organization has already given up on the understanding that would make it unnecessary — a way to convert “we don’t know why this system behaves this way” into a line item that looks like rigor. Look at what that conversion produces in practice, as documented across this site’s own coverage: a stack becomes “so brittle and interconnected that its failure modes are completely unpredictable,” so the organization runs chaos experiments “to create an illusion of resilience.” The output is a gameday report, not validated knowledge. Nobody can tell you whether the fault they injected resembles anything that will actually happen, because nobody fully understands the system they’re testing — that’s the whole reason it’s fragile. The Colonizers’ Tax names the same pattern as one of several disciplines an organization hires specifically to manage the bill for complexity operations already agreed to own, rather than to reduce it.
That’s the correction worth stating plainly: chaos engineering’s failure mode isn’t misapplication of a good method that started out aimed at verification. Its institutional function was never verification — verification was never the thing being purchased. It is a political artifact of the ops-led power transfer that preceded it: evidence manufactured for a budget review or a postmortem, not a trial that answers “does this actually work.” It was built to look like rigor, downstream of an org chart that had already made rigor someone else’s job.
The Actual Fix Was Never a Discipline. It Was a Cost Curve.
The real alternative to “inject a plausible-sounding fault into a system nobody understands” is “give the hypothesis its own complete, real system and just run it.” Not a simulation of the dependency graph — the actual dependency graph, wired the same way production is wired, disposable when you’re done. That was always the correct trial. It was just never cheap enough to be anyone’s default.
This is the part of the ONDEMANDENV design that wasn’t originally framed around AI at all — it was built so a human developer could branch a feature without fear of breaking a shared environment. An Enver is a complete, isolated version of a service’s bounded context: its own infrastructure, its own dependencies, its own endpoints. A Constellation is the emergent, full dependency graph you get when you follow producer/consumer edges out from any enver — the actual running system, not a diagram of it. Cloning one is a single commit message, and multiple constellations coexist in the same accounts simultaneously, because contract compatibility is proven deductively at compile time rather than negotiated at the shared-environment level. That compile-time proof is what makes cheap cloning safe: most of what a chaos experiment is groping for in the dark — will this edge break, is this contract still honored — is already answered before the clone even exists.
What’s left after that deductive layer is exactly the thing that can’t be proven statically: real emergent behavior under real conditions. And now there’s a cheap, disposable, real system to run it in — a genuine trial, not a performance of one.
The Design Was for Humans. It Turns Out to Be the Missing Piece for AI.
Put the two halves back together. AI collapses the cost of generating an implementation once you have a clear enough description — that part of From Code to Cognition’s thesis holds. What it does not do, and cannot do by getting faster at code generation, is tell you whether the fitness function itself is right, or cheaply confirm that a candidate actually satisfies it once real interactions are involved. Those are exactly the two things left standing once implementation is nearly free: judgment about what “correct” means, and infrastructure to test that judgment against reality without it costing a shared environment and a scheduled maintenance window every time.
The first is still an irreducibly human problem — domain knowledge, tacit understanding, the willingness to say “I don’t actually know if this fitness function is right” instead of shipping it anyway. No model fixes that by being more fluent.
The second was solvable all along, just not by hiring a discipline to cope with its absence. It required making the trial itself cheap — the same infrastructure move that was always going to matter for fearless human experimentation, now mattering more, because AI-generated hypotheses arrive faster than any organization can staff a chaos team to theatrically wave at each one. An architecture built so a developer could safely try something turns out to be the architecture an army of AI agents actually needs to try a thousand things and find out, for real, which ones survive contact with a running system — not which ones merely compiled, and not which ones somebody wrote a hopeful gameday report about.