Making Human Attention the Priority

In my software factory series, raising expectations leads to a question: how much human attention does a useful result take? Explaining, steering, reviewing, correcting, and verifying all count.

An agent can work for twenty minutes while I do something else. It can also finish a task and leave me with twenty minutes of figuring out what happened. Those have very different costs. As more work moves through the system, the routines around it deserve another look: the interruptions, repeated explanations, awkward handoffs, and little workarounds I’ve got used to.

I can have a feeling about where that effort goes. But I can also collect timings, quality signals, and feedback while I’m working, then use an agent to help me analyze them. That gives me something concrete to improve. Code review is where I’ve taken this furthest in my own work.

My iOS code-review workflow

On GitHub, I review within GitHub’s navigation and the habits it supports. For an iOS change, I often want to read the code in Xcode, where jumping through Swift definitions and SDK code feels much more natural. So I switch.

I also want to choose which files deserve my attention first. Neither GitHub nor Xcode makes that easy in the way I want to review. With my own view, I can prioritize the key files and automatically hide the ones I know I don’t need to inspect now. A change touching 50 files can become a review where I go through four or five, with the rest still available if I need them.

Then I find something worth commenting on. I want the comment attached to that exact line and sent back to the agent. In my workflow, that means going back to the review, finding the code again, and adding the comment there. A collective message in the agent’s chat might be good enough. But how much time do I spend explaining which code I mean, and how often does the agent need clarification?

There are also screen snapshots and app screenshots to compare. If the review page won’t render an image stored through Git LFS, I need another way to inspect it. That means finding the right files in the right worktree, opening them, and getting back to the code I was reviewing.

And I still want to run the app. I need the simulator for this worktree, with this change built, ideally already on the screen I want to click through. Opening Xcode and launching the app gets me part of the way. Finding the relevant screen is more work. A GitHub review page doesn’t give me that whole experience either.

None of these steps looks particularly dramatic on its own. Together, they can eat a good part of a review. Some are obvious annoyances; others are habits I’ve stopped questioning.

What I can measure right now

I can break that review into the things I actually do and collect a few useful observations:

Some timings can come directly from tool events. Others need an explicit start and stop or a quick estimate. A ten-minute unattended build and ten minutes spent getting the simulator ready cost me different amounts of attention.

Quality needs a place in the same record. I can note which problems I caught in the diff, snapshots, or simulator; whether the correction resolved them; and which related bugs or regressions I discovered after accepting the change. Linking those findings to the review lets me check whether faster reviews are leaving more repair work behind. Comparing similar changes over the same follow-up period is more useful than comparing two arbitrary review durations.

Feedback while I still remember

Timings tell me where the time went. My feedback helps explain why. If I wait until Friday to list everything that could have gone better, I’ll forget most of the small things I worked around.

During the review, a note like “I had to find this line again to leave a comment” is already useful. So is “the screenshot was from a different revision” or “I launched the app but had to navigate through onboarding again.” I can attach it to the review or the step where it happened.

Agents make it practical to fit that feedback into how I work. I can type it, dictate it, or add a small feedback step after using a tool. The agent can save it with the task, revision, and current activity. Automated timings and these short notes give me something much richer than a weekly recollection that reviewing was annoying.

What changed in my own reviews

I built local-review, now part of Pitcrew, to bring file prioritization and filtering, the diff, comments, visual comparisons, and access to the relevant worktree and app into one workflow. For reviews that used to take me twenty or thirty minutes, the human attention cost can now be a few minutes.

Of course, not every change needs that kind of review. Sometimes reading the diff is enough. Sometimes agreeing on the approach gives me enough confidence in what the agent will do. But for changes where I need to inspect the code, compare the UI, and click through the app, saving those minutes matters every time I do it.

Measurements also help me choose what to improve next. Repeatedly finding the same code to attach a comment might turn out to cost very little. Preparing the app might be where most of the effort goes. I want enough evidence to choose between them, including whether the change makes the review better.

Collect the data, man.

If I want to test a hypothesis about where my time goes, I need records of my own work. Timings, outcomes, and short notes let me compare similar tasks, check whether an improvement helped, and see what still needs attention.

Vibe Coding Your Productivity Tools Is Fine describes how I turn those observations into tools I can try and improve during real work.