The merge used to be the finish line. You opened a pull request, someone reviewed it, it went in, and the change was done. Coding agents have quietly moved that line. When an agent picks up a Linear issue, writes the code, and opens a merge request while you are in a meeting, the merge is no longer the end of the work — it is the start of everything the merge touches.
The merge stopped being the finish line
A merge is never just a merge. Every change leans on the systems around it: the issue that should now be closed, the docs that describe something slightly untrue as of this morning, the CI that is a little redder than yesterday, the release notes nobody has written, the support conversation still waiting on a fix that actually shipped hours ago.
When one engineer shipped a handful of changes a week, that follow-up work fit in the cracks. You closed the issue while you had the pull request open; you remembered the doc because you had just touched the code. When an agent — or a fleet of them — ships many changes a day, the cracks overflow. The code is not the bottleneck anymore. Everything downstream of the code is.
The maintenance model didn't change
Development got faster. Maintenance did not. The tools we use to keep a project coherent are still mostly manual, and still mostly depend on a person remembering to reach for them at the right moment:
- A merge request goes in, but the Linear issue it resolves stays open.
- The docs still describe the old behaviour, and nobody is quite sure which page.
- CI has been failing intermittently for a week and everyone has learned to read past it.
- A feature flag from three months ago has no owner and no removal date.
- Support answers a ticket with a workaround for a bug that was fixed on Tuesday.
- Someone asks what went out this release, and the honest answer is "let me read the git log."
None of these are new, and none of them are really agent problems. They are the ordinary entropy of a software project. The agent just turns up the rate until the informal system that used to absorb them stops keeping up.
Prompted cleanup doesn't scale
The obvious fix is to ask the agent to clean up too, and you can. Mention @taskgoblin on the merge request and tell it to update the docs, close the issue, draft the release note. It works. But it depends on the scarcest resource in the entire loop: a human remembering to ask, every time, at the right moment.
Maintenance is not a one-off task; it is a loop. "Check the docs are current" is not something you do once. "Make sure merged issues get closed" is not something you do once. Anything that waits for a person to notice it is time to run the loop will be run inconsistently — because people are inconsistent about noticing, especially once the whole point of the agent was to stop holding all of this in your head. Prompted cleanup moves the work to the agent but leaves the scheduling of the work exactly where it was: on you.
Why we built Loops
A normal agent run is triggered by an event — an issue assignment, a mention, a new pull request. A Loop is triggered by time. You give the agent a standing instruction and a cadence — every weekday morning, every Monday, the first of the month — and it runs itself, in a sandbox, with the same tools and the same access as any other run.
The instruction is the whole task, and the good ones read like a job description rather than a wish: what to look at, which repository, what to do, what not to do, and — the part that makes it safe to run unattended — what to do when there is nothing to do, which is nothing.
Every weekday at 09:00, look at the merge requests merged in the last day in
group/repo, and close any Linear issue they resolved that is still open. If there are none, do nothing.
That is a maintenance loop with an owner. It does not wait for you to remember it. Because a scheduled run is a full agent run, it can go the whole distance: not just flag the stale doc but open the merge request that fixes it; not just notice that merged issues drifted open but close them — and then report where you will actually see it, as a comment on the Linear issue, a message in the Slack channel you named, or an email if there is nowhere better.
And because it reuses everything a normal run already does, the sharp edges are handled. Missed time is skipped rather than backfilled, so a scheduler that was down for an hour does not wake up and fire a hundred catch-up runs at you. Each run has its own budget and guardrails. We ship a set of starting templates for exactly these loops — keep issues and merges in sync, watch for CI that has been red too long, chase feature flags that have outlived their owner, draft release notes as things ship — because the useful ones are the same across most teams. You fill in your repository and your channel; the guardrails are already written.
The engineer's job moves up a level
There is a worry underneath all of this: that automating maintenance means automating away the judgement. It does not. It moves the judgement up a level. When the loops run themselves, you stop being the person who remembers to close issues and become the person who decides which loops should exist, what their guardrails are, and what "done" means for each one. You review the standing instruction instead of running the errand.
That is the more senior version of the job anyway. The agent made the code cheap to write; the work that is left is deciding what should be true about the system and making sure it stays true. Loops are how you keep it true without holding all of it in your head — the agent creates the work, and a standing loop maintains it.
