DEV Community: AI CodeOps

AI Coding Agents Beyond GitHub: GitLab, Bitbucket, Gitea and Forgejo

AI CodeOps — Fri, 30 Oct 2026 02:02:05 +0000

Most AI coding agents assume your code lives on GitHub. A lot of it doesn't. Here's what it takes to run gated AI changes on the Git host you already use.

If you read the docs of most AI coding agents closely, one line keeps showing up: works with repositories hosted on GitHub. That's a reasonable place to start. GitHub is huge.

But plenty of teams aren't there. Enterprises run self-managed GitLab. Agencies live in Bitbucket. Privacy-minded teams and a growing slice of open source run Gitea or Forgejo on their own servers. For them, "just use the agent" means moving their code first, which usually means not using the agent.

We built AI CodeOps to work where the code already is.

One workflow, five Git hosts

AI CodeOps connects to GitHub, GitLab, Bitbucket, Gitea and Forgejo. The flow is the same on each:

Connect once. Use OAuth for the hosted services, or a personal access token for your own server. For a self-hosted GitLab, Gitea or Forgejo, you enter the server's public https address and paste a token
Describe a change in the browser. Agents plan it, write it, review it and run the project's own tests in a sandbox
Get a pull request on your host. When the change passes the release gate, AI CodeOps pushes a branch named codeops/run-<id> and opens a pull request (a merge request on GitLab) into the default branch

A team that uses more than one host can run all of them from one workspace.

What it does, and what it doesn't

For teams that own their tooling, the second list matters as much as the first. On Gitea and Forgejo, for example, AI CodeOps:

Does list the repositories, branches, files and pull requests the connected account can see
Does push a branch and open a pull request, with commits authored as "AI CodeOps"
Doesn't need admin access. An account that can read the repository, push a branch and open pull requests is enough
Doesn't install webhooks, post commit statuses or comment on your pull requests
Never pushes to your default branch directly

Tokens are encrypted at rest and never written into a repository's Git configuration. To remove access, disconnect in AI CodeOps or revoke the token on your server.

The gate goes with you

The point isn't only that the agent can reach your host. It's that the same rules apply there. A change opens a pull request only when your tests passed on that exact version, the AI review of the real diff has no open high or critical findings, and a person approved it. If a check errors, the gate fails closed.

A pull request opened by AI CodeOps can be merged from the console only after the release gate passes again. You can also merge it on your host as usual, and if you want those merges gated too, your CI can ask the gate for a verdict through an API and fail the job on a "no".

A note for Codeberg users

Codeberg runs Forgejo, so the connection works with https://codeberg.org and a personal access token. But read Codeberg's Terms of Use first: they don't allow projects that mostly consist of code written by generative AI tools. That's their call, and worth respecting.

Try it on your host

AI CodeOps runs in the browser, with nothing to install. It's free during the open beta, and free forever for non-commercial open-source projects.

Integrations: aicodeops.dev/integrations
Open source program: aicodeops.dev/pricing/open-source

Drafted with AI assistance and edited by the AI CodeOps team.

Free Forever for Open Source: Why We're Giving AI CodeOps to Maintainers

AI CodeOps — Fri, 30 Oct 2026 02:01:24 +0000

Maintainers carry a lot of the software world. If AI agents are going to touch their projects, they should do it behind the same quality gates as everyone else, at no cost.

Open-source maintainers are in an odd spot right now. AI tools make it easy for anyone to send a pull request, so the volume of contributions goes up. The time a maintainer has to review them does not.

The usual answers are to review faster or to say no more often. Neither scales. What does scale is making every change prove itself before a person spends time on it.

That's the idea behind AI CodeOps, and it's why we're making it free forever for non-commercial open-source projects.

What maintainers get

The open source plan isn't a trial. Approved projects get, at no cost:

Higher limits than the free plan: more workspaces, seats and AI models
300 sessions a month on the platform's models. Past that, you can keep going on your own model provider key, or wait for the monthly reset
The release-gate badge for your README, turned on for you
A usage meter in the console, so you always know where you stand

