Chaos Engineering

Chaos engineering usually means deliberately introducing controlled failures into a system: terminate a service, increase network latency, remove a dependency, then see whether the system remains reliable.

That is a useful technique, but the definition misses much of the thinking behind it.

I use the term more broadly. Chaos engineering is the discipline of working with complex systems whose future behavior cannot be predicted precisely enough. It reveals assumptions and actual behavior, limits the consequences of surprise, and helps us adapt.

This view extends beyond production infrastructure. The software product, the team building it, the business around it, its users and suppliers, and now its AI agents all belong to the same interconnected system. Reliability depends on every part.

Chaos is not disorder

In everyday speech, chaos means mess or confusion. In mathematics, it has a more precise meaning: deterministic systems can be extremely sensitive to their initial conditions. Tiny differences compound through feedback until two apparently similar trajectories produce very different outcomes.

A development team is not literally governed by the equations of a double pendulum. The analogy has limits, but its operational lesson is useful.

When we interact with a sufficiently complex system, we face several unavoidable constraints:

We never see its complete state.
Important variables remain outside our control.
Measurements arrive late, incomplete, or approximate.
The system keeps changing while we study it.
Interactions produce effects that the parts do not explain in isolation.
Uncertainty grows with the prediction horizon.

We may know the common regimes where a system tends to settle, which chaos theory calls attractors, without knowing its exact path. We can see a team approaching burnout, a service nearing a dangerous capacity boundary, or a market becoming unstable. We usually cannot name the precise incident, date, and sequence that will follow.

Weather forecasting is the familiar example. Tomorrow's weather can often be predicted reasonably well. A precise forecast months ahead cannot, because limited observations and small errors accumulate. Technological and organizational systems have similar horizons, though their mechanisms differ.

Prediction remains useful. Every prediction is also conditional, approximate, and perishable.

The software is not the whole system

Traditional chaos engineering focuses on infrastructure because it is comparatively easy to instrument and disturb. We can terminate a container or isolate a region. We can exhaust a resource or slow an API, define the blast radius, and measure the result.

Production reliability is sociotechnical. The actual system includes:

code <--> infrastructure <--> team <--> users <--> market <--> finances <--> regulation

Each part has its own cycles and feedback loops. Development changes the product, which changes user behavior and business priorities. Those priorities change the team. The team changes the architecture, and the next development cycle begins under different conditions.

A lead developer can become unavailable. A vendor can change its API or pricing. A financial crisis can wipe out a market, while an unexpected research result can make a year-long roadmap obsolete. Team morale may alter delivery capacity faster than any planning model can account for.

This resembles a chain of coupled pendulums. Development, testing, deployment, hiring, finance, promotion, support, and research all affect one another. Optimizing one loop in isolation can destabilize another.

Killing a database replica may teach us something about technical failover. It cannot tell us whether one person alone understands the recovery procedure, whether management will permit the recovery plan, or whether the business can survive the interruption.

Chaos engineering must examine the whole system, including the people and organizations around the machines.

The illusion of control

People naturally reduce systems to manageable pieces. We assign each piece a metric, create a process, and start feeling that the whole thing is under control.

Engineering depends on decomposition. The danger comes when we mistake the model for reality.

A roadmap states an intention. A metric shows one projection of the system. A process may improve coordination, but it cannot guarantee an outcome when the variables that decide it are unknown.

Organizations can end up paying for rituals that produce predictable costs and little new information. Meetings happen because they are on the calendar. Reports appear because they have always appeared. Teams repeatedly revise long plans and treat the revision itself as evidence of control.

Retrospectives can fall into the same trap. They are useful when they update our model and improve the next experiment. They become corporate shamanism when they build a tidy, deterministic story after the fact and pretend the outcome was always predictable.

The observer adds another complication by participating in the system. Our models, metrics, and incentives change the behavior we want to measure. Once a target becomes a KPI, people optimize it and the system moves toward the simplified model. The process can create a self-fulfilling prophecy, although its effect has limits and remains hard to predict.

We influence the system from within. We do not control it from some external vantage point.

From prediction to adaptation

