Superhuman attention.

In the last three years a model learned to write in minutes what took a person a day, and the pace of change in codebases rose to match. Attention did not get cheaper. An engineer's focused hour is the same hour it was five years ago, and everything that got cheap is competing for it.

Slowness never demands attention the way breakage does. A failing test or an outage gets dealt with because it interrupts someone. A hot path that quietly gets ten percent slower interrupts nobody, and the loss builds up through changes that each looked harmless. When attention is scarce, the work that never interrupts gets dropped.

And performance is an envelope you hold for as long as the system lives. Every change presses on it: the dependency upgrade that looked free, the feature an agent wrote yesterday on top of one it wrote last week. Code standing still presses on it too, as data grows under a query that was written when the table was one tenth the size. A system is fast because someone keeps it fast, and keeping it fast is sustained attention: watching what changed, suspecting the right places, measuring, and checking that an improvement is real before you trust it.

When code changed at human speed, a strong team could almost hold the envelope, and the backlog was the almost: every team I have worked on had suspected slow paths that nobody ever got to, work that needed attention that was never there. Where agents write the code, the rate of change is superhuman, and holding the envelope under that pressure needs superhuman attention too.

The same shift is happening to the load. Software's users are becoming machines: an agent doing real work for one person fires off requests at a pace no person ever did. The canary is GitHub. It is the service coding agents pull on all day, and its public status history now logs an incident nearly every working day. That traffic is customers using the product, at machine pace, and the only answer to it is serving it, on systems that were tuned for human pace. Mass-market agents carry the same load to the banks and the insurers of the world next. So the envelope is being squeezed from both ends: code changing faster than a team can watch, and traffic growing past what the code was tuned for.

None of this arrives evenly. The spread across teams is enormous, and people are still arguing about what good practice even looks like: some teams are agent-native today and ship at machine pace, and some of the best engineering organizations in the world hand-write every line and hold change to a deliberate crawl, proud of the control, and they should be. That control is superhuman attention too, paid at full human price, and it works because those teams keep their scope ruthlessly small. It does not scale past the teams willing to pay it.

For everyone else the pace arrives unevenly, one tool and one hire at a time. It is a wild west: every earlier production revolution eventually built industrial-scale quality control, and software is only building its own now. The bet I am making is that the pace reaches most teams long before the discipline does. Wherever a team sits on that spread, the thing it is managing is attention.

The reflex answer is a coding agent. I use them daily, and my company's product is built to work with them, so read this knowing where I stand: a coding agent does not solve the attention problem, because a coding agent runs on your attention. Someone prompts it and reviews what it produces. Give one total freedom on a performance task and it comes back with a plausible diff and nothing you can check. You still don't know whether behavior changed or whether the speedup is real against a fair baseline, and answering that is the expensive part of performance work. The freestyle agent leaves those questions to whoever reviews it, and the machine-generated patches piling up unproven in open source queues right now are what that looks like at scale.

A good engineer can steer one to a real win instead. I built Perfloop itself that way, steering coding agents through every session for months, and it works because the engineer supplies the harness by hand: choosing the constraints, demanding the measurement, rerunning anything that looks too good. It also consumes exactly what this essay says it consumes. The cost of a change lands on someone every time: run the agent free and it lands on the reviewer, steer it and it lands on you. The cost goes away only when the proving runs with no person inside it.

A harness built for performance engineering changes the accounting. A change touches one place in the code and states one hypothesis, and behavior has to stay unchanged. Before a person ever sees it, it has to survive the harness. The project's own checks come first, then a speedup measured against the unchanged code under the same conditions, and the result stands only while disproving it keeps failing.

Proof here is the empirical kind, closer to a lab than to mathematics: a speedup is a claim about real hardware under a realistic workload, and it is settled by sampling, under controlled conditions, again as the system changes. Where production telemetry is connected, the win is checked once more in production, after the merge. That is what makes proving expensive, and it is the kind of expensive that compute can carry.

Most candidates die in there. Whatever wrote the change gets no say in the verdict, and that rule comes from experience: I have proven my own performance assumptions wrong too many times to trust anyone's without a measurement, including a machine's.

What reaches the reviewer is a claim with its evidence attached, and that changes what reviewing is. The questions that eat the afternoon, whether behavior changed and whether the speedup is real against a fair baseline, arrive already answered, and the reviewer checks the answers instead of producing them. And the answers do not ask to be believed: the checks are the project's own, and the measurement arrives with what it takes to run it again. A doubted number gets rerun; when enough reruns have agreed, the doubting gets rare. Trust builds the same way the proof does, empirically. What is left is the judgment call, whether the change belongs, and that takes minutes. That difference is the economics of holding the envelope: the more a change proves about itself, the less attention it takes from a person.

The envelope forces a division of labor: people keep the judgment, and compute does the verifying. The machine keeps watch. It keeps a model of the system current as the code moves, hunts the places where known performance patterns apply, builds and runs the experiments, and interrupts a person only for results that survived the harness. The person decides whether the change belongs, and where to point the machine's attention next.

This thesis applies to me first. Perfloop's systems open performance pull requests in open source, disclosed as such and approved by me, and I have been on the receiving end of the four-minute close. A sender owes disclosure before anyone reads a diff, and evidence the reader can rerun rather than take on faith. Everything we send out has already survived our own harness, so most of what a generator produces dies at our expense and never reaches a maintainer's queue. A human stands behind every submission, and the maintainer's no is final in their own house. A sender working at machine scale owes proof at machine scale. Producing a change got cheap for me and reviewing one stayed expensive for the maintainer, so an unproven submission spends a resource they cannot buy more of to spare one I can. The proof has to come from where the leverage is: the machine makes it and attaches it to every submission, and checking it requires no trust in me.

And none of it guarantees a hearing. My four-minute close came with the evidence attached: when a queue fills with machine patches, filtering by who wrote it is a rational defense, and substance wins only when checking substance is cheap for the receiver too. That is a machine someone still has to build. The obligations hold either way: proof is owed whether or not it gets read.

The gap between research and production has always been an attention gap. Performance research keeps producing techniques that would pay for themselves in deployed systems, and most never make the trip: crossing takes someone who reads the new work and sees what applies to their system, then runs the cheap experiment that could prove it wrong. Some teams have those hours; even they cannot sift all of it, because the field publishes faster every year, and a fixed budget of attention loses to a stream that keeps growing. The machine can hold this watch too: give it a goal and it reads what is new, narrows it to what fits your system, tries the cheapest test first, and sends what survives into the same harness as everything else.

Many engineers will not like where this leaves them. The grind moves to the machine: finding the candidates, and proving the wins over and over as the code changes. The feel keeps its job: a hunch about where the win hides becomes a hypothesis you hand the machine, and the proving happens without you carrying it. The grind is what leaves, and if you loved even the grind, that is a loss. For me it is; I have spent Christmas breaks hunting these wins for the joy of it. But look at the backlog: the grind was never staffed. It sat in the queue, in mature and well-run systems as much as anywhere.

What stays human is the part that was always the point: intuition about how the system should behave, and judgment about what a measured result means for where to point the machine next. Attention spent there compounds. The grind just burns it.

The envelope is not going to relax. Change gets faster from here, and the gap between what a fast system needs and what a team can give keeps widening; hiring alone does not close it, and unconstrained generation makes it worse. What closes it is the machine this essay has been describing: one that holds the envelope the way an engineer would with a thousand hours for every one, patiently and suspiciously, trusting only what keeps surviving attempts to prove it wrong. That is what superhuman attention means. What comes out the other end is software that stays fast, and people spending the hours no one can buy more of on the work only a person can do.