How to Set Up Quality Gates for AI-Generated Code

Jul 09, 2026

Share this article:

Author: Pepe

An AI agent that writes code and immediately commits it is a liability, not a productivity gain. The fix isn't reviewing every line by hand, that defeats the purpose of running agents in the first place. The fix is putting checks between "agent wrote code" and "code merges," so bad output gets caught by a script instead of by you finding it in production three weeks later.

That's what a quality gate is: an automated checkpoint in your pipeline that an agent's output has to pass before the next step runs. No passing tests, no merge. No clean lint, no deploy. The gate doesn't judge whether the code is good, it judges whether the code meets the bar you defined.

Why Quality Gates Matter More With Agents Than With Humans

A human developer internalizes your team's standards over months of code review feedback. An agent doesn't retain that. Every session starts fresh, and an agent under time pressure to "finish the task" will happily produce code that passes a manual glance but fails on edge cases, security practices, or your team's actual conventions. This isn't hypothetical: the 2025 Stack Overflow Developer Survey found that 66% of developers are spending more time fixing "almost-right" AI-generated code, which is exactly the failure mode a gate is built to catch before it reaches a human at all.

This gets worse as you parallelize. One agent you're watching closely is manageable. Five agents running simultaneously on five different branches means you physically cannot review each one's work in real time. Gates are what let you scale from one supervised agent to many, because the supervision moves from "a human watching" to "a rule enforcing." How to Manage Parallel Agents Without Losing Track covers the tracking side of that same problem.

Add gates as you find failure patterns, not before. A gate you added speculatively and never tuned just slows things down.

Building Gates Into a Pipeline

A single gate bolted onto one task doesn't scale, you end up re-implementing the same checks by hand every time you kick off agent work. The fix is defining the gate once, as a reusable step in a pipeline, so every task that matches a pattern runs through the same checks automatically.

This is what Unstoppable Code's pipeline engine is for. Pipelines are YAML-defined, built specifically for orchestrating agents rather than adapting a generic CI tool, with a job dependency graph, retries, and reusable built-in actions rather than one-off scripts. A quality-gated pipeline follows this shape:

pipeline:
  name: 'Implement and Gate'
  version: '1.0'
  description: 'Implement a task, run quality gates, and pause for human approval before merge.'
  scope: worktree
  on:
    task_ready: {}
  jobs:
    implement:
      name: Implement Task
      max_retries: 2
      steps:
        - id: write_code
          uses: builtin/agent-prompt
          with:
            model: opus
            permission_preset: plan

    quality_check:
      name: Run Quality Gates
      needs: implement
      steps:
        - id: run_tests
          shell: bash
          run: npm test
        - id: gate
          uses: builtin/quality-gate
          with:
            criteria: 'tests pass, lint is clean, diff touches 6 files or fewer'

    review:
      name: Human Review
      needs: quality_check
      steps:
        - id: approve
          uses: builtin/request-input
          with:
            prompt: 'Review the diff and approve before merge.'
        - id: open_pr
          uses: builtin/github-create-pr

Treat the field names inside each with: block as illustrative rather than a copy-paste spec, the exact parameters a given built-in action accepts (like how quality-gate wants its criteria formatted) are best confirmed against the in-app action reference before you ship a pipeline built on this shape.

A few things worth calling out in how this works in practice:

Retries are automatic, not manual. If the test gate fails, the pipeline can send the agent back with the failure output and let it try again, up to a limit you set. You're not the one re-prompting after every failed run.

Human-in-the-loop pauses are a gate, not an afterthought. You can require a person to approve before merge regardless of whether the automated gates passed. This matters for changes touching sensitive paths, even when every check is green.

State persists across the pipeline. If a gate fails and the pipeline pauses for review, that state is durable and resumable, you're not restarting the whole run because a check failed at 6pm and nobody was around to look at it.

The plan is reviewable before execution, not just the diff after. Because you can inspect what an agent intends to do before code gets written, some issues get caught before they'd even reach a gate. How to Review an AI Agent's Plan Before It Writes Code has a working rubric for that earlier checkpoint.

Getting Started

Don't design a ten-step pipeline before running a single task. Start with one gate, tests passing, on the task type you run most often. Watch what fails and why for a week. Add the next gate based on what actually slipped through, not what seems theoretically risky.

If you're running agents one at a time in a terminal right now, this is the point where a single-session tool starts to feel limiting: no reusable pipeline definition, no way to fan out the same gated workflow across parallel tasks. Unstoppable Code's YAML pipelines exist for exactly this, defined once, reused across every isolated worktree you spin up, with the gates enforced the same way every time. How to Supervise AI Coding Agents: Isolation, Plan Review, and Parallel Workflows covers how this pillar fits with the other two, and How to Orchestrate AI Coding Agents Across Multiple Repos covers reusing the same pipeline when a task spans more than one repository.