A moderate CVE dropped on a Wednesday. By Friday I had patches across three repositories because the dependency had been sitting in a queue nobody touched for two months. The line that needed changing was a single character per file. The hours I lost finding and writing it were not. That weekend I asked the only question that mattered: what fraction of last week’s maintenance time was actually interesting, and what fraction was routine work I was doing by hand because I had not spent an afternoon wiring up a script?
When I tallied it honestly, the answer was about one in five. Most of the rest was opening a page, reading a small paragraph, clicking one of two buttons, and moving on. The interesting one in five stays with me. The other four hours evaporated into a kind of attention tax I had been writing off as “just how maintenance works.” It is not. Most of it is mechanical, and most of it can be lifted into a scheduled prompt that runs while you sleep.
This is what I learned running a daily automated triage on a personal repository for two months. The interesting part is not the tool. The interesting part is the math, because the math tells you whether the automation actually bought your morning back or just moved the busywork.
The arithmetic that decides whether this is worth doing
Every recurring maintenance chore has a hidden cost that is easy to underestimate. You do the chore. You read the changelog. You check CI. You write a comment or click merge. You move on. Five actions, ninety seconds each, seven and a half minutes per dependency. Multiply that by the dozen repositories a small team or hobbyist maintains and you spend an hour a day on work that has no original thought in it.
That hour does not just cost time. It costs context. Every decision, no matter how small, pulls you out of the focused work you were doing. By the time you come back from the merge queue, the design problem you were halfway through has reset. The cost of a small interruption compounds through the rest of the day.
The narrow case for automation is simple. If a chore happens regularly, takes a fixed amount of time, and produces output that follows a pattern, that chore is a candidate. The broader question is which candidates pay off. A chore that takes thirty minutes once a year is not worth touching. A chore that takes seven minutes five days a week, every week, is the one to fix.
Two numbers help separate the candidates from the noise:
- Frequency: how often the chore happens in a normal week.
- Decision density: how many of the steps require you to actually think.
If frequency is high and decision density is low, you have a candidate. A scheduled prompt can absorb the routine steps so that you only handle the steps that genuinely need your brain. Everything else gets a one-line summary.
Where a daily automated triage pays its rent
A daily automated dependency review on a single repository is the test case I keep coming back to. It pays rent because the chore is bounded. The script reads the same list each morning, groups items by risk class, checks CI status, and writes a tight summary. You act on the summary, not on the list.
What this looks like in practice on a small project:
- Patch updates flagged as “merge after CI green, no manual review.”
- Minor updates flagged as “skim the changelog section, then merge.”
- Major version upgrades flagged as “park for a focused afternoon block.”
- Any pending security advisory flagged separately, regardless of update size.
The morning shifts from forty open tabs to one four-line summary. That is the real win. Attention is the bottleneck, not time. Reducing forty decisions to four keeps you in the work you actually came to the desk to do.
Where it does not pay rent
The same arithmetic shuts the door on most other chores. Bug triage is too varied. Customer support responses require judgement per case. Code review needs the original author or a domain owner. Those tasks have high decision density and they are exactly where your attention should land. A scheduled prompt summarizing them produces summaries you cannot act on, which costs more than it saves.
The rule I use is simple. If I can describe the task as “do X for each item in this list, where X has two outcomes”, the task is automatable. If “X” has four outcomes, or the items require outside context, it is not. Maintenance chores tend to be the first kind. Design tasks tend to be the second. The line between them is sharper than people expect.
I also try not to automate chores that take less than five minutes total in a week. The setup time, the prompt-tuning time, and the prompt-rewriting time the first month are not free. A chore that takes two minutes a week is cheaper to keep doing by hand than to wire up and tune. A chore that takes forty minutes a week is not.
Trade-offs
There is no setup that costs nothing, and I want to be honest about the lines I had to draw.
- The automation needs a permission grant. Whatever tool you use will require read access to the artifacts it summarizes. Closed-source repos and private customer data change the calculus; for those, local execution modes exist but cost you convenience.
- Tuning happens monthly, not once. The first version of a prompt produces vague output. That is normal. Plan to spend fifteen minutes once a month editing the prompt as your priorities shift, or the report goes stale.
- The summary is not the work. Acting on a four-line summary takes two minutes. Acting on forty pull requests takes forty minutes. The savings come from doing the action, not from the summary existing. If you read the report and then open the list anyway, the workflow has failed.
- Coverage has limits. Anything outside the tool’s view stays outside the report. A scheduled digest knows about the dependencies the tool tracks, not the ones you have vendored manually or the security advisories posted on a list you did not subscribe to.
If any of those are dealbreakers, do not use this. If they are not, you have just recovered a meaningful slice of your morning. That hour is the difference between a week that lets you ship something new and a week that is just maintenance.
What I would tell past me
If I could send a message back to the version of me that wrote the first triage script by hand, I would say three things.
- Measure the chore before you automate it. Use a stopwatch for one week. Most chores are bigger than they feel. The ones that are not are the ones to leave alone.
- Keep the summary short. A four-line report is read. A forty-line report is skimmed. A forty-line report that is skimmed is the same as no report at all.
- Do not try to automate everything. Some work is high-decision by nature. Protecting your attention on the hard parts is what lets the easy parts stay easy.
How to start without overcommitting
Pick one repository where you have been avoiding the queue. Run one cycle manually to see what the report looks like. If the format is useful, turn on the schedule. Ignore the report for a week. When Monday morning arrives, see whether you read it and act on it, or whether you open the underlying list anyway. If you acted on the report, the workflow fits your day. If you opened the list, the report was not the bottleneck and a different workflow would.
Run the experiment on a Friday afternoon. The setup is short. The behavior change is the actual work. Give yourself a week before you decide whether the morning routine has changed, and be ready to rewrite the prompt if the output is not what you wanted. After that, the morning that opens with a four-line summary instead of a wall of red dots is the morning the rest of the day gets easier.