The AI Coding Agent Problem: Governance When AI Writes 60% of Your Code

It's Thursday morning. Your engineering manager opens the PR dashboard and sees 47 open pull requests. Yesterday there were 12. The team didn't grow overnight. Nobody hired contractors. What happened is simpler and more disruptive: three engineers started using Cursor with agent mode on Monday, two others onboarded Copilot Workspace, and one team lead got access to Devin. Your 12-person team is now producing code at the rate of 50 developers, and your review process is drowning.

This is already happening across engineering organizations. GitHub reported that Copilot generated 46% of code in files where it was enabled as of 2024 [1]. Cursor's agent mode and Devin take this further by writing entire features, not just autocompleting lines. The throughput looks fantastic in your sprint metrics. The danger is what those metrics hide.

I've watched three teams go through this transition over the past six months. The pattern is consistent: velocity spikes, dashboards turn green, and then four to eight weeks later, someone discovers that the codebase has quietly fractured into incompatible patterns that will take months to untangle.

Your Team Didn't Hire 50 Junior Developers, But It Feels Like It

The analogy is imperfect but useful. AI coding agents are like eager junior developers who write fast, pass tests, and never ask about your architectural decisions. They don't read your ADRs. They don't know that you standardized on the repository pattern in the data layer or that your team uses structured logging with correlation IDs. They just produce code that works.

The false comfort of high velocity is real. When your cycle time drops and PRs per developer triple, leadership sees progress. But throughput and quality are not the same measurement. A team I worked with saw their PR count go from 8 per day to 34 per day after adopting Cursor's agent mode. Their deployment frequency doubled. Six weeks later, they discovered that agent-generated services were using three different HTTP client libraries, two conflicting error handling patterns, and a mix of snake_case and camelCase that had crept into their previously consistent Python codebase.

The fundamental mismatch is arithmetic. AI agents generate code at machine speed. Humans review at human speed. If each of your 12 engineers produces 6 to 8 agent-assisted PRs per day instead of 2, you need 72 to 96 reviews daily. Even with a generous 15 minutes per review, that's 18 to 24 hours of pure review time. Per day. For a team of 12. The queue doesn't just grow. It compounds.

What Agent-Generated Code Actually Looks Like in Production

Let me show you what I mean by "technically correct but architecturally inconsistent." Here's a service method a Cursor agent generated for a team using a clean architecture pattern:

# Agent-generated: direct database query in the service layer
class OrderService:
    def get_order(self, order_id: str) -> Order:
        conn = psycopg2.connect(DATABASE_URL)
        cursor = conn.cursor()
        cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))
        row = cursor.fetchone()
        conn.close()
        return Order(**dict(zip(ORDER_COLUMNS, row)))

The team's actual convention uses a repository pattern with dependency injection:

# Team convention: repository pattern with injected dependencies
class OrderService:
    def __init__(self, order_repo: OrderRepository):
        self._order_repo = order_repo

    def get_order(self, order_id: str) -> Order:
        return self._order_repo.find_by_id(order_id)

Both work. Both pass tests. But the agent-generated version bypasses the repository layer, creates its own database connection (hello, second connection pool), and embeds raw SQL in the service layer. No linter catches this. SonarQube won't flag it. Semgrep's security rules don't care about architectural layering. It's a correctness problem that no existing SAST tool is designed to detect.

This is the copy-paste amplification problem. Agents reproduce patterns from training data that may contradict your team's conventions. One team reported that a Cursor-generated service ran in production for three sprints before anyone noticed it had introduced its own connection pool alongside the team's SQLAlchemy session factory. The discovery only happened during a database connection exhaustion incident at 2am.

The Three Failure Modes of Ungoverned AI Code

Through working with teams adopting AI agents, I've identified three distinct failure modes that repeat across organizations.

Architectural drift is the most insidious. Each agent session lacks memory of your system's intended design. Over weeks, agents produce working code that slowly diverges from the planned architecture. Module boundaries blur. Services that should be independent start sharing data structures directly. The system still works, but its maintainability degrades with every merged PR.

Dependency sprawl happens because agents reach for whatever library their training data suggests. One team discovered that agent-authored code had introduced 14 new npm packages in a single sprint, including three different date-handling libraries (moment, date-fns, and dayjs) when the team had standardized on date-fns. Each new dependency is a supply chain risk surface and a maintenance burden.

