Entropy Containment Engineer
I can imagine a fairly ordinary Tuesday a few years from now.
A compliance lead notices a regulator has tightened rules around “high-risk accounts.” She opens an internal admin tool, writes what she wants in plain language, and an agent generates the change: a new check, a UI nudge, an audit record, a couple of dashboards, a feature flag. It rolls out slowly, watches itself, and keeps going.
Across the office, a support manager is tired of a refund workflow that forces three manual steps and produces inconsistent outcomes. He describes the intent, the agent threads the needle through a messy back-office system, adds guardrails, and ships the fix.
A marketer wants a different onboarding path for a specific campaign. She asks for two screens and a new event. The agent wires it up end to end.
None of this is “deep engineering,” but it’s still real engineering surface area: money, customer data, risk controls, and downstream obligations. The novelty is not that changes can be made; it’s that they can be made all day, by many people, without queuing behind a scarce engineer.
There have already been plenty of essays about this shift – domain specialists using AI to build, the impact on software company moats, on margins, on valuations, on who captures value in the economy. All of that is interesting and probably important.
One aspect I haven’t heard discussed as much is more operational and less glamorous: when this shift actually happens inside a real company, how do we stop the system from gradually degrading as the rate of change goes up by 100× or 1000×?
If you step back and look at the system as a whole, that gradual breakdown of order has a name: Entropy.
Entropy, in software terms (and why we’ve always fought it)
Entropy in a codebase isn’t a bug count. It’s the gap between the system’s intended shape and what it becomes after years of local decisions that drag it away from that ideal shape.
Every working system has an intended shape, even when nobody wrote it down. There are boundaries (what belongs where), invariants (what must remain true), and meanings (what a “customer,” a “refund,” a “risk flag” actually is). When those meanings stay crisp, the system stays legible: people can predict consequences, reuse parts safely, and make changes without constantly rediscovering hidden rules. When meanings blur, the system can still be changed for a while, but the cost shows up as bugs, performance issues, and an increasing fear of changing anything.
This is not a new problem. It’s what “software maintenance” has always been!
When we do “software maintenance”, we are reducing entropy.
Refactoring is entropy reduction. Dependency upgrades are entropy reduction. Cleaning up duplicated business rules, untangling accidental dependencies, fixing CI so it behaves predictably, keeping runbooks in shape, it’s all the same family of work: restoring the intended shape so the next change is still possible.
“Software Maintenance” has always been a part of software engineering. In healthy companies (and healthy systems), we find time to do maintenance regularly. However, it’s not the primary activity: that’s still shipping features and shipping value.
Under 1000× change, entropy management becomes the job
If domain specialists can ship changes with AI agents, the volume and frequency of modification changes character. The codebase stops evolving in bursts around sprint boundaries and starts evolving continuously, with many hands applying small, locally rational adjustments throughout the day.
With 100× or 1000× more change, treating entropy reduction as a side activity stops being viable. The curve outruns you. So the question becomes: who does the entropy work when almost anyone can generate new code and ship new behavior?
The answer is still “software engineers,” but the role changes. Engineers stop being primarily the people who implement most business features, and become the people responsible for the system’s coherence while change hits it from all sides. They still build, but their highest leverage work moves toward the machinery that keeps the system understandable, stable enough to evolve, and resistant to slow degradation.
The tools we have, and the tools we need
Some of the answer is already sitting inside software engineering. We know how to test systems, how to control releases, how to refactor, how to encode constraints. We simply have not had to apply these disciplines with the level of consistency that 1000× change will demand.
At the same time, not everything we need lives inside the traditional SDLC toolbox. If software starts to resemble other large systems under constant, loosely coordinated change, then we should expect to borrow ideas from those systems as well.
Three software engineering practices that move from optional to essential
Before looking elsewhere, it’s worth being honest about how much unused leverage already exists inside our own discipline. The practices below are familiar. What changes is not the concept, but the intensity and consistency with which they are applied.
Continuous Refactoring, industrialized
Refactoring is one of the cleanest entropy reduction tools we have. The problem is scale. As a craft activity done occasionally by humans, it cannot keep up with a world where the codebase is being modified constantly.
In a high-change environment, refactoring needs to look less like an annual cleanup and more like continuous background maintenance. Imagine an army of AI agents that engineers run and supervise: shrinking complexity hotspots, deduplicating business rules, deleting dead code, keeping dependencies fresh, and nudging the codebase back toward a small set of consistent patterns.
Engineers define what “healthy” means, constrain the agents so they do not introduce risk, and decide when automated cleanup should give way to human judgment. Entropy reduction becomes continuous rather than episodic.
Error Budgets + Progressive Delivery
Error budgets were popularized by Google’s SRE practice, but adoption remains uneven. Under 1000× change, they become central.
The mechanism is straightforward. You set a Service Level Objective. You track performance against it. When you overspend your error budget, you slow down or pause new changes and focus on restoring stability until you are back within bounds.
Pair that with disciplined release engineering: staged rollouts, canaries, automatic rollback when metrics move in the wrong direction, and monitoring that is designed alongside the change itself rather than after it. Add production-like simulation and regular chaos exercises so fragility is discovered deliberately.
The underlying idea is not to prevent change, but to control its blast radius and respond quickly when reality disagrees with the plan. Engineers build and tune this feedback system so that high change velocity does not automatically translate into high instability.
Architectural Fitness Functions + Policy-as-Code
Earlier, we talked about boundaries, invariants, and meanings. Those define the system’s intended shape. Over time, the quiet risk is drift: boundaries becoming porous, invariants being weakened, meanings diverging across modules.
Today, much of our defense against that drift is human code review. That depends on attention and memory, and it does not scale when changes arrive continuously from many sources.
If we want to preserve intent at 1000× scale, the checks must be automatic.
Architectural fitness functions encode structural intent directly: which modules may depend on which, what invariants must always hold, what kinds of coupling are forbidden. Policy-as-code applies the same principle to operational and business rules: logging constraints, audit requirements, sensitive state transitions.
The system’s constitution is expressed as executable rules. Engineers spend less time reviewing every change and more time engineering the checks that preserve boundaries, invariants, and meanings at scale.
Three ideas we need to borrow from other complex systems
There are other systems that live under constant, loosely coordinated change and would degrade quickly if left unmanaged.
Cities evolve through thousands of independent decisions each day, yet remain livable because of zoning, codes, and inspection regimes. Living organisms grow and adapt, yet remain viable because growth is paired with removal. Markets coordinate countless actors, yet avoid collapse because pricing introduces friction when shared resources are stressed.
If software systems begin to experience similar levels of uncoordinated change, it is reasonable to borrow from these mechanisms.
Stable Core, Fast Edge (zoning)
A useful architectural principle is to keep a stable core and push innovation to the edges.
The core is where the most expensive invariants live: identity, permissions, ledger rules, durable state, risk calculations. The edge is where variation belongs: UI flows, routing logic, experiments, workflow glue.
Under modest rates of change, that separation can remain informal. Under 1000× change, it cannot. Not all edge changes are equal. Some are superficial. Others reach back into core assumptions through shared data models or hidden coupling.
Cities address similar gradients of risk through zoning. Different areas carry different rules and levels of scrutiny. The same idea applies in software. A copy tweak can move quickly. A workflow change touching billing requires stronger verification. A direct change to the ledger or permission model belongs in the tightest zone.
Zoning turns an architectural idea into an enforceable structure. Engineers define the zones, specify what crosses boundaries, and integrate the checks into the delivery pipeline so variability concentrates where it is cheap and stays contained where it is dangerous.
Built-in Death (feature expiry as default)
A large share of software complexity is accumulated history. Features remain long after their context has faded. Exceptions introduced under pressure settle into the baseline.
Biological systems pair growth with removal. Cells are created and cleared out. Tissue is repaired and damaged parts are broken down. Health depends on maintaining that balance over time. Biologists call this programmed cell death, or apoptosis.
Software rarely enforces that balance. By default, it remembers everything, which means the surface area of the system only expands and each new change must navigate old intent.
A practical response is to make expiry the default. New features and experiments ship with an explicit end date. They are renewed if they prove value; otherwise they are removed. Deletion becomes part of the normal lifecycle rather than a rare, anxious cleanup.
This is entropy control in practice. Engineers make it feasible by building visibility into unused paths, safe migration tooling, reliable rollback, and release processes that treat deletion as a first-class change.
Pricing the Cost of Change
When many people can change a shared system, the tragedy of the commons appears quickly. Each change may be reasonable in isolation, yet the shared system slowly absorbs disorder if the cost of adding complexity is invisible.
Markets address this by using pricing to reflect scarcity. When a shared resource is stressed, the cost of consuming it rises, introducing friction that protects the system as a whole.
Singapore’s Certificate of Entitlement (COE) system is one concrete example. The number of cars allowed on the road is capped, and the right to own one is allocated through bidding. When demand increases, prices rise, reflecting limited capacity and preventing congestion from overwhelming the system.
Software under 1000× change faces a similar constraint. The scarce resource is system coherence. We need to price the cost of change.
That price does not have to be monetary. It can mean fewer release windows, stricter automated checks, mandatory review, or reduced access to the most sensitive zones without sponsorship. It can also influence performance evaluation. If someone consistently improves the system while shipping value, that should count. If someone repeatedly injects entropy without benefit, that should also be visible.
The point is not punishment. It is alignment. Engineers design the measurement, attribution, and enforcement so that the long-term health of the system is reflected in the day-to-day economics of making change.
The title is slightly silly, but the job is real
“Entropy Containment Engineer” is not a serious title. But I think it’s a useful one, because it points at a real inversion.
If AI agents make feature creation cheap, then the bottleneck moves. It is no longer the ability to produce change. It is the ability of the system to absorb change without losing its shape, without losing coherence: clean boundaries, stable meanings, and a system that can keep evolving without turning into a mess.
Engineers become the people who build and operate the machinery that resists drift. That fight the entropy.
Continuous refactoring that runs in the background so complexity does not quietly accumulate. Error budgets and progressive delivery that treat stability as a managed resource. Fitness functions and policy-as-code that encode boundaries, invariants, and meanings so they do not drift. Zoning that recognizes gradients of risk rather than pretending everything is either core or edge. Built-in expiry so growth is paired with removal. Pricing mechanisms that make the tragedy of the commons visible in day-to-day decisions.
In the agent-assisted era, the hard part will not be producing change. It will be keeping the system coherent as change becomes abundant.
The engineers who matter most will be the ones who design and operate that entropy fighting machinery.