A few weeks ago Mitchell Hashimoto posted his daily schedule.
I remember two lines:
600 review nightly agents, start new
and at the other end of the day,
2000 hang with wife, start new nightly agents
He’d set himself “always have an agent running” as a goal in early 2026 (and admitted he’d mostly failed at it initially). By August though — at least two agents running constantly, many of them through the night.
So I thought I’d like to test this shape of a workday. I felt intuitively that my loops were too short. And I am fortunate enough to spend some time with folks who keep agents working on their own for hours, on useful work.
For about fourteen days now I’ve been running my own version: sessions of eight to sixteen hours, agents working without a pause, one overnight run clearing thirty-something tasks by breakfast. What follows is a field note.
Four things I’m fairly sure of, and one I’m stuck on.
The afternoon is the job
Fourteen days went into drawing graphs: which tasks depend on which, what can run side by side, where the results have to meet. The models mostly wrote the code. I mostly wrote the graph (although it is really a conversation). If prompt engineering was ever a discipline, it’s dead; the craft moved up a level, from the words in one prompt to the edges between thirty of them.
People have started calling this graph engineering. You can watch Andrew Ng — a guy who likely trained half the world’s ML engineers before LLMs were even a thing — describe it in his two-hour course. In short: a node is one unit of work, an edge is a real dependency between them. Boris Cherny of Claude Code reportedly said: “You’re not supposed to write code anymore. You’re supposed to build a graph that writes itself.” And I’m starting to think there is some substance to it.
So my day has a shape. Two to three hours of graph in the afternoon, which is really a conversation about trade-offs and scope. One to two hours of review in the morning. The machines in between. In three such days I get through what would have taken several weeks at the start of 2025, with the caveat that some of it I would never have done at all (thus it is an infinite ROI, or at least “hire someone else” territory).
Worth noting: nobody in this setup is really watching twenty terminals at once at this stage. The afternoon is one long conversation, with occasional forks, about one big chunk of work, the night runs it, the morning reads it. People who try agents and report exhaustion are usually describing something else: babysitting several of them live, switching context every few minutes. My intuition now is this: if many parallel flows leave you exhausted, you may still be doing prompt engineering. Planning the graph up front removes the switching, and the switching is most of what people mean by tired.
This is mostly design work now (and it is hard!).
Multi-agent moat was wrong
Three or four months ago I’d have bet against all of this, and for a specific reason. I assumed the frontier labs would each build a harness around their own agent, and that the hard gap, the one a product could live in, would be between agents: one lab’s model handing work to another’s, adversarial review across vendors, worktrees and changesets managed between them. In short, the classic multi-cloud play from the cloud-native era.
That gap closed without anyone announcing it (or I didn’t care to notice). Claude Code manages Codex: hands it a changeset, sets up a worktree for review, picks the model tier, exchanges messages, reads the verdict back. Codex will talk to Gemini. No framework sits in the middle, and it works surprisingly well. The models’ raw coding ability, as far as I can tell, has barely moved in that time (irrespective of what AI pundits claim). What moved is their ability to coordinate, but oh boy — is it a hell of a difference!
The harness moat is eroding too
Once they coordinate, something odd happens to the harness: agents running without one start producing better work than agents running inside a custom one. Robert Martin — Uncle Bob — spent several weeks building a harness: gates, tests, tools, protocols, all constraining the agents to work his way. When he came up for air the agents had improved enough that “the need for my harness was obviated. Indeed, the need for any but the most liberal of harnesses may be obviated.”
The next morning, in a bathrobe rant, he went a step further: with the harness off, the work came out better than it had inside it. The unharnessed agent beat the harnessed one.
This is truly surprising.
But it matches my results closely. What I run instead now is really dull. A few skills tuned to how I actually work, a handful rather than a hundred. A few models, so one can review another (this is key). Cheap remote machines, because fourteen hours is a long time to keep a laptop lid open (and besides if you truly want to have at least some agents working at any given point in time — this is really a must).
But there is more. Take mutation testing. Three months ago I spent real time working out how to poke holes in agent-written tests with deterministic mutation testing: a harness step, wired by hand, because the agents would happily write tests that passed and proved nothing. Today they run mutation testing on their own work unprompted. For free (kind of).
Wow.
Review becomes shape
Adversarial review by a second frontier model catches real things. One round finds most of them, a second round a few more, and my ceiling of four exists for my own comfort; typically past two, the reviewers start inventing objections. That said, I have had runs where the worst defects surfaced in the third or fourth round, so the ceiling is still an experiment.
The morning has changed. Two machines have already argued over the lines, so I read the shape of what came back: which files were created and where; what each file is responsible for, so the division of labour is legible; which tests exist, at the level of “what does this protect”; which parts of the system were touched, and whether those are the parts that got tested.
Review always had a price, paid during authorship. Human authors used to arrive at review already understanding the code they’d written. With agents, that understanding no longer comes bundled with the implementation. Someone has to acquire it afterwards. What you can do is stop reviewing lines and start reviewing structure, which is where intent and taste still live and where the diff says nothing (or at least is too fine-grained, and it’s easy to miss the forest for the trees).
My bet: review gets reinvented within a year. It has to; the old ceremony is mostly inefficient and partly useless.
The part I’m stuck on
It’s slow. The coding is quick; adversarial review and mutation testing eat the hours, and a graph only lets you parallelise the edges that are genuinely independent. A lot of it still runs one after the other. At three or four parallel lanes on a subscription you sometimes hit the API throttle. And the industry numbers point the other way for now: Faros AI telemetry across ten thousand developers, reported in a May 2026 paper, found pull requests up 98% and review time up 91% with delivery flat, which is what happens when the review moves nowhere. On metered pricing, working the way I work now, I’d burn eight to ten thousand dollars a month (in API-based pricing costs; realistically I use a bunch of subscriptions and rotate them so it is effectively way cheaper). Which still buys, overnight, what two or three weeks of developer time cost in 2024 money.
Tokens will get cheaper; they always have (at least for the last few years). And if capitalism is good at anything, it is driving the cost of technology down. The accounting problem is still here, though. Cost per unit of work has collapsed, visible spend per unit of time has spiked, and the visible number is the one that lands on a credit-card statement in real time.
I discussed this phenomenon with my friend recently. Either the return is real and hard to attribute, and the visible cost wins the meeting. Or maybe the development bottleneck was hiding a harder truth: some of the lower-priority work never had a convincing business case. We could leave it in the backlog without confronting that. Now each task comes with a visible token bill, and that makes it painfully obvious.
Either way, the work moved. From writing code to drawing the graph, and from reading code to reading its shape. A year from now, reading the diff line by line will feel like reading the assembly your compiler emitted: possible, occasionally necessary, and no longer where the judgment lives.
Want to make a bet?