Convention erosion is the death of readability by a thousand cuts. Naming patterns fracture. Error handling strategies diverge (some agent code throws, some returns Result types, some uses error codes). Logging formats split between structured JSON and unstructured strings. Teams frequently report that 40 to 60 percent of agent-generated PRs require non-trivial rework when no governance guardrails exist.

Building a Governance Layer That Runs at Agent Speed

The core principle is non-negotiable: governance checks must be automated and execute fast. If your policy gates take 10 minutes, engineers will skip them or find workarounds. Target under 90 seconds for the full pre-merge check suite.

Layer 1: Pre-Commit Policy Gates

These catch violations before code reaches the review queue. Architectural boundary checks verify that code in services/ doesn't import directly from infrastructure/. Dependency allowlists reject PRs that introduce packages not on the approved list. Naming convention enforcement uses custom rules in tools like Semgrep or ast-grep to verify patterns.

# .governance/agent-policy.yaml
rules:
  dependency_allowlist:
    enforce: true
    approved_packages_file: ./approved-dependencies.txt
    action_on_violation: block_merge

  architecture_boundaries:
    enforce: true
    rules:
      - from: "src/services/**"
        deny_imports_from: "src/infrastructure/**"
      - from: "src/domain/**"
        deny_imports_from: "src/services/**"

  naming_conventions:
    enforce: true
    patterns:
      python_variables: snake_case
      typescript_interfaces: PascalCase
      api_endpoints: kebab-case

Layer 2: Automated Review of Agent Code

This is where an AI reviewer reviews agent-generated code. SlopBuster, for example, can analyze Cursor or Copilot output specifically for convention violations, flagging architectural boundary crossings and pattern inconsistencies before human reviewers spend time on the PR. The human reviewer then focuses on business logic correctness and design decisions, not catching style violations.

Layer 3: Post-Merge Drift Detection

Even with pre-commit gates, cumulative small changes can shift module boundaries over time. Weekly automated scans that compare the current architecture graph against the intended design surface gradual drift before it becomes a rewrite.

Agent Identity: Tracking Who (or What) Wrote Every Line

Git blame is broken in the age of AI agents. When a developer uses Cursor to generate a 200-line service, the commit shows their name. There's no attribution trail distinguishing human-authored code from agent-generated code. This matters for three reasons: quality tracking, audit compliance, and rework analysis.

Implementing agent provenance starts with your PR template. Add metadata fields that capture the originating tool, the prompt or task description, and the percentage of code the developer estimates was agent-generated.

## PR Metadata
- **Agent Used**: Cursor Agent Mode / Copilot Workspace / Devin / None
- **Agent Contribution**: ~80% generated, ~20% manually modified
- **Session Context**: "Generate CRUD endpoints for inventory service"

This provenance data becomes powerful when fed into an engineering intelligence dashboard. You can answer questions like: "Which agent produces the most rework-prone code?" and "Are Devin-generated PRs taking longer to pass review than Copilot PRs?" The JetBrains 2024 Developer Survey found that 77% of developers now use AI assistants [3], but almost no teams track which assistant generated which code.

The compliance angle is real and growing. SOC 2 auditors are beginning to ask about AI-authored code lineage. ISO 27001 control A.8.25 (secure development lifecycle) requires organizations to account for how software is produced. If 60% of your code is agent-generated and you can't demonstrate provenance, you have an audit gap.

The Human Review Bottleneck (and How to Fix It Without Removing Humans)

The math is unforgiving. If 12 engineers each produce 8 agent-assisted PRs per day, you need 96 reviews daily. You can't hire your way out of this. The solution is risk-based routing that matches review effort to actual risk.

Risk scoring for agent PRs considers three factors: files touched (auth, payments, and data models score high), complexity delta (large additions to previously stable modules), and proximity to sensitive code paths.

Here's a GitHub Actions snippet for risk-based routing:

# .github/workflows/pr-risk-router.yml
name: Agent PR Risk Router
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Score PR risk
        id: risk
        run: |
          HIGH_RISK_PATHS="auth/ payments/ migrations/ models/"
          TOUCHED=$(gh pr diff ${{ github.event.number }} --name-only)
          RISK="low"
          for path in $HIGH_RISK_PATHS; do
            if echo "$TOUCHED" | grep -q "$path"; then
              RISK="high"
              break
            fi
          done
          echo "level=$RISK" >> $GITHUB_OUTPUT
      - name: Apply review requirements
        if: steps.risk.outputs.level == 'high'
        run: |
          gh pr edit ${{ github.event.number }} \
            --add-label "requires-arch-review" \
            --add-reviewer "security-team"

