The useful unit of AI work is an iteration
An agent finishing a change creates a new piece of work for me: deciding whether I want to keep it.
That sounds like a minor detail until several agents finish at once. Now there are multiple diffs, different ways to launch the relevant behavior, and several explanations of why the work is complete. If I have to reconstruct every experiment myself, faster implementation has mostly moved the queue onto my desk.
Looking back at May, the useful investment was making the results easier to reach. The repository gained more testing tools, direct screen-preview routes, and reference captures. One May change added fourteen launcher cards for opening specific screens. That is not a dramatic feature announcement. It is exactly the sort of thing that makes the next afternoon more productive.
Count the whole loop
For a change to be useful, I need to select a problem, communicate it, get an implementation, reach the affected state, inspect the result, and decide what happens next. Code generation occupies one part of that sequence.
When I think about AI productivity, I try to keep the entire sequence in view. An implementation that takes less time but requires more investigation afterward may be a poor trade. A modest tool improvement that makes every subsequent inspection easier can be a very good one.
This is why I keep returning to the iteration as the useful unit of work. It includes judgment. It has an observable result. It gives me an opportunity to change direction before the cost grows.
Remove setup from the conversation
A direct route to a screen gives an agent and me a common reference. We do not need to describe a navigation sequence from memory. We can name the state, set the relevant inputs, and return to it.
A capture gives us something stable to discuss. Instead of saying that the new version seems crowded, I can point to the area where competing elements obscure the action. A repeatable test can distinguish a failure of the implementation from a difference in setup.
The goal is to keep the conversation about the product. Every minute spent reconstructing which build or configuration somebody used is a minute that cannot improve the result.
There is a limit. I do not need a new tool for every question. If I will inspect a behavior once, manual setup may be fine. When the same setup returns repeatedly, it starts to deserve a stable interface.
Make the next decision smaller
The other advantage of a cheap loop is that I can ask for less at a time. I can evaluate one change to timing or presentation before requesting a larger set of improvements.
That helps the agent too. Feedback about one variable is easier to act on than feedback about a bundle of changes whose effects interact. It also helps me recognize when my initial idea was wrong. I have less invested in defending a large implementation.
May’s tooling work did not give me a measured productivity multiplier. It gave me more places where I could exercise judgment quickly. That is a different claim, and a more useful one.
Before I ask an agent to move faster, I now ask a simpler question: how quickly will I be able to tell whether I want what it produces?