It comes up in nearly every demo. The checks are green, the diff is small, the spec was approved — why does a person still have to press merge?
It is a fair question with a boring answer: because the failure mode is not symmetrical. A pull request that waits an hour costs an hour. A bad change that merges itself costs the incident, the revert, the post-mortem, and a permanent dent in how much anyone trusts the queue.
Green is not the same as correct
Our own gates catch a lot. Tests run, the diff is reviewed by a critic pass, secrets are scanned for. All of that reduces how often something is wrong. None of it establishes that the change was the right thing to build, which is the judgement a reviewer is actually making.
A test suite tells you the code does what the code says. It does not tell you the spec was a good idea. We have watched runs implement an approved specification correctly and completely, and be wrong, because the specification was wrong. No amount of automated checking finds that — only somebody who understands the product does.
The boundary is structural, not a setting
There is no auto-merge toggle to find, and no API call in our codebase that merges anything. That is deliberate. A capability that exists behind a flag is one that gets switched on during a busy week and quietly stays on.
The same reasoning applies to protected branches. CodeLynq pushes to its own branch and opens a pull request. If you merge nothing, nothing ships.
So the waiting has to be cheap
Refusing to merge is only defensible if the review is not where everything piles up. That is the actual engineering problem, and most of what we build points at it.
The change arrives already verified, self-reviewed and scanned, with anything unresolved written into the description instead of left to be discovered. When CI goes red afterwards, the run comes back and works the same branch rather than waiting for someone to notice. When a reviewer does leave a comment, it becomes a durable rule for the project so the next task does not repeat the mistake.
Aim at making review fast, not at removing the reviewer. The second one is easier to build and much harder to live with.
What does run unattended
Some things genuinely should not need a person: fixing a failing build on an open pull request, opening a draft fix when an alert fires, triggering your existing deploy pipeline after you merged.
Those exist, and every one of them ships switched off, is enabled per project, and carries a ceiling. Iterations are capped per run, alert runs are capped per hour, and all of it counts against the same quota as work a person started. Autonomy you have to ask for is a different thing from autonomy you discover.