A mid-market SaaS company -200 engineers, 18 teams, monorepo with 2.4 million lines of TypeScript -adopted AI coding agents in January 2026. By March, their PR review queue had doubled. Not because engineers were writing more features. Because agents were generating more code, and every line still needed human review.

The review bottleneck was eating their productivity gain. They needed an AI code review tool that caught issues before PRs were opened, not after.

The problem: AI code review bandwidth

Before agents, their average PR had 120 lines changed. After agents, it jumped to 340. The code was generally correct -it compiled, passed tests, and handled the obvious edge cases. But reviewers were still catching issues in roughly one out of every three agent-generated PRs:

  • Wrong error handling pattern (their codebase had three historical patterns; agents picked whichever appeared first in the context window)
  • New utility functions that duplicated existing ones in their shared package
  • Direct Prisma calls from API route handlers instead of going through the service layer
  • Missing correlation IDs in log statements
  • Using deprecated internal APIs that still existed but were slated for removal

None of these were bugs. Tests passed. The code worked. But each violation created tech debt and eroded AI code consistency across the codebase. Without rules to prevent AI code drift, reviewers spent 45 minutes per agent-generated PR on average -longer than human-written PRs -because the code looked right and the issues were subtle.

What they tried first

More linting rules. They added 14 custom ESLint rules over two weeks. These caught some issues -direct Prisma imports, deprecated API usage -but couldn't express higher-level patterns like "service layer must be used for business logic." The rules also generated false positives that annoyed developers. After a month, three of the 14 rules had been disabled.

Review guidelines document. They wrote a 12-page review checklist for agent-generated code. Reviewers were supposed to verify each item. Nobody read past page two. The checklist became shelfware within two weeks.

Dedicated agent-code reviewers. They assigned two senior engineers to review all agent-generated PRs. This created a bottleneck worse than the original problem. The two engineers were reviewing 30+ PRs per day and burning out.

AI code governance: the approach that worked

In April, they set up Uzera with 23 governance rules. Not 100. Not 50. Twenty-three rules that captured their most common agent violations. They spent one afternoon writing them.

The rules fell into four categories:

Architecture boundaries (7 rules)

API routes can only call service layer methods. Services can only access data through repositories. No direct ORM calls from controllers. No cross-domain imports without going through the public API of each domain. These rules encoded the layered architecture that agents consistently violated.

Pattern enforcement (6 rules)

Error handling must use their AppError class hierarchy. Log statements must include correlationId. API responses must use the ResponseEnvelope wrapper. Database queries with user input must use parameterized queries through their query builder -not string interpolation.

Duplication prevention (5 rules)

Before creating a new utility function, check the shared package. Before adding a new type definition, check the types package. Before implementing a new validation pattern, check the validators directory. These rules referenced specific paths in the codebase where shared code lived.

Deprecation guards (5 rules)

Don't import from @internal/legacy-auth. Don't use the v1 event bus -use v2. Don't create new REST endpoints in the old router format. These were the simplest rules but caught the most frequent violations.

AI code consistency: results after 8 weeks

They tracked results before and after:

Review time per agent-generated PR: Dropped from 45 minutes to 18 minutes. Reviewers stopped finding architectural violations because the governance layer caught them before the PR was opened. Reviews focused on business logic and design -the things humans are actually good at evaluating.

Agent-generated PR rejection rate: Dropped from 31% to 8%. The remaining 8% were genuine design disagreements, not pattern violations. These are the conversations worth having.

Time from agent output to merged code: Dropped from 2.3 days to 0.8 days. PRs moved through the pipeline faster because there were fewer review round-trips.

The combined effect: 60% reduction in total review time spent on agent-generated code. As an AI code review tool integrated into the authoring workflow, governance rules proved far more effective than post-hoc review. Their two dedicated reviewers went back to feature work. The PR queue returned to pre-agent levels despite 3x more code being generated.

What surprised them

Agents got better over time. Because governance rules provided specific feedback when code was rejected, agents learned which patterns to follow. After two weeks, the same agents were producing code that passed governance checks on the first attempt 85% of the time. The rules acted as training data for the agent's context.

Human-written code improved too. Junior developers started following the same patterns because the governance rules made the architectural expectations explicit. The rules document that nobody read became a living system that people interacted with every day.

Rule count stayed low. They expected to keep adding rules. After eight weeks, they had 26 rules -only three more than the initial set. Most agent violations fell into patterns already covered. The 80/20 rule applied: 23 rules covered 90% of issues.

What actually moved the needle

The team didn't slow down agent usage. They didn't add more reviewers. They didn't write longer checklists. They used AI developer tools for teams that enforce coding standards at authoring time -encoding their existing standards as machine-readable rules and letting the governance layer handle enforcement.

The math is simple: 200 engineers, averaging 4 agent-generated PRs per week each, saving 27 minutes of review time per PR. That's 360 hours of senior engineering time recovered per week. Not by writing less code -by making the code right before it reaches review.