It's the same product, with the same gates. Nothing is held back for paying customers when it comes to what a change must pass before it merges.

What the gate does for a project

Every AI change in AI CodeOps waits at a release gate. It becomes a pull request only when:

Your own test suite passed in a sandbox, on that exact version of the change
The AI review of the real diff has no open high or critical findings
A person approved it. The person who started the session can't cast the approving vote while someone else in the workspace can

If any check errors, the gate fails closed. For a maintainer, that means the pull request in your queue has already been tested and reviewed, and someone has looked at it.

Each change also carries a signed evidence pack: the task, the models used, the findings, the test runs and the approvals. When someone asks how a change got in, there's a record.

Your Git host, your server

A lot of open source doesn't live on GitHub. AI CodeOps works with GitHub, GitLab, Bitbucket, Gitea and Forgejo, including self-hosted GitLab, Gitea and Forgejo servers connected with a personal access token. Branches and pull requests stay on your server.

One honest note: if your project is on Codeberg, read its Terms of Use first. Codeberg doesn't allow projects that mostly consist of code written by generative AI tools. The connection works, but the rules are Codeberg's to set.

Who qualifies

A public repository under an OSI-approved license
A non-commercial project: not sold, not the core of a paid product, and not run by a company to make money from it. Community projects, libraries and tools qualify, even with sponsors or donations
Approved by application. We read every one, usually within a few working days, and email you either way

How to apply

Sign up at aicodeops.dev with the email you'll use for the project. Approval moves that account's own organization onto the open source plan
Fill in the short form at aicodeops.dev/pricing/open-source: email, repository URL, maintainer's GitHub username, license, and a few words about the project

And as with every plan: AI CodeOps doesn't use your code, prompts or outputs to train AI models.

If you maintain something people depend on, we'd like to help you ship changes you can trust. Apply here: aicodeops.dev/pricing/open-source. Program updates are posted at github.com/aicodeops-dev/announcements.

Drafted with AI assistance and edited by the AI CodeOps team.

AI CodeOps vs GitHub Copilot's Coding Agent: When Each One Fits

AI CodeOps — Fri, 30 Oct 2026 01:43:11 +0000

A fair comparison as of October 2026, including when Copilot is the better choice.

GitHub Copilot's coding agent (GitHub's docs now call it the Copilot cloud agent) and AI CodeOps solve a similar problem. You hand over a task, the work happens in the cloud, and you get back a pull request. The differences are in where they work, how changes are gated, and what you pay.

This comparison uses GitHub's own documentation for the Copilot facts, as of October 2026. It's about the coding agent, not Copilot code review, which is a separate feature.

What the Copilot agent does

According to GitHub's docs, the agent can research a repository, plan changes and implement them in the background, in a temporary cloud environment where it can run tests and linters. You can start it from an issue, a pull request, a chat or the agents panel. It creates a branch, pushes commits and opens a pull request.

GitHub builds solid safeguards around it. The person who asked for the pull request can't approve it. The agent can't approve or merge, and it can only push to its own branch. By default, workflows don't run until a person has reviewed its code.

Its documented limits: it works only with repositories hosted on GitHub, it works on one branch and opens one pull request per task, and each session runs for at most 59 minutes.

What AI CodeOps does

AI CodeOps runs AI software-engineering sessions in your browser. Specialised agents (architect, builder, reviewer, tester, security auditor and others) plan the task, write the change, run your tests and review the result. The change then waits at a release gate until your tests pass, the AI review is clear and a person approves it.

Side by side

	Copilot coding agent	AI CodeOps
Git hosts	Repositories hosted on GitHub	GitHub, GitLab, Bitbucket, Gitea, Forgejo (incl. self-hosted)
Approvals	Requester can't approve; agent can't approve or merge	Session starter can't cast the approving vote when another approver exists; policies can require two
Gate	Your branch protection and required checks	Built-in gate combining tests, review findings and approvals; fails closed
Evidence	GitHub history	Signed evidence pack per change
Individual pricing	Copilot Pro $10/mo, Pro+ $39/mo, Max $100/mo (not in Free)	Free during the open beta
Org pricing	Business $19/seat, Enterprise $39/seat; admin must enable the agent	Enterprise per seat, through sales
Where it runs	GitHub.com, supported IDEs, CLI	Browser only (no IDE extension or CLI)

