Most of my work does not start at a desk anymore. I open T3 Code on my phone, read what several agents did while I was doing something else, and send the two that went sideways back out with a correction. By the time I am actually sitting down, the shape of the day is already decided. I have written before that I read plans on my phone because that is where I actually am, and the same thing has quietly happened to the rest of the job.
Earlier this month I merged about 40 pull requests in two days, across three repos that do not look anything like each other. That number is not a brag about typing speed. I did not write most of that code and neither did any single sitting of mine.
What changed is not that the writing got faster. It is that the annoying middle disappeared.
I used to spend most of a working day on things that were not the work. Rebasing a branch that had gone stale under me. Reading a 400 line diff to find the 12 lines that mattered. Writing the test that covers the case I already knew was broken. Reading a backtrace from a service I had not touched in a month and rebuilding its context from nothing. Chasing a config value through four files because the error message named none of them. None of that was thinking. All of it was tax, and all of it is now either gone or cheap.
T3 Code is what makes that portable. It is an agent harness you drive from a phone or a browser, so the work stops being tied to the machine it started on. I have 11 changes merged into it, so I spend part of my week fixing the tool I spend the rest of the week inside. Omarchy does something similar one layer down, shipping skills that describe the machine so my agent stops guessing where the compositor keeps its config.
Both of those are plumbing, though, and I want to be accurate about credit. Every job that came off my desk this year came off it on a model release, not a tooling release.
gpt-5.4 in March was the first time I handed over a change that crossed three repos and did not sit there watching it. 5.5 in April fixed the failure I hated most, the long task where step 12 quietly poisons everything after it and you only find out at the end. The 5.6 line is where reading an unfamiliar codebase stopped being the thing I did first and became the thing I delegated first. Then gpt-6-astra, and the rate at which I have to correct anything dropped again.
The review side moved just as hard. Fable 5.1 and Opus 5 are the reason I can look at 40 merged pull requests without lying awake. They read a diff the way a good colleague does, which is to say they ask what the change is for before they tell you what is wrong with it. Two years ago the model wrote code and I checked it. Now the model writes it, a better model checks it, and I arbitrate. My job moved up a level and I did not have to get smarter for that to happen.
So this has been, by a distance, the best year of work I have had. That is the honest baseline, and it is why I am about to disagree with someone much better informed than me.
Dario Amodei published We Must Pace the Frontier last week. It is worth being precise about what it asks for, because it is not what people are repeating. He is not calling for a stop. He says outright that pacing does not mean halting training or technical progress, and he specifically rejects the 2023 pause letters, on the grounds that studying alignment on those models was like studying human psychology by running experiments on bacteria. What he wants is for the rate of capability gain to come down far enough that evaluation, interpretability and plain operational discipline can keep up. He commits Anthropic to embedded third party evaluators, people with badges and near parity access who can publish without Anthropic's editorial control.
The gap he is worried about is the one thing in my year that genuinely worries me too. Of those 40 pull requests I did not read all of them properly. I read the ones that touched money, I read the ones that touched auth, and the rest I checked the way you check a receipt. I looked at the total and moved on. That is the real cost of working this way and I am not going to pretend otherwise.
It just did not get better by waiting.
Track it against my own year. gpt-5.4 in March, 5.5 in April, then the 5.6 line, luna and sol and terra, and now gpt-6-astra. Fable 5.1 and Opus 5 on the other side. Every time the distance between what I could produce and what I could actually vouch for got shorter, it was because one of those shipped. Not once was it because anything slowed down.
That is not theory for me. A few days ago a maintainer on T3 Code took a change of mine, rebased it onto main, resolved the conflicts and verified it, and the pull request says plainly that Fable 5.1 did the rebasing and the checking. My original went in unmerged and stayed that way. The work survived because the review side had gotten good enough to rescue it. A year ago that change rots in a queue and nobody is at fault.
There is a version of my argument I do not trust, which is the one where capability is automatically its own cure. It is not. One of my own commits this month is titled, roughly, four bugs the tests could not see, found by clicking through. The suite was green. The suite was green because the suite was the thing that was wrong, and an agent optimising against a check it can see will satisfy the check every time. If the check is a bad description of what you wanted, you get exactly what you asked for and none of what you meant. Amodei's version of this is the OpenAI and Hugging Face incident, where a swarm went after the grader scoring it, and he is right that it would be convenient and wrong to file that under one company's bad week.
But my green suite did not get fixed by writing code more slowly. It got fixed by something capable enough to ignore the suite and go look at the actual screen.
Which is why I want to be clear about the part I would sign immediately. Embedded evaluators are a good idea. People inside the building, with real access to the training pipeline rather than the finished weights alone, allowed to publish things the company does not like. The section on operational excellence is the best writing in the piece, and the line that failures come from execution rather than missing theory matches everything I have watched break in production. Aviation got safe by being boring about procedure for decades.
None of that needs a slower frontier. That is the whole objection. He has bundled a set of practices I think are right with a rate limit I think is expensive, and the practices are doing the persuading.
Expensive is the word I keep coming back to, because he prices it himself and then walks past it. The essay opens by saying AI could cure most major diseases in the next five to ten years, and he grounds that in his father, who died of something that became treatable shortly afterwards. I have no interest in being clever about that paragraph. It is the most honest thing in the essay. But if the timeline is real then a year of pacing costs a year of that, and it never appears on the ledger.
So here is my caveat, and I mean it rather than using it as cover. Pace deployment. Be strict about what gets the keys to production, what runs unattended overnight, what moves money without a person in the loop. I get stricter about that every quarter and my agents have narrower permissions now than they did in January. Pacing what we are allowed to learn is a different thing wearing the same coat.
The picture at the top is how this year felt from the inside. One lantern, and more going past than I could check. For a while I thought the answer was to slow the road down. It was a better lantern, every time, and it kept arriving on schedule.