Berner Setterwall5 min read

    Auto-Merge: Let Cogny Merge Its Own Small, Fully Checked Pull Requests

    Cogny's coding agent turns a ticket into a pull request: a fixed canonical tag, a rewritten meta title, a new section on a landing page. Until now, the last step was always a person pressing Merge. For a one-line copy fix that already passed your build, tests and preview, that step is mostly waiting.

    Auto-merge removes that wait where you want it removed. It is now available to every Cogny Cloud workspace with a GitHub repository, and it is off until an owner or admin turns it on.


    TL;DR

    • Off by default. Nothing merges on its own until an owner or admin switches it on under Settings → YOLO Mode → Auto-merge.
    • Only the coding agent's own pull requests. A pull request a person opened, linked or shipped is never merged by auto-merge.
    • Hard rules first. Every check must have finished green, and the pull request must stay small and away from sensitive files. The review can hold a pull request the rules allow; it can never merge one they block.
    • Then a merge review. Cogny reads the ticket, the pull request and the whole diff, and scores it from 0 to 100. It merges only when the score reaches your merge threshold (default 90, adjustable from 50 to 100) and the review recommends merging.
    • Your policy, in plain words. Write what should always wait for a person. The review follows it, and changing it re-reviews held pull requests.
    • Every decision is visible. A comment on the pull request with the score, threshold and reasons, plus a note on the ticket.
    • Each review uses credits. A workspace with no credits left has its pull requests held, not reviewed.

    The hard rules

    Before anything is reviewed, a pull request has to pass rules that no score can override. Auto-merge holds it for a person when:

    • A check failed, or no check ran. With no checks, nothing shows the change builds, so it waits. Auto-merge also waits 10 minutes after the last check finishes, so checks that start late still count.
    • It isn't ready to merge. It is a draft, it has merge conflicts, or it targets a branch other than the repository's default branch.
    • It touches files a person should ship. Database migrations, CI and repository settings, deploy pipeline and container build config, Kubernetes manifests, environment files, package registry settings, CODEOWNERS and LICENSE.
    • It is too big to review in full. More than 15 files or more than 400 changed lines (lockfiles don't count), or a diff too long to read end to end.

    Your repository's own branch protection still applies on top: if GitHub refuses the merge, the pull request stays open and the refusal is posted on it.

    The merge review

    A pull request that passes the rules gets a merge review. Cogny reads the ticket and its expected outcome, the pull request description, the results of every check and the complete diff, and judges:

    • Correctness: does the diff do what the ticket asks, completely?
    • Scope: does it change only what the ticket needs?
    • Blast radius: could it break sign-in, billing, data or many pages at once, and is it easy to revert?
    • Hidden prerequisites: does it need something outside the diff, such as a new environment variable, an API permission, a database change or a manual setup step? If so it is held, whatever the score.
    • Your merge policy, which outranks the review's own judgement.

    The review follows only your policy. Instructions that appear inside a ticket, a pull request description or the code are never obeyed.

    The score is a confidence: 90 or more means the review would merge it without asking anyone. Set a higher threshold if you want only the most obvious changes to go through, a lower one if you are comfortable with more.

    Cogny merges exactly the commit it reviewed. If the agent pushes a correction, the new commit is reviewed again before anything merges.

    What happens after the merge

    The same thing that happens after a merge by hand. Your deploy picks up the change, the ticket moves to Analysis, and Cogny measures the outcome against the expected result in Search Console and GA4 once the data exists. If a change didn't work, the evaluation says so and the next round of tickets learns from it.

    Who can use it

    • Cogny Cloud. Code tickets and the coding agent are part of Cloud. On Free, Solo, Cogny AI and Cogny Pro the settings are shown as a locked preview.
    • A GitHub repository connected under Settings → Coding Agent. Without one, the settings explain that there are no coding-agent pull requests to merge yet. Pull requests on Forgejo wait for a person for now.
    • Owners and admins change the settings, the same people who may press Merge. Every member can read them and see the latest decisions.

    The voice agent in the app can read the settings and explain why a pull request was held ("why is this PR still open?"), and an owner or admin can change them by voice after confirming the change out loud.

    Getting started

    Most teams start with the default threshold of 90 and a short policy:

    Small copy, meta and UI fixes can go live directly. Hold anything that touches billing, sign-in or tracking.

    Then watch Latest decisions for a week. If the review holds changes you would have merged, lower the threshold a little or loosen the policy; if it merges something you would have looked at, raise it or add a line to the policy. Turning auto-merge off takes one switch, and pull requests go back to waiting for a person.