Choosing a job, and writing a goal a machine can check

Autonomy is not a reward for a task being annoying. Score a candidate on five things: how often it happens, how clearly it can be specified, how reversible the actions are, what the damage is if it goes wrong, and how expensive it is to verify the result.

The pattern is straightforward once written down. Frequent, clear, reversible, low-damage, cheap to verify — automate it. Rare or ambiguous — leave it manual, because you'll spend more specifying it than doing it. Frequent but irreversible or expensive to check — that's the interesting middle, and the answer is usually assist: the workflow prepares, a human commits. Most valuable automation lives there rather than at either extreme.

Verification cost is the one people underweight. A workflow whose output takes as long to check as the task took to do has saved nothing — it has moved the work and added a layer. If you can't verify cheaply, that's a reason not to automate yet, not a detail to sort out later.

Then write the goal so something other than you can tell whether it was met. "Keep the dependencies up to date" is a direction. A goal names its inputs (which manifest, which registry), its constraints (patch and minor only, nothing with a failing build), its success checks (the suite passes, the lockfile is valid), and its stop condition (one PR per run, stop on the first failure).

Loading your workspace…