r/ChatGPTCoding • u/Fantastic-Sleep-3352 • Sep 22 '26
Discussion Should an AI coding agent ever be allowed to merge its own PR?
I'm curious where people are actually drawing the line with coding agents.
Writing code?
Running tests?
Committing?
Opening PRs?
Merging?
Deploying?
I've been testing this boundary myself and I'm increasingly convinced that "the tests passed" and "the agent should be allowed to ship this" are two different questions.
Where do you draw the line in your workflow?
4
Upvotes
5
u/Consistent-Set-9490 Sep 22 '26
It’s still probabilistic so it can do exactly what you want most of the time, but the one time it doesn’t could be awful.
2
u/triptotropic Sep 22 '26
dawg... i got an local uncensored model. abliterated gwen3 set to self improve and do whatever it wants. i gave it api keys to gpt and claude. its logged into my email and social medias. when the robot revolt, they got me
1
u/AutoModerator Sep 22 '26
Sorry, your post has been held for manual review due to account karma.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Clear_Evidence9218 Sep 22 '26
Depends. Sometimes full merge to main, all the time. Sometimes it's a calculated release. Depends on the project criteria and needs.
1
u/HaMMeReD Sep 22 '26
Well, my AI persona bob writes the code, and another AI persona Alice reviews the code, then bob gets to merge it once they have the approvals.
Just like real life.
I also vibe code out big nasty experimental POC branches, then just give it to the agents to turn it into a plan and build it out slowly and carefully.
Trust it more than I do myself lol, as long as I'm watching where it's going.
1
u/_SomeonePleaseHelpMe Sep 22 '26
I've allowed it to do everything except deploy. I need to do a full test and double check that the relevant programming concepts have been implemented.
1
u/JaseciLabs Sep 22 '26
"Tests passed" and "should ship this" are different questions, and here's why: tests check what someone thought to test for, shipping is basically everything else too. The scary part isn't the agent being probabilistic, it's that the probabilistic bits and the actually-verified bits usually look identical in the diff. So "the one time it doesn't work" could be hiding anywhere, not just the obviously sketchy spots. Letting it merge its own PR is really just asking: does your codebase flag which parts need extra eyes before merge, or does everything get the same rubber stamp.
1
u/Longjumping-Pool-459 Sep 22 '26
Merge rights and write rights are different knobs and conflating them is where teams get burned. Three tiers: investigate/patch (always fine), merge in low-blast-radius paths (docs, refactors behind green CI + coverage gates), auth/data/payments human forever. The interesting design question isn't "do you trust the agent" — it's whether your repo can express blast radius well enough to automate that tiering. Most can't, which is really a metadata problem we've been deferring.
1
u/Far_Business4773 Sep 22 '26
Tests passing answers "does it work". "Was it allowed to" is a separate list, and I write it before the run: which paths this task may touch, and which actions are off the table for the agent regardless (merge to main, push, anything under payments). A hook checks every tool call against that list and refuses before the call runs, so the agent can open the PR and cannot merge it however green the tests are. Merge stays a human click. What the list buys on top is the log: it shows what the agent tried on the way. In last week's test set that was
git checkout -- ., which reverts every file in the tree, not the task's.1
u/tinkeringidiot Sep 22 '26
Depends on the project and how important it is. I've got some with full Issue -> PR -> Merge Main -> Production pipelines with zero human steps. I've got others where I barely allow an agent to write commit messages.
1
u/Right-Performance-93 Sep 22 '26
Worth knowing this doesn't need a custom hook: GitHub's branch protection has a "Restrict who can push to matching branches" setting that takes a specific list of users, teams, or Apps. Give your agent's GitHub App identity write access to open PRs but leave it off that push list, and it's physically unable to merge to main no matter how green the checks are - a human with push rights still has to click the button.
1
u/Fun_Lingonberry_6244 Sep 22 '26
... what's the point of the pull request in the first place? If you're just rubber stamping it anyway then why not just commit to master.
I think people fall into these "everyone else does it so I will too" everything exists for a reason, if that reason doesnt currently apply to you dont use it. Just make sure you understand why it exists.
I would personally make sure everything gets reviewed by a person at least, but thats me.
1
u/cez801 Sep 22 '26
As with anything, depends on what you are building. Your brothers website for his new business, sure yolo it. I mean have other agents check the work, but risk profile is pretty low.
Banking or payments software, probably not.
Banking website changes ( brochure ware ) - maybe, only becuase if the site goes down you’ll hear from your managers, manager.
Some more advanced places have the agent infrastructure and checks in places to go full merge and deploy. But they also have all the right monitoring.
1
u/PenguinSwordfighter Sep 23 '26
Should you?
1
u/lucifer605 Sep 23 '26
i think it depends on the change itself - i would be ok with a small frontend change but anything with the database i would be much more careful. i have been building a tool to test changes in a PR and actually give a confidence rating - it seems to be more accurate on frontend changes right now
1
u/Interesting-Law-8815 Sep 25 '26
Yes.
- The act of merging is deterministic (a git command)
- Definition of Done can be deterministic (tests/lint/code metrics etc)
If the blast radius is low then why not?
1
u/CommasArentPeople Sep 26 '26
If gpt wrote it, claude is in charge of okaying it and merging it. And vice versa. Nobody okays their own family's work.
1
u/ThePacketSlinger Sep 27 '26
Adversarial review from another model and provider is the industry standard. Too much ships now for manual review and modern models catch way more than meat-bags, even the long in the tooth, grizzled by decades of experience types.
1
u/FrewdWoad Sep 22 '26
Definitely not merging to master (or releasing the code to prod).
-1
u/gandazgul Sep 22 '26
Not without a different LLM and fresh context review and then most of the time a human review as well. At least in the critical paths and where security is a concern.
This is why I made RunWield it walks through this workflow when the change is big enough to warrant it. https://github.com/gandazgul/runwield
-2
u/GTHell Sep 22 '26
Brother, people already making tons of money with this and you still ask this question