Chaos is already present. Chaos engineering develops the observation, boundaries, and responses we need to work within it.

The core loop is short:

observe --> form a hypothesis --> intervene --> measure --> update

Strategy still matters. Its time frame and confidence should match the stability of the environment. A five-year direction may be useful. A detailed five-year sequence of implementation tasks is fiction.

Several practices follow from this principle.

Instrument reality

Monitoring is how an organization detects change; dashboards are only one part of it.

Useful observation draws on technical telemetry and business data, along with user behavior, incident reports, research results, and qualitative signals from the team. A service may be green while its maintainers are exhausted. Revenue may grow while the support load becomes unsustainable. No single dashboard represents the whole state.

Shorten the prediction horizon

When uncertainty compounds over time, shorter feedback loops reduce exposure. Evaluate the situation, make and implement a bounded decision, collect evidence, then reassess.

Short iterations can speed up delivery. More importantly, they keep us from navigating too long with an obsolete map.

Prefer reversible interventions

Feature flags, canary releases, staged migrations, backups, shadow traffic, and small experiments preserve a way back. Reversibility turns a confident decision into a testable hypothesis.

Some decisions are difficult to reverse. They need more evidence and wider review, with a smaller blast radius around them.

Limit propagation

Loose coupling, isolation boundaries, graceful degradation, and independent recovery paths stop local failures from spreading across the system.

Organizations face the same problem. Knowledge held by one person, approval controlled by one manager, revenue tied to one customer, and infrastructure housed with one provider are all forms of tight coupling.

Remove toxic dependencies

A dependency becomes toxic when it is likely enough to fail and the damage would be disproportionate. It might be a library, vendor, employee, model provider, distribution channel, or business assumption.

We cannot remove every dependency. We can identify those that silently control the system and build alternatives before an emergency chooses for us.

Preserve optionality

A flexible architecture makes the next unknown change affordable. It does not try to anticipate every future requirement.

Modular boundaries, transferable knowledge, portable data, financial runway, and multiple technical paths all preserve options. In an unpredictable environment, those options provide resilience.

Follow positive signals

People often frame chaos engineering entirely around failure, even though complex systems also produce unexpected opportunities. An engineer discovers a new strength. Users adopt a feature in an unanticipated way. A new technology suddenly makes a difficult idea practical.

Observation should look for drivers of development as actively as it looks for risks. Resilience includes the ability to resist damage and to redirect energy toward a promising state.

Experiments still require discipline

Giving chaos engineering a broader scope does not excuse random action. A chaos experiment deliberately enters uncertain territory, so it should be more disciplined than an ordinary change.

Before intervening, we should define:

the steady state or behavior we believe currently exists;
the assumption being tested;
the smallest useful experiment;
the maximum acceptable blast radius;
the signals that indicate success, failure, or danger;
the abort condition;
the recovery path;
the knowledge we expect to gain.

An experiment should leave us with a better model of the system's behavior. Mere survival provides only one data point.

Experiments should test recovery as well as resistance. Perfect robustness is usually an illusion: components fail, people make mistakes, and external conditions change. Recovery tells us whether the system notices the problem, contains it, recovers, and learns.

AI makes the dynamics visible

Large language models and agentic development make these dynamics hard to ignore.

An LLM may produce different responses to the same request. Its output depends on the prompt, system instructions, available context, retrieved information, model version, tool results, sampling configuration, and hidden runtime conditions. Even with constrained generation, the environment around the model keeps changing.

Agentic development adds feedback:

prompt --> plan --> tool call --> changed repository --> new context --> next plan

A small difference in the first interpretation may lead the agent to inspect a different file. That changes the plan and the edit, which in turn changes the tests and the context for the next step. The effect compounds. Two runs can start with the same task and end with substantially different implementations.

Operationally, the butterfly effect means sensitivity amplified by feedback.

AI agents also make intervention faster and cheaper, which accelerates the loop. A system can enter an unexplored state in minutes instead of weeks. If observation and recovery do not speed up with experimentation, we simply produce failures faster.

