What to hand a loop, and what to keep

A loop can run unattended when the task is cheap to get wrong and easy to call done. Anything else needs a person watching, and the judgement of whether the result is good enough stays with that person.

Hand over: low risk, clear stop

Addy Osmani fully delegates the lower-risk tasks with a clear stopping condition. His examples are writing docs and checking test coverage. For an analyst, that means refreshing a recurring report or flagging rows that break a known rule.

A written policy can be the stop rule. His contribution guideline says the project does not accept translations, so a loop can close those pull requests by itself, and the human review queue shrinks. A data rule such as "no backfills before 2024" can do the same job.

Watch closely: thin specs and sensitive systems

Complex problems, tasks where the spec may be incomplete, and anything touching system access, authentication, security or finance get a person watching. Finance is an analyst's daily ground, so many of the useful loops land here and run supervised.

Bad fits: taste

"Keep going until the design is good" has no end state, so subjective design and open creative exploration stay out of loops. An agent can also be confident on one axis and wrong on another. In Osmani's case, a performance baseline was measured on desktop when mobile was what mattered, and a separate checker caught it (Loop engineering covers that split).

Keep the judgement

Osmani nearly pushed a batch of agent-made pull requests that closed feature gaps against competitors. Each one finished its task. On a closer read, they added a lot of complexity for little gain, so they did not ship. You delegate the task; the standard it is checked against stays yours.

The bottom line

Hand a loop work that is cheap to get wrong and easy to call done, watch it where the spec is thin or money moves, and read what it ships against your own judgement.

Source: Addy Osmani, "Practical Loop Engineering" (2026).