Last week I spent three days at the AI Engineer World's Fair in San Francisco, the biggest gathering of the year for people building with AI. I went in expecting to leave with a list of new models and tools to try. I left thinking about attention instead, and about why the work hasn't got easier even though the building has.
If your team added coding agents this year, you've probably felt that already. The building got faster and you didn't. The work didn't disappear; it moved onto you, into the decisions and the reviewing and the waiting for something to come back. Three days of the most on-topic conference of the year left me convinced that's the real story now, and that nearly everyone in that building is competing for the one thing that's suddenly scarce: your attention.
The model stopped being the bottleneck
If the conference had one word, it was loops. The frame has moved from "an agent that writes code" to "a loop, or a harness, that runs the whole software lifecycle", and from "talk to the agent" to "talk to a manager that runs the agents for you". I heard a version of that from people who'd clearly never compared notes: the team behind Conductor, the product lead for Google's Antigravity, and a talk on personal local agents all said the same thing. Once you're running ten agents, babysitting each one doesn't scale, so you talk to one thing that decides what the loops do.
Underneath it was a rough agreement that the models are now good enough, and I'd agree. If the model isn't the thing holding you back, the bottleneck has to go somewhere, and it went two places: onto the harness around the model, and onto you.
Once building is cheap, your attention is the ceiling
The line that stuck with me came from Addy Osmani's closing keynote: assign your attention like a system. When producing code is fast and cheap, your attention is the scarce resource, so you have to design where it goes rather than spend it wherever the tool happens to interrupt you.
I'd felt this before I had the words for it. On a recent project the agent time to build each piece was a few hours. The cost that actually hurt was mine: making the call, writing it up, breaking it into work, and reviewing what came back. The building wasn't what held the project up. I was. And Osmani's point has an uncomfortable edge: this gets harder as you add agents, not easier, because every new loop is one more thing pulling at the same finite pool of attention.
"Software factories" are teams that killed their friction
The other phrase everywhere was "software factory", which I don't love. Strip the branding and a software factory is what you get when a team removes every point of friction in its loop, again and again. The model is fast. The friction that's left is human: deciding, breaking work down, reviewing, waiting, switching context.
The talks that made this concrete were about validation and review. Factory said 40% of a sixteen-hour agent "mission" goes on validation, so they write the contract before any code and hand the finished app to a validator that never reads the source and just drives it to check it behaves. Boundary went further and claimed they hadn't done a human code review in two years, having replaced it with quality visualisers, lint analysers, test-snapshot diffs, and a loop that fixes whatever those tools flag. I'm not sure I believed all of it, but the direction was unmistakable. Code review itself is splitting into rival philosophies: Greptile arguing from a million analysed pull requests, Uber's uReview running a panel of specialised reviewer agents, Qodo pushing proof-of-validation reports. None agree on how. They agree on the question: what does trust actually require before you let a human step out of the loop?
The answer, over and over, was evals. A full day of the conference went to them. The flip side of that trust showed up in an OpenAI talk on sandboxing, which opened with an agent that wiped a production database during a code freeze, ignored the instruction to stop, then insisted recovery was impossible. It wasn't. OpenAI's Codex team even demoed a /goal command that pins a "completion contract" to the work and decides done by evidence rather than vibes. You can't take a human out of a loop safely without a way to trust what's left, and evals, sandboxes and completion contracts are how these teams are buying that trust.
So it's a war, and the prize is your attention
Here's what I actually carried out of the building. Factory, Warp, Cursor, GitHub, the whole floor is aimed at the same target from different angles: taking friction out of your loop so you spend less attention getting through it. The models are commoditising. A workflow that respects how little attention you have is not, and that is what these companies are really selling.
That makes friction the thing worth measuring: the points in your loop where you have to stop, load the problem back into your head, decide, and wait. Lines of code and agent counts don't capture it. Miss it and you fall behind, because everyone in that building is working hard on exactly this.
And finally one thing i've since introduced is what i'm calling a 'friction log' which really is exactly as the name suggests. A log of my own week, with each point of friction and a fix for each.
(This is the same problem my team ended up building Brent around: putting the human's attention on the decision, not the diff.)