If agents can write code faster than my team can review it, how do we keep up?

Summary

• Treat this as a throughput problem. Shrink what a person must read, automate the first pass, and gate the risky actions, instead of trying to read every line.
• Split agent work into small pull requests, run tests and linters in CI, and add an AI reviewer from a different vendor for a first pass. A person still approves the merge.
• Send high-stakes changes, such as authentication, security policy, financial logic, and data deletion, to mandatory human review. Let low-risk changes pass automated checks.
• On Databricks, Unity Gateway service policies (Beta) can require approval before an agent pushes code through an MCP service, and can block GitHub write tools for read-only agents. Unity Gateway also reports how much coding-agent activity you have.
• Genie Code's auto-approve is "a productivity feature, not a security boundary", so keep it off on production data.

If agents can write code faster than my team can review it, how do we keep up?

Do not try to read everything. Reduce what reaches a person, automate the first pass, and put approval gates on the actions that can do damage. Then spend human attention on the changes where a mistake is expensive.

Which strategies reduce the review load?

Strategy	What it does	What the docs describe
Small, separate pull requests	Keeps each diff reviewable	Omnigent's /fanout runs independent tasks in parallel, each with its own git worktree and sub-agent, and each opens its own pull request
Automated first pass	Runs tests and checks before a person reads	Declarative Automation Bundles bring testing and CI/CD to data and AI projects
Cross-vendor AI review	A second agent reviews each diff	Omnigent's /cross-review sends a diff to a different-vendor reviewer, and blocking issues loop back as fixes until clean
Approval gates	Pauses a risky action until a person agrees	Unity Gateway service policies (Beta) can return ASK on an MCP tool call
Least privilege	Limits what an agent can reach	Unity Catalog grants, EXECUTE on MCP services, tool selection, and the GitHub "Disallow writes" policy
Measurement	Shows how much agent activity there is	The Unity Gateway usage dashboard and system.ai_gateway.usage

For the CI step, Claude Code documents a GitHub Action (anthropics/claude-code-action) and Codex documents openai/codex-action. Omnigent is marked alpha in its repository and is in Beta on Databricks. Its Polly agent never merges, so the human decides.

How do I measure how much agent-written code there is?

The built-in Unity Gateway usage dashboard has a Coding Agents tab that shows metrics such as active days, coding sessions, commits, and lines of code added or removed. An account admin creates the dashboard from the Govern menu. For your own analysis, system.ai_gateway.usage carries session_metadata.coding_agent and session_metadata.client_session_id:

SELECT date_trunc('DAY', event_time) AS day,
       session_metadata.coding_agent AS coding_agent,
       COUNT(DISTINCT session_metadata.client_session_id) AS sessions
FROM system.ai_gateway.usage
WHERE service_type = 'MODEL_SERVICE'
GROUP BY 1, 2
ORDER BY 1 DESC;

Use the trend to size review capacity against agent activity.

How do I put approval gates on risky agent actions?

Service policies let you set guardrails on an agent's activity. They are in Beta and need the Unity Gateway beta features enabled. The docs note that an agent inherits everything the user can access, and give this example: require user consent before an agent pushes code to a Git repository through an MCP service. On an MCP service, an ASK decision pauses the request for user approval before the tool runs. Policies fail closed, so an error results in a deny.
For agents that only read, the built-in GitHub policy has a "Disallow writes" option. It blocks tools that create, modify, or delete data on GitHub while allowing read-only tools.
In Genie Code, pick the approval option that fits the risk: Ask every time, Allow in current chat, Always allow, or Auto-approve. The docs say not to rely on auto-approve for security, compliance, or access-control requirements, and to keep it off for production data and sensitive workspaces.

What should stay with people?

Keep a person on the high-stakes path: changes to authentication logic, security policies, financial calculations, and data deletion. Route those to mandatory human review no matter how much lower-risk code you automate.

FAQs

Can agents review each other's code?

Yes. Omnigent's /cross-review skill sends an implementer's diff to a reviewer from a different vendor. Use it for a first pass, not as the final approver.

How do I tune guardrails without blocking people?

Run a service policy in Log mode first. It is non-enforcing and records what the policy would have decided without blocking the interaction, so you can review its decisions before you enforce it.

What if code passes every check but has a logic bug?

Tests only catch what they encode. Add a regression test for every bug that escapes, and promote agent-written changes through staging before production.