Three years ago, if I wanted a day's worth of code, I had to spend a day writing it. Now I can ask a model and get roughly the same amount in minutes, which still feels absurd even though I do it every day. I love this way of building software. The catch is that the model made code cheap without making my attention any less finite, so by lunch I can have a pile of changes that would once have represented a week of careful work and exactly the same pair of eyes with which to understand them.
Breakage is rude. It fails a test, pages somebody, or puts a customer in your inbox, and eventually a person has to stop what they are doing. Performance is much more polite. A hot path gets ten percent slower and the test suite stays green; another harmless change adds five percent; data grows; six months later everybody agrees the system is slow, but no single change ever demanded a meeting. When much more code competes for the same attention, this quiet failure mode is the one I expect to lose first.
Keeping a system fast was never a task you finished. The performance envelope moves when a dependency changes, when an agent builds today's feature on top of the one it wrote yesterday, and even when the source stands still: a perfectly reasonable query for a small table can become a disaster after the table grows by ten times. Somebody has to notice the change, form a suspicion, find the right experiment, run it fairly, and then distrust the exciting result long enough to learn whether it is real. That loop lasts as long as the software does.
The widening envelope
I have never worked on a team that lacked performance ideas. We knew which paths felt wrong, had profiler screenshots sitting in tabs, and could usually name three experiments worth trying. What we lacked was the empty afternoon after the release, the incident, and the customer request had taken their share. At human development speed a strong team could almost keep up by being disciplined and occasionally heroic. Once agents can produce changes faster than the team can inspect them, the old arrangement stops being merely stretched and starts being numerically impossible: holding the same envelope asks for more attention than the team has.
The usual answer is performance testing in CI, and it is a good answer as far as it goes. If a benchmark runs on every relevant commit, on comparable machines, with enough samples to separate a change from runner noise, it can protect the path it measures. Many useful suites are too slow or too noisy to pay that price on every commit, so they run before a release, during an investigation, or whenever somebody remembers. The benchmark code remains in the repository and looks reassuring, while its last result describes an old commit under old conditions. This distinction gets lost all the time: the benchmark is current source code; the evidence it produced is stale.
Even a perfectly run suite only asks the questions somebody already thought to encode. It will not wander into an unmeasured path, decide that a suspicious allocation deserves an experiment, write the missing benchmark, or come back next month because the workload changed. Perfloop works in that larger loop. It looks for the missing question, builds the experiment, measures the original and candidate under the same rules, and can repeat the attack later so the answer belongs to this code rather than a commit everybody has forgotten.
So far this is only the supply side of the problem: machines write more code. The same machines are becoming users of software, and one agent doing useful work for one person can send requests at a pace that person never could. GitHub looks like an early canary because coding agents pull on it all day, and its public status history now records an incident on nearly every working day. You cannot solve this by blocking the traffic, because it comes from customers doing real work; the service has to carry it even if every capacity assumption was made for humans clicking through a UI. Banks and insurers will meet the same problem when mass-market agents reach their systems. We are increasing the code a team must inspect and the load its software must serve at the same time. Hiring alone cannot close both gaps, and unconstrained generation only widens the first.
Teams will not arrive there together. Some are already agent-native and ship at machine pace; some of the best engineering organizations I know still write every line by hand, keep change deliberately slow, and are rightly proud of the control that buys them. That is another form of superhuman attention, except it is paid at full human cost and works best while scope stays small. Most teams will move one tool and one hire at a time, while software slowly invents the industrial quality control that earlier production revolutions had to invent for themselves. My bet is that machine pace reaches them before the discipline does.
The cost of another agent
At this point another coding agent looks like the obvious answer. I use them every day, and for months I built Perfloop by steering them through performance work myself: choose the target, set constraints, demand a benchmark, reject the suspiciously large win, rerun it, notice that the agent changed the workload, start again. We produced real improvements this way because I supplied the harness in my head. It was also a ridiculous way to save attention. I had replaced writing the patch with operating a small performance lab through a chat window.
Let the agent run free and the bill moves to the reviewer, who receives a plausible diff and must work out whether behavior changed, whether the workload was fair, and whether the number survives a clean baseline. Steer it closely and the engineer pays the same bill one prompt at a time. Open-source maintainers now see the first version piling up in their queues; anybody who has spent an afternoon disproving a confident machine patch has felt the second. Neither arrangement removes the proving work. It only chooses the person who gets stuck with it.
Perfloop turns the lab into the product. A case asks one question about one place in the code, a candidate gives one complete proposed answer, and then the project's checks run. The agent that wrote the change does not grade it; a separate verifier looks for defects before any performance result can anchor the review. Only a candidate with a clean Verification reaches the official comparison, where the original and candidate are measured under the same stored rules in the same environment. Most candidates die somewhere in this process. This is the healthy outcome. I have proved my own performance assumptions wrong too many times to trust a machine's merely because it rendered the benchmark table with confidence.
There is no theorem at the end. A speedup is a claim about real hardware under a realistic workload, settled with samples and controls, then checked again when the code or workload moves. Perfloop can repeat the experiment later and, when production telemetry is connected, check the result once more after the merge. Fair measurement costs real compute. That is not free, and on some systems it is the limiting cost. The point is to spend both resources deliberately: compute on repeatable proof, expert attention on the judgment the machine cannot make.
Proof before review
A candidate that survives reaches the reviewer with the expensive questions already made concrete. The project checks show whether behavior held; the original and candidate measurements show what moved; the stored command and workload let somebody run it again. A doubtful number should still be rerun, of course, but the reviewer is no longer asked to invent the entire experiment while reading an unfamiliar diff. Once the evidence agrees, the remaining question is the one only the project can answer: does this change belong here?
We have one public example in ClickHouse's sorting path. Perfloop noticed that constant sorting keys might be able to return early, tried the change, ran the project check, passed an independent Verification, and then ran the performance comparison before opening the pull request. ClickHouse's maintainers did not have to take our word for the result; they could inspect the change and its proof, decide whether it belonged in their project, and they merged it. The case still contains the question, code, evidence, and timeline, which is more useful than another triumphant claim that an agent made something faster.
This division gives the sender obligations, not permission to spray pull requests. Perfloop may open them, but I approve each one, disclose how it was made, and pay for the failed candidates before they reach a maintainer. I also learned how little this entitles us to when one evidence-backed submission was closed in four minutes. Fair enough. A maintainer's no is final in their project, and good proof does not create a duty to read it. It only means we did not save our time by taking theirs.
When a queue fills with machine patches, filtering by author is a rational defense. The sender owes disclosure before the diff, evidence the maintainer can rerun, and a human who stands behind the submission; even then, a good change has a chance only if checking it is cheap for the receiver. The receiver-side machine that can do this filtering well still needs to be built. Until it exists, we owe the proof even when nobody reads it.
Where else attention is missing
Research has a version of the same backlog. Useful performance techniques appear every year, and moving one from a paper into production requires a person who reads it, recognizes where it might fit, and is willing to run the cheap experiment that could make the whole idea collapse in an hour. A few teams can spare those people some of the time; no team can keep up with a field that grows every year without giving up something else. Given a goal, Perfloop can read new work, narrow it against the actual system, try the cheapest useful test first, and send only the survivors through the same hostile harness. This version of the loop starts with the literature instead of a regression, but it ends at the same boundary: the machine can produce the evidence; a person must decide whether it matters.
What remains human
That last decision is not a consolation prize. It is the part I care about. I have spent Christmas breaks following a profile into some ridiculous corner of a system and emerging hours later with a number I wanted to show everybody. The joy was never typing the benchmark command or waiting for the fifth clean run. It was the hunch, the chase, and the moment the system finally gave up its secret.
Perfloop should not automate that away. It should give the hunch more reach. The machine can write the benchmark, rerun the baseline, throw out the miraculous result, and return when the workload changes. It can be patient where people cannot afford to be. With production telemetry, it can also tell which paths are hot, what they cost, and where a win would matter most. It should. The boundary is not whether the machine can rank the work. The boundary is who sets the goal and who accepts the tradeoff. Perfloop can tell us that this win matters more than that one; it cannot decide what the system is for, whether ten clever lines are worth maintaining, or whether the change belongs. That judgment stays with us.
Three years ago, a day of code cost me a day. Now it costs minutes, and by lunch I can have a week's worth of changes waiting for the same pair of eyes. I do not want another machine that makes that pile taller. I want one that stays with the quiet problem, the one that will never page anybody, until the win survives or the idea dies. Let the machine spend the thousand hours. Give the engineer back the afternoon.