Probabilistic engineering and the 24-7 employee

Software is quietly becoming a probabilistic system, and almost no one is saying it out loud.

We built our profession around deterministic code. Write it, test it, ship it, know it works - but in my experience that contract is breaking. Inside the top few percent of operators at truly AI-native companies, the codebase has started to become something you believe works, with a probability you can no longer precisely state. The workday is changing as a consequence, and so are the roles, the organizations, the training pipelines, and the nature of what it means to ship.

I noticed because I built one.

A few months ago, in the evenings after my day job running Modular, I started building a side project called Compound Loop - a system that orchestrates multiple frontier models against each other to write, review, and merge code more or less autonomously. I would set it running on a real problem before I went to bed, and I would wake up and triage a stack of pull requests that had not existed the night before. Some were excellent, some were wrong, and some surfaced a question I did not know to ask. By 8 a.m. I was not catching up on yesterday's work - I was deciding which of the overnight jobs to keep, while the system kept analyzing logs and adding more PRs. The continuous compounding nature of it was, and still is, infectious to watch.

For the first time in the history of knowledge work, the person who went home did not take the only copy of their brain with them. 9-9-6 as a concept is dead, and we are simply 24-7 employees now - but the 24-7 employee is not a person working 24 hours, it is a person whose agents work with enormous parallelization. Most teams in 2026 still bottleneck on coordination rather than typing, and most organizations have barely begun to restructure, but the frontier is always where the future shows up first, and the frontier is already here. This essay is not a description of the industry at large, but rather a description of what is already happening inside the most AI-native teams, and where I believe that pulls the rest of the industry.

Roles are not just collapsing upward - they are splitting

Inside the most AI-native teams, the pattern is messier than the clean "everyone levels up" story most commentary is selling. Some operators really are moving up the stack: the best engineers are becoming more effective product managers, working at engineering's abstraction layer, the best product managers are becoming system architects, and the best architects are thinking about distribution, growth, and the shape of the market. For this group - maybe the top tier of any team - the work is more leveraged than it has ever been, and they are having the best years of their careers.

But that is not the whole picture, and pretending it is does a disservice to everyone else. Alongside the upward shift, a downward pressure is fragmenting roles in ways the headlines are not covering. Plenty of engineers are not becoming architects - instead they are becoming spec writers, reviewers, and agent babysitters, operators who spend their days translating intent into machine-readable prompts and then grading the machine's work against standards they themselves might not fully possess. Some of that work is genuinely important, but some of it is the 2026 equivalent of data entry, dressed up in new terminology.

We need to be honest about what that means for the people doing it. These fragmented roles will be paid less, valued less, and in many cases become career dead ends - a layer of output-wrangling work the system needs but does not reward. The pay gap between the top tercile running fleets of agents effectively and the middle tier managing their exhaust will be wider than the pay gap between engineers and sales reps was in the previous era. That gap is already opening inside the companies I watch closely, and I don't believe it is going to close on its own.

One honest note on where the scarce work has moved. In AI infrastructure, kernel performance and compiler design and hardware abstraction remain deeply defensible moats, because there is still a high degree of determinism needed at the lowest levels of systems engineering. But at the level of building software on top of those moats, the center of gravity has shifted hard toward the human inputs a machine cannot yet replicate, and that shift is real and accelerating.

Jevons was right about coal, and he is right about code

In 1865, the economist William Stanley Jevons observed that more efficient steam engines led to more coal consumption rather than less - efficiency expanded the set of things worth building engines for. We are living the software version of that same observation, and it is one of the most exciting moments the profession has ever seen. As the unit cost of writing code approaches zero, we are not writing less, we are writing vastly more and shipping vastly more, and the best teams are leaning into the curve with both hands.

The companies that believe the scaling laws are unbounded are building accordingly, and they will be the power-law-distributed winners.

Many of my friends at leading AI-native companies are already rapidly moving there in practice. Agents are opening pull requests, reviewing each other's work, and closing them without a human ever touching the keyboard, with a continuously live log monitoring loop to rapidly fix issues. Self-healing test suites rewrite themselves when the underlying code changes. Autonomous experimentation loops spin up, measure, and tear down a hundred hypotheses in the time a team once ran three. Documentation updates itself faster on merges using tightly honed AI skills that also self-improve. We are moving from a world where features were bound by the constraint of how fast engineers could type to one where we are bound on human creativity, management of agentic systems, and how fast the product surface can absorb the output.

In my view, this is a wonderful moment to build. The throughput gains are not subtle, and the teams that have genuinely restructured around agents are shipping three, five, or ten times what they shipped a year ago, and the curve is bending up rather than flattening. Many of the founders and operators I talk to who are running their companies this way are not complaining about noise - they are trying to figure out how to feed more work to their agent fleets tomorrow than they did today, because every incremental unit of well-directed agent output is a compounding advantage over competitors who are still typing.

But Jevons' second lesson applies here too, and it is the one that separates teams that ride the curve from teams that get thrown off it: when supply explodes, selection becomes everything. More coal made engines more valuable, but it also made the discipline of choosing what to burn, what to power, and what to build with the output dramatically more important. Cheap energy without judgment is just waste, and the same logic applies to code.

For the teams running this well, selection is not a drowning problem - it is the new leverage point. The operator who can direct a fleet of agents toward the right problem, filter the outputs for what is actually valuable, and integrate the results into something coherent is doing the highest-leverage work in software right now. The value of a piece of work is no longer set by how much effort it took to produce, because effort has collapsed - it is set by how well someone pointed the agent fleet, chose from what came back, and integrated it into something that compounds even faster. Production is not where the work gets hard anymore. Where it is hard now is direction, selection, and coherence, and those are the exact muscles the best teams are building for as fast as they can.

From deterministic engineering to probabilistic engineering

We are rapidly moving from deterministic engineering to