Teams using automated pre-review tools like SlopBuster report reducing human review load by roughly 60% while catching more convention and architectural issues than manual review alone. The automated reviewer handles pattern matching, convention checks, and dependency validation. Humans focus on the judgment calls that require business context.

Measuring Governance Effectiveness: Four Metrics That Matter

You can't manage what you don't measure, and most teams don't measure agent code quality at all. Here are four metrics worth tracking.

Agent rework rate is the percentage of agent-authored PRs requiring follow-up commits within 5 business days. This directly measures how much agent output needs correction. Track this weekly. A healthy target is under 15%. The 2024 DORA report emphasizes that rework metrics are among the strongest predictors of overall delivery performance [4].

Convention compliance score is an automated scan of agent code against your team's style and architecture rules. Run ast-grep or custom Semgrep rules against every agent PR and express results as a percentage. Below 85% means your policy gates have gaps.

Review queue depth and age tracks how many agent PRs are waiting and for how long. If your median review wait time exceeds 4 hours, your governance is creating a bottleneck rather than preventing problems. The DORA research consistently shows that fast feedback cycles correlate with both higher quality and higher throughput [4].

Dependency introduction rate counts new third-party packages added per sprint, segmented by agent-authored versus human-authored. This metric catches dependency sprawl early. The Snyk 2024 State of Open Source Security report found that the average JavaScript project already has 170 dependencies [5], and uncontrolled agent additions can push this number dramatically higher.

Engineering intelligence dashboards can surface these metrics in real time rather than waiting for quarterly retrospectives. When you can see that Cursor-generated PRs have a 32% rework rate while Copilot-generated PRs sit at 11%, you can adjust your governance rules and agent configurations accordingly.

Start Governing This Week, Not Next Quarter

Governance frameworks don't need to be perfect on day one. They need to exist. Here are three actions you can take this week.

Action 1: Add agent provenance metadata to your PR template today. This is a 15-minute change. Edit your .github/PULL_REQUEST_TEMPLATE.md to include agent attribution fields. Even if the data is self-reported, you start building the dataset that informs every future governance decision. GitHub's documentation on PR templates makes this straightforward [6].

Action 2: Create a dependency allowlist and enforce it in CI before Friday. Export your current package.json or requirements.txt as the baseline. Write a CI check that fails when a PR introduces a package not on the list. This single gate prevents the dependency sprawl problem immediately.

Action 3: Set up a weekly agent code quality review. Block 30 minutes each Thursday. The team examines 5 random agent-authored PRs merged that week, looking specifically for pattern drift, convention violations, and architectural boundary crossings. This builds institutional awareness of what agents get wrong and informs your automated rules.

Remember that Thursday morning with 47 open PRs? Those AI coding agents aren't going away. Adoption is accelerating: the Stack Overflow 2024 Developer Survey found that 76% of developers are using or planning to use AI tools in their development process [7]. The question isn't whether your team will produce code at machine speed. The question is whether you'll build the governance system that keeps that speed productive rather than destructive.

Start with provenance tagging today. Add the dependency allowlist by Friday. Run your first agent code review next Thursday. In four weeks, you'll have the data to build the automated governance layer that actually matches the pace your agents set.

References

[1] GitHub, "GitHub Copilot: The AI Pair Programmer," 2024. https://github.com/features/copilot

[2] GitClear, "Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality," 2024. https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality

[3] JetBrains, "The State of Developer Ecosystem 2024," 2024. https://www.jetbrains.com/lp/devecosystem-2024/

[4] DORA Team, "2024 Accelerate State of DevOps Report," Google Cloud, 2024. https://dora.dev/research/

[5] Snyk, "State of Open Source Security 2024," 2024. https://snyk.io/reports/open-source-security/

[6] GitHub, "Creating a Pull Request Template for Your Repository," GitHub Docs, 2024. https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests

[7] Stack Overflow, "2024 Developer Survey," 2024. https://survey.stackoverflow.co/2024/