When Copilot is the better choice

Your code is all on GitHub and you already pay for Copilot.
You want the smallest change to your tooling, with no second product to adopt.
You like GitHub's default safeguards on agent pull requests.
Your developers already use Copilot in the editor.

When AI CodeOps fits

Your code lives on GitLab, Bitbucket, Gitea or Forgejo, or across several hosts.
You want several agents to review each change before a person sees it.
You want one gate that covers tests, findings and approvals together, with signed evidence for each change.
You need spend control: caps per workspace and per workflow, cost per session, model tiers, or your own provider key.

How to decide

If your code is on GitHub and Copilot is already in place, try the Copilot agent first, since it costs you the least to adopt. If you need other Git hosts, a gate with signed evidence, or per-workflow spend caps, run AI CodeOps on the same repository and compare.

Full comparison with sources: aicodeops.dev/compare/aicodeops-vs-copilot-agent

💚 AI CodeOps is free forever for non-commercial open-source projects: apply here.

Originally published on Medium. Drafted with AI assistance and edited by the AI CodeOps team. Copilot details are from GitHub's documentation as of October 2026 and may change.

Who Approves the AI's Code?

AI CodeOps — Thu, 29 Oct 2026 21:49:04 +0000

When an AI agent writes the code, who reviews it? The rules that keep "approved" meaning something.

In the first post in this series, Nothing Should Merge on an AI's Word, one of the gate's checks was "a person approves it." That sounds like the easy part. It's not.

With human-written code, the author and the reviewer are obviously different people. With AI-written code, the line blurs. Someone writes a prompt, an agent writes the change, and the same someone looks at the diff and clicks approve. Technically a human approved it. In practice, nobody but the requester ever looked.

That's the problem this post is about: keeping approval a real second opinion when the "author" is an agent.

The prompter is the author

The person who starts an AI session is the closest thing that change has to an author. They chose the task, steered the agent, and probably accepted its first plan. They're also the person most likely to approve it quickly, because it does what they asked.

So the rule should be the same as for human code: the person who launched the session can't be the one who approves it, as long as someone else can.

In AI CodeOps that's built in. A code-change review needs one approval from someone other than the person who launched the session. That makes it a two-person rule whenever a second approver exists. The launcher can still reject their own change, because stopping something never needs a second opinion.

Don't lock out the solo developer

A strict two-person rule has an obvious failure: a team of one can never ship anything. Small teams then switch the rule off entirely, and it never comes back on.

The better rule is conditional. The launcher can't approve when anyone else in the workspace can. A solo workspace can still approve its own work. The moment a second approver joins, the two-person rule applies on its own, with no settings to remember.

Five rules that keep approval honest

Separation of duties is the headline, but a few smaller rules matter just as much.

1. Editing after approval resets it. If the change is edited after someone approved it, the approval goes back to pending. Otherwise "approve now, fix it up later" turns an approval into a blank check. This is the same idea as the tested-version rule from the first post: approval applies to a version, not to a pull request.

2. One reject ends it. A single rejection closes the request. Another person's approval doesn't reopen it. If one reviewer saw a real problem, three approvals from people who didn't shouldn't outvote them.

3. A reject needs a reason. Approvals take an optional note. Rejections require a reason. A bare "no" teaches the requester nothing and tends to get worked around.

4. People are counted, not clicks. Votes are counted per distinct person, and voting again replaces your earlier vote. Nobody gets two votes by clicking twice.

5. Approvals expire. A code-change review expires after 7 days. A week-old approval was given against a codebase that has since moved, so it's asked for again.

Approval is one check, not the only one

Approval doesn't open the pull request on its own. The pull request opens only if the quality gate also passes: tests ran on this version, no high or critical findings are open, and policy allows it.

