Skip to content
← Knowledge baseAI in engineering · change control

AI agent in code: five gates before any production change

An AI agent can rapidly pinpoint files, generate patches, and run checks. That does not mean it should ever merge or deploy directly to production autonomously.

Tomasz Duda reviews AI agent code changes prior to deployment.
Author: Tomasz Duda8 min read

I never evaluate an AI agent by how many files it touched. What matters is whether it produced a verified change, provided verifiable evidence, and paused exactly where an engineer must make the call.

A disciplined workflow prevents two extremes: tedious manual execution of every repetitive step, and dangerous unconstrained agent access to live systems. NIST SSDF highlights the necessity of embedding security controls across the entire software development lifecycle. For high-velocity teams, five concrete gates create that safety net.

Five gates for an agent-authored change

  1. Bounded scope: the task articulates a single objective, architectural constraints, target files or modules, and exact acceptance criteria.
  2. Branch isolation: the agent works in an isolated Git branch or disposable workspace, never directly on production environments.
  3. Automated verification: the agent runs the build, test suite, and typecheckers. Results are recorded as hard evidence, never assumed on faith.
  4. Human code review: a qualified engineer inspects the diff, edge cases, permission boundaries, and error handling.
  5. Controlled release: integration and deployment follow standard CI/CD pipelines with deterministic rollback procedures and clear accountability.
flowchart LR
  B[Brief
scope + acceptance criteria] --> W[Working branch
no production access]
  W --> A[Agent prepares changes]
  A --> V{Build & checks
pass?}
  V -->|no| R[Fix or abort]
  R --> A
  V -->|yes| H{Human code review
& sign-off?}
  H -->|no| R
  H -->|yes| P[Controlled deployment]
  P --> O[Observability + rollback ready]
  classDef focus fill:#103844,stroke:#18d5e7,color:#f4fbfc,stroke-width:2px
  classDef decision fill:#172733,stroke:#91dfe2,color:#f4fbfc
  classDef work fill:#0b1d27,stroke:#7396a1,color:#edf5f6
  class H,P focus
  class V decision
  class B,W,A,R,O work
An agent can iterate rapidly on patches, but the production gateway remains strictly locked behind verified human approval.

In brief: task brief → isolated branch → agent change → automated verification → human review → controlled release and observability.

Least privilege for autonomous tools

If the task is updating a landing page headline, the agent does not require access to your production customer database. If it is debugging a unit test, it does not need deployment credentials. The same rule applies to file system paths, tools, API secrets, and environments.

Assign granular capabilities per task, set deterministic timeout limits, and audit all tool invocations. Treat external documents, issues, and chat inputs as untrusted data rather than system-level commands. OWASP specifically warns against prompt injection vulnerabilities and excessive agency in autonomous agent architectures.

Tests must match the scope of change

Not every fix requires an identical test battery. A modification to payment processing logic demands rigorous regression tests, while copy adjustments need visual verification and layout checks. For business-critical paths, keep a straightforward test scenario: inputs, expected outputs, boundary conditions, and explicit error states.

If a legacy project lacks an automated test suite, begin with modest baselines: successful compilation, checking target routes, and an explicit checklist for the human reviewer. Over time, these manual checks should be codified into automated test scripts.

What to measure after deployment

  • percentage of agent changes passing automated gates on first attempt;
  • number of revisions returned from human review and specific root causes;
  • velocity trend from task initiation to verified production release;
  • post-release regression rate and time-to-rollback;
  • least-privilege audit verifying agent permissions remained strictly bounded.

Use these metrics to refine workflow mechanics, not to judge engineering personnel. When an agent repeats a mistake, improve the prompt specification, add regression tests, or tighten tool boundaries.

How to start in your company

Begin with a small, low-risk task, such as updating documentation or fixing a minor test in an isolated branch. Document what the agent may read and modify, execute verification checks, and conduct an engineering review. Never inject production secrets into an agent environment simply to rush an internal demo.

Sources and further reading

This framework describes software engineering governance and does not constitute a warranty of security or an endorsement of specific vendor tools.

Press Escape to close