Let your AI agents open pull requests, not commits

AI agents should change your code through pull requests, not by committing straight to the main branch. A pull request gives you one diff to read, one unit to revert and a record of who changed what and why. In GATE, that is the default path for every code change: your agent writes the request up as a GitHub issue, a coding session builds it on its own branch, the session reviews its own diff, and your agent merges only once the required checks pass and your repository’s own rules allow it.

Why is it risky to let an AI agent commit straight to main?

An agent that writes straight to your main branch is making an unreviewed change to the code everything else builds on. That is risky for the same reasons it would be risky from a person, only more so, because the agent moves faster and does not feel the social weight of breaking the build for everyone.

A model sounds sure even when it is wrong. It will produce a clean, plausible change that misreads the intent, deletes a check that looked redundant but was not, or fixes a symptom and leaves the cause. With no boundary between the agent’s output and your main branch, that change is live the moment it is written, and nobody looks at it before it lands.

It also takes away your ability to reason about what happened. When agents commit directly, your history becomes a stream of changes with no unit you can point at, approve or undo. You cannot say “this set of edits, for this reason, reviewed before it went in.”

What does a pull request give you that a commit does not?

A pull request is what makes autonomous code changes safe to allow at all. It gives you four things a direct commit does not.

A review surface. Everything the agent changed for one task sits in one bounded diff, with the reasoning attached. You read a proposal instead of digging through history.

A rollback point. The change lands as one unit and can be reverted as one unit. If it turns out wrong a week later, you revert the pull request instead of hunting down scattered commits.

An audit trail. Who asked for the change, what it was meant to do, what was discussed and when it merged. A pull request produces that record as a side effect of normal work.

A natural stopping point. The agent finishes its task and stops at the pull request. It does not carry on into the next thing on the assumption that its last change was correct.

None of this is new. Good engineering teams already hold each other to it. An AI agent is a contributor like any other and should be held to the same boundary.

Should the agent review its own diff?

Yes, and it raises quality more than almost anything else. It sounds redundant for the same agent to check its own work. The reason it helps is altitude. While writing code, an agent thinks locally: this function, this file, this problem. When it re-reads the whole diff with a different instruction, “you are reviewing this change, find what is wrong with it”, it looks at the change as one object. It catches the debug line it left in, the value it hardcoded, the edge case it skipped and the test that locks in the bug instead of the intent.

Every GATE coding session makes that pass before your agent merges. The gain is even larger when the reviewer is a separate agent with fresh context that never saw the original reasoning, the same logic behind multi-agent workflows: separate the writer from the checker and quality goes up.

Who merges in GATE, and when?

In GATE, your agent merges, and only when three things hold.

1. The session has reviewed its own diff. That is the working rule for every coding session, before any merge.
2. The required checks have passed. GATE reads the pull request’s checks before every merge. A failed required check stops the merge, and the refusal names the check. Checks still running park the merge, and GATE lands it when they pass. A parked merge that waits 6 hours is dropped without merging, and the chat that asked is told. Your agent cannot merge past a red required check: only GATE’s own operators can override one, and the override is logged.
3. GitHub accepts the merge. GATE merges through GitHub’s normal merge, so your repository’s branch rules apply to the account GATE merges as.

If you want a person to approve changes, require it on GitHub. One detail matters: by default, GitHub’s classic branch protection does not bind people with admin rights on the repository (GitHub’s documentation on protected branches). If the account GATE merges as is an admin, turn on the setting that stops admins bypassing the rule, or use a ruleset and leave that account off its bypass list, so the approval binds it too.

Where does the human stay in the loop?

You decide what gets built and which rules every change must pass. You ask for the change, and it is written down as an issue before any code moves. You can watch any session live in the chat’s code session window and stop it at any time. You choose which changes need a person’s approval, through your repository’s rules. And a straight commit to the main branch happens only when you explicitly say so for a fix of one or two files, never for database changes, sign-in or billing.

How tight to make the gate should scale with the stakes. A documentation typo can go through on review and green checks. A change to sign-in, billing or anything that touches money or personal data deserves a required approval from a person, every time. The pull request boundary is what lets you set that dial deliberately, instead of one blanket level of trust for everything an agent does.

What GATE does not do

• It does not run continuous integration for your repositories. It reads the checks your repository already runs, and a repository with no checks merges after the review alone.
• It gives you no preview environment per pull request.
• It has no one-press rollback. A git revert is the undo, and a site hosted on GATE deploys the revert like any other push.

How do you start?

GATE is invite only right now while it onboards a small number of businesses. Once you are in, an owner of your organization approves the GATE GitHub App once, your repository is connected, and you ask your agent for the first change in plain language. AI coding agents on GATE shows the whole path, the Trust Center lists the controls GATE runs, and you can see how teams use it on production workloads.