That separation matters. A reviewer shouldn't have to re-run the tests in their head or re-check every file path against policy. The gate handles evidence. The person answers the question only a person can answer: is this the change we actually want?

Policies decide when to ask

Not every action needs a human, and asking for everything trains people to click "approve" without reading. Policies let you decide where approval is worth the interruption.

Each policy rule is allow, ask or deny. When several rules match, the strictest one wins: deny beats ask, and ask beats allow.

A few patterns that work well:

Protected paths. Rules on file patterns, such as infra/** or anything under auth and payments, are checked when the pull request opens, against every file the change touches. The agent can still write the change; it just can't ship it without passing the rule.
Ask before starting risky work. Dispatching certain workflows or agents can be set to ask, so a person signs off before the session even starts.
Some actions can't wait. Running a shell command, calling an MCP tool or deploying can't pause for a person, so those can only be allowed or denied, never "ask." That's a useful constraint: it forces you to decide ahead of time.
Try rules in log-only mode first. A rule set to log only records what it would have done without blocking anything. Run it for a week, check what it would have stopped, and then enforce it.

Every policy change is saved as a new version with an audit entry, so "who loosened this rule?" always has an answer.

Approvals belong in the record

The last piece connects to the next post in this series. The approval, the list of people who were eligible to approve, and each vote with its time and note all go into the change's signed evidence pack. Months later, "who approved this?" isn't a Slack search. It's a field in a record you can verify.

The checklist

The launcher doesn't approve. Require someone other than the person who started the session, whenever someone else can.
Keep solo teams working. Make the rule conditional instead of switching it off.
Approve versions, not pull requests. Any edit after approval resets it.
Let one "no" win, and make it explain itself.
Ask only where it matters. Use protected paths and ask rules for risky areas, and try new rules in log-only mode first.

An approval is only worth something if the person giving it could have said no, and wasn't the one who asked for the change.

AI CodeOps is free during the open beta and free forever for non-commercial open-source projects. The full rules are in the approvals and policies docs.

Drafted with AI assistance and edited by the AI CodeOps team.

Your Merge Button Is the Real Quality Gate

AI CodeOps — Thu, 29 Oct 2026 21:48:49 +0000

A release gate only works if the merge button has to ask it. Here's how to wire one into CI so it fails closed.

In the last post, Nothing Should Merge on an AI's Word, I argued that AI-written code needs a gate between "the agent finished" and "this is a pull request," and that the gate should check evidence: a review that ran, tests that passed on this exact version, and a person who said yes.

There's a hole in that picture. A gate inside one tool only covers changes made through that tool. Pull requests still get opened by hand, branches still get pushed, and the merge button on GitHub or GitLab doesn't know your AI platform exists. If the gate can be skipped by clicking somewhere else, it's not a gate.

So the real question is: how do you make the merge itself ask for a verdict?

Put the check where the merge happens

The answer is boring, which is a good sign: a CI job that asks the gate for a verdict on this pull request, and fails when the answer is no. Then you make that job a required status check in branch protection.

That second step is the one teams forget. A CI job that isn't required is a dashboard. It only becomes a gate when the merge button is greyed out until it passes.

In AI CodeOps, the question goes to one endpoint, POST /api/release/check, with a workspace API key. You send a pull request URL (or a commit SHA, at least 7 characters) and get back a verdict that covers every AI session that touched that change:

allowed: true or false
summary and reasons: plain-English explanations
blockingFindings, testFailures, coverageShortfall, licenseViolations: the detail behind a deny
runsConsidered: which sessions the verdict was based on

The trap: "200 OK" doesn't mean "allowed"

Here's the detail that makes or breaks a CI gate. The endpoint returns HTTP 200 for both outcomes. A denied change is a successful API call with "allowed": false in the body.

That means the most common way to write this check is wrong:

# Looks fine. Lets everything through.
curl -sf -X POST "$CONSOLE/api/release/check" ...

curl -f only fails on HTTP errors. A deny comes back as 200, so the step goes green and the change merges. That's a gate that fails open, which is the one thing a gate must never do.

The fix is to read the body and treat anything other than an explicit true as a no:

jq -e '.allowed == true' > /dev/null

jq -e exits non-zero when the result is false or null, so a deny fails the job, and so does a missing or malformed field.

A fail-closed GitHub Actions job

Putting it together:

name: ai-release-gate

on:
  pull_request:

jobs:
  release-gate:
    runs-on: ubuntu-latest
    steps:
      - name: Ask the release gate for a verdict
        env:
          WORKSPACE_API_KEY: ${{ secrets.AICODEOPS_API_KEY }}
          PR_URL: ${{ github.event.pull_request.html_url }}
        run: |
          set -euo pipefail

          body=$(jq -n --arg pr "$PR_URL" '{
            pullRequestURL: $pr,
            blockingSeverity: "medium",
            minCoveragePct: 80,
            blockOnInFlight: true
          }')

          resp=$(curl -sSf --retry 3 --retry-all-errors \
            -X POST "https://console.aicodeops.dev/api/release/check" \
            -H "Authorization: Bearer $WORKSPACE_API_KEY" \
            -H "Content-Type: application/json" \
            -d "$body")

          echo "$resp" | jq -r '.summary'
          echo "$resp" | jq '.reasons'

          # Anything other than an explicit "true" fails the job.
          echo "$resp" | jq -e '.allowed == true' > /dev/null

Every way this can go wrong ends in a red check:

What happens	Result
Gate says no	`allowed` is `false`, `jq -e` fails the job
Gate couldn't evaluate	`allowed: false`, summary "Evaluation failed."
No AI session touched this change	Denied: there's nothing to judge
Bad or missing API key (401/403)	`curl -f` fails the job
Invalid request (400)	`curl -f` fails the job
Rate limited (429, 60 checks/min per workspace)	curl retries, then fails if it still can't get through
Network down, API unreachable	curl retries, then fails
Response isn't valid JSON	`jq` errors, `set -e` fails the job

Nothing on that list ends in a green check. That's the property you want.

Two practical notes. The key only needs the workspace:read permission, so don't hand CI a more powerful one. And use the same host you open the console on.

Tune the bar per pipeline

The defaults block on open high and critical findings and on failing tests. CI is where you can be stricter, because different branches deserve different bars:

blockingSeverity: "medium" blocks on medium findings too. Reasonable for anything that touches auth, payments, or infrastructure.
minCoveragePct sets a coverage floor for the latest run that reported coverage.
requiredWorkflows lists workflows that must have completed on this change, such as a security audit.
disallowedLicenses checks the project's SBOM for licenses you can't ship.
requireDeployedTo: "staging" denies until the change has been deployed to staging. Useful on the job that promotes to production, not on every pull request.
blockOnInFlight: true denies while a session for the change is still running, so nobody merges halfway through a fix.

The gate looks back 14 days by default (lookbackMs changes that). An old session isn't silently reused forever.

Then keep the receipt

The gate decides whether a change ships. The evidence pack is how you prove later why it did.

Every change gets a signed pack: the task and the models used, each run with its tokens and cost, review findings and how they were triaged, test results and coverage, policy decisions, who was eligible to approve and how each person voted, and the pull request and deployment it ended up in. The code itself isn't included. Instead the pack carries a SHA-256 hash of the diff, so you can match it against the pull request.

The part I like is that you don't have to trust the platform to check it. Packs are signed with Ed25519 over canonical JSON, and the public keys are published at /api/evidence?action=keys. You can verify a pack in the browser at aicodeops.dev/evidence/verify without an account, or offline with Node's built-in crypto module. Keep a copy of the keys file next to your audit records, and verification doesn't depend on the vendor still being reachable in three years.

Retired keys stop signing new packs but are never deleted, so old packs keep verifying.

The checklist

If you're adding AI agents to a repository this quarter, here's the short version:

Gate the merge, not just the agent. Run the verdict check in CI and make it a required status check.
Read the verdict, not the status code. allowed == true or the job fails.
Make every error a no. Bad key, timeout, rate limit, unreadable response: all red.
Raise the bar where it matters. Stricter severity and coverage on sensitive paths, a staging requirement before production.
Keep evidence you can verify yourself. A signed record beats a chat log.

AI agents can write a lot of code. The merge button is where you decide how much of it you trust.

AI CodeOps is free during the open beta and free forever for non-commercial open-source projects. The full field list is in the API docs, and the gate itself is described at aicodeops.dev/product/quality-gates.

Drafted with AI assistance and edited by the AI CodeOps team.

An Audit Trail You Don't Have to Take on Trust

AI CodeOps — Thu, 29 Oct 2026 21:48:00 +0000

"The AI wrote it" isn't an answer. A signed record of how each change shipped is, as long as you can check it without trusting the vendor.

This is the last post in a short series. The first, Nothing Should Merge on an AI's Word, argued for a gate between "the agent finished" and "this is a pull request." The second and third covered wiring that gate into CI and keeping approvals honest. This one covers what's left after a change ships: the record.

Six months later

A bug reaches production. Someone runs git blame and finds the commit. It came from an AI session in the spring.

Now the questions start. What was the agent asked to do? Which model wrote it? Did the review flag anything, and if so, who decided it was fine? Did the tests actually run on this version? Who approved it?

For human-written code you'd ask the author. For AI-written code there's no author to ask, and the chat history is probably gone. If the answers aren't written down somewhere durable, they're lost.

What a useful record contains

A good record answers those questions without needing anyone's memory. In AI CodeOps, every change gets an evidence pack that covers:

The task: the prompt, the model and provider, and the context files the agent was given.
The runs: each session and follow-up run, with status, timings, tokens, cost, and which provider and model handled each agent step.
The result: the summary, the changed files, and a SHA-256 hash of the diff.
Approvals: who was eligible to approve, and each vote with its time and note.
Policy decisions: every allow, deny or ask made during the change.
Findings and tests: review findings and how each was triaged, plus test results and coverage.
Delivery: the pull request, the deployment, and any linked incident.
The audit trail: the related audit log entries, and the email address behind each account ID.

Notice what's missing: the code itself. The pack carries a hash of the diff, not the diff. You match the hash against the pull request, which keeps source code out of an artifact you might hand to an auditor.

A record you can edit isn't evidence

A log stored in a database the vendor controls proves very little. Anyone with write access, including the vendor, could change it after the fact. For a record to count as evidence, you need to be able to tell whether it was altered.

That's what the signature is for. Each pack is signed with Ed25519 over a canonical form of its contents: the JSON payload with object keys sorted at every level and no whitespace. Canonical form matters because the same data can be serialised many ways. Without it, re-saving a file in an editor could break a valid signature.

If anyone changes a single field, whether it's a vote, a finding's triage status or a model name, the signature no longer matches.

Don't trust the verifier either

A signature is only useful if the check doesn't depend on the party that signed it. "Our server says the pack is valid" proves nothing if the server is the thing in question.

So there are two ways to verify a pack, and the second needs no trust in the platform at all.

In the browser. Open aicodeops.dev/evidence/verify and pick the file. No account is needed. It tells you whether the signature matches and which key signed it.

Offline, on your own machine. First fetch the public keys:

curl -o keys.json "https://console.aicodeops.dev/api/evidence?action=keys"

Then run a short Node.js script. It uses only Node's built-in crypto module and needs Node 20 or later. The script:

Reads the pack and keys.json.
Finds the public key whose kid matches the pack's signature.kid.
Rebuilds the canonical JSON of the pack's payload.
Checks the Ed25519 signature against it.
Prints VERIFIED, or NOT VERIFIED: the pack was altered.

The full script is in the evidence pack docs, under "Verify a pack offline." It's short enough to read in a minute, which is the point: you should be able to see exactly what it checks.

node verify-evidence.mjs evidence-chg_....json keys.json

Keep the keys with the records

One step people skip: save a copy of keys.json next to your audit records. If you only ever fetch keys live, verification depends on the platform still being online, and still serving the same keys, years from now.

Keys are never deleted. A retired key stops signing new packs, but every pack it already signed keeps verifying. Still, an auditor shouldn't have to take that on faith. A local copy of the keys file turns "the vendor says so" into "the maths says so."

Who can download a pack

Evidence packs include people's email addresses and the full history of a change, so access is limited. Only owners, admins and security admins can download them, from Changes, then the change, then Download evidence pack. Each download is itself recorded in the audit log.

The checklist

Record the decisions, not just the code. Task, models, findings, triage, tests, approvals, policy decisions.
Sign the record. An unsigned log is a claim, not evidence.
Use canonical form. So the same data always produces the same signature.
Verify without the vendor. Public keys plus a script you can read.
Keep the keys. Store keys.json with your audit records.

Across the series, the idea has been the same: AI agents can do the work, but trust comes from evidence. Tests that ran on this version, a review that read the real diff, a second person who said yes, and a record of all of it that anyone can check.

AI CodeOps is free during the open beta and free forever for non-commercial open-source projects. Learn how evidence packs work in the docs.

Drafted with AI assistance and edited by the AI CodeOps team.

Nothing Should Merge on an AI's Word

AI CodeOps — Thu, 29 Oct 2026 21:35:36 +0000

Why AI-written code needs quality gates that fail closed, and what a good one checks.

AI coding agents are fast now. They can read a repository, plan a change, write it, and open a pull request in minutes. That speed is real, but it creates a quiet problem: the volume of changes grows faster than a team's ability to check them.

When an agent says "done," teams tend to take one of two shortcuts. Either they trust the agent's summary of its own work, or they skim a diff that is too large to read carefully. Both mean the bar for AI-written code ends up lower than the bar for human-written code. It should be the same, or higher.

The fix isn't to slow agents down. It's to put a gate between "the agent finished" and "this is a pull request," and to make that gate check evidence, not opinions.

What a quality gate should check

At AI CodeOps, every AI change waits at a release gate. It opens a pull request only when all of these hold:

The review actually ran. A review step reads the real diff and records structured findings. If the review couldn't finish, the change is held. A missing review never counts as a pass.
No serious findings are open. A high or critical finding that is still open, acknowledged or in progress blocks the change. To clear it, you fix it or triage it.
Your tests don't fail. The project's own test suite runs against the change in a sandbox. The agent may plan tests, but only a real test run counts.
The tested version is current. If someone edits the change after the tests ran, the old result no longer counts.
A person approves it. The person who started the session can't cast the approving vote while someone else in the workspace can. Editing the code after approval resets it to pending.
Workspace policy allows it. The repository and every changed file are checked against your policies before the pull request opens.

Fail closed, not open

The most important property of a gate is what it does when something goes wrong. If a check errors, the safe answer is "no." A gate that lets changes through when the reviewer times out or the test runner crashes isn't a gate. It's a suggestion.

The same goes for missing evidence. If the gate can't find a session for a change, it has nothing to judge, so it denies.

Gating merges outside the platform

A gate inside one tool only covers changes made through that tool. Someone can still merge directly on GitHub or GitLab. To cover that path, your CI can ask the gate for a verdict through an API, with a pull request URL or commit SHA, and fail the job when the answer is no. You can also make CI stricter per pipeline: block on medium findings, set a coverage floor, or require a change to be deployed to staging first.

Keep a record of how each change shipped

When something breaks in production, "the AI wrote it" isn't an answer. Each change should leave a trail: the task, the models used, the findings, the test runs, who approved it and how each person voted. In AI CodeOps that trail is a signed evidence pack that anyone can verify.

The bar should not move

AI agents are a real productivity gain. The way to keep that gain is to hold their work to the same standard as everyone else's: tests that ran on this exact version, a review that read the real diff, and a person who said yes.

AI CodeOps is free during the open beta and free forever for non-commercial open-source projects. Learn how the gate works at aicodeops.dev/product/quality-gates.

Originally published on Medium. Drafted with AI assistance and edited by the AI CodeOps team.