AI systems therefore need evaluation as distributions rather than anecdotes. One successful run proves very little. Useful evaluation includes repeated trials against representative and adversarial scenarios, with the context recorded and outcomes measured. It also tests recovery. Model behavior in production deserves the same monitoring as any other uncertain dependency.

AI strengthens the case for chaos engineering and makes agentic development one of its most important domains.

The human role

If an AI agent can analyze data, write code, run tests, operate tools, and respond to monitoring signals, what remains for the human?

Trying to control every step creates the illusion of a deterministic result and strips away much of the agent's value.

Humans must provide the judgment that a local optimization loop cannot safely supply.

Set direction and meaning

An agent can optimize a defined objective. It cannot independently decide which future is worth pursuing.

Humans choose the system's purpose, whom it should serve, which values it must preserve, and which trade-offs remain unacceptable even when they improve a metric. These are value judgments and acts of responsibility, not missing technical requirements.

Humans define the direction in which movement remains meaningful without specifying every move.

Maintain temporal and situational grounding

An LLM does not experience time passing. It works with the context available during a run, which may omit a conversation from this morning or a changing market condition. It may miss an exhausted colleague, a physical constraint, or a user reaction that has not yet become data.

Humans connect the current digital state with the current real-world situation. They notice when an assumption has expired and when the task itself needs to change.

Curate context and memory

Old decisions, irrelevant files, misleading examples, and duplicated instructions can destabilize an agent just as much as missing information. Adding context is not automatically an improvement.

Humans decide what the system should remember or forget, which evidence is authoritative, and which contradictions need investigation. Context engineering actively controls the initial conditions of the next reasoning loop. It is more than clerical preparation.

Read weak signals

Automated monitoring detects what we have learned to measure. Humans still notice signals whose meaning has not yet been formalized: patterns in user frustration, a subtle loss of product coherence, an emerging strength in a team member, or the sense that a technically correct result solves the wrong problem.

The gap is clearest where digital systems meet physical reality and human perception. Text and numerical proxies alone cannot adequately evaluate virtual and augmented reality, industrial interfaces, spatial design, accessibility, aesthetics, or social interaction. A model can assist, but it does not inhabit the experience being designed.

Define boundaries and stop conditions

Autonomy without boundaries creates an uncontrolled blast radius.

Humans define permissions, budgets, environments, reversible actions, escalation paths, and stop conditions. They decide which changes need independent verification and which systems an experiment must never modify.

Approving every action is unnecessary. The control surface needs to match the possible consequences.

Shape the attractor

Because the observer belongs to the system, humans do more than react to signals. Architecture, incentives, examples, tool access, review culture, and definitions of success all influence where the system tends to settle.

An exact trajectory remains beyond our control. We can still make desirable states easier to reach and dangerous ones harder to enter. That is a practical way to exert control in a complex system.

Accept accountability

An agent can recommend, generate, and execute. It cannot bear responsibility for consequences in the human world.

Someone must decide whether the evidence is sufficient, the risk is justified, and the release should proceed. That person must also judge whether the resulting harm or benefit is acceptable. Accountability makes meaningful autonomy possible; treating it as an inefficiency misses its purpose.

What this requires from a human

The "conqueror of chaos" is not a heroic controller outside the system. No one stands outside it. A better image is a skilled navigator who knows the map is incomplete and the conditions keep changing.

That role asks us to:

Separate evidence from inference and state our confidence honestly.
See feedback loops and second-order effects instead of isolated tasks.
Notice weak signals before they become obvious incidents.
Reason in ranges, scenarios, and trade-offs without reaching for false certainty.
Make hypotheses testable, bound each intervention, and keep recovery possible.
Update a mental model without defending it merely because it was once useful.
Make clear decisions even when uncertainty remains.
Connect architecture and business with users, teams, and physical reality.
Take responsibility for consequential decisions instead of transferring moral agency to a tool.

Human judgment is fallible. People bring bias, fatigue, politics, and their own chaotic behavior into the loop. Human decisions therefore need observability too, through recorded reasoning, peer challenge, independent review, and feedback from outcomes.

A workable approach combines machine speed and breadth with human meaning, perception, and accountability. It also builds checks for the weaknesses of both.