AI Code Governance: A Practical Framework for Engineering Teams

Picture this: you are the engineering lead who catches the problem at 11pm on a Thursday. A junior developer merged a 2,400-line pull request. Your static analysis tools passed it. Your security scanner gave it a green check. The code compiled, tests passed, and it shipped to production. Three weeks later, your compliance team discovers AI-generated authentication logic that exposes customer records. The breach notification and the regulatory questions follow. The developer says they "just used Copilot for the boilerplate stuff."

The governance question is whether an organization can explain which systems fall under which rules and show the controls used to review their changes. The EU AI Act applies different obligations and dates to different categories of AI systems, including transparency rules and high-risk systems ^[2][3]. Engineering teams need evidence tied to the actual system, its use, and the applicable obligation.

Traditional code review was built for human-authored code, and it struggles with AI-generated code because its assumptions no longer hold. Reviewers expect intentionality. AI code has statistical plausibility instead. Reviewers look for patterns they recognize. AI can introduce vulnerability patterns your SAST rules were not written for. Reviewers trust their colleagues. Nobody knows which parts of the PR came from a human and which came from an LLM agent that hallucinated a crypto library.

The Shadow AI Governance Gap

Shadow AI usage is not a future risk. It is a current liability. Reporting on IBM's 2025 Cost of a Data Breach study, Cybersecurity Dive found that breaches at organizations with high levels of shadow AI "cost an average of $670,000 more than breaches at firms with little or no shadow AI" ^[1]. That figure covers the breach itself, not the engineering time spent unwinding AI-generated technical debt.

AI-generated code also carries more issues into review. In CodeRabbit's analysis of 470 open-source pull requests, AI-co-authored changes produced 10.83 issues per PR against 6.45 for human-only PRs, about 1.7x more, with about 75% more logic and correctness issues ^[4]. GitClear projected that code churn, lines reverted or updated less than two weeks after being written, would double in 2024 against its 2021 pre-AI baseline ^[5].

Engineering metrics built on repository metadata track PR cycle times and deployment frequency. They tell you how fast code moves. On their own, they do not tell you whether that code came from a human or a machine, which repositories lean heavily on AI-generated code, or which team is quietly using an agent to rewrite entire modules without documentation. They show the symptom (longer review cycles, more reverts) but not the cause (ungoverned AI adoption).

Reviewers also lack confidence in AI-generated pull requests. In the 2025 Stack Overflow Developer Survey, more developers distrusted the accuracy of AI output (46%) than trusted it (33%) ^[6]. When reviewers do not know what was human-crafted versus machine-suggested, they hedge. They request changes they would not normally request. They defer to a second reviewer. The merge gate becomes a bottleneck, and teams respond by disabling review requirements or rubber-stamping approvals to hit sprint commitments.

That is how authentication logic with hallucinated crypto patterns makes it to production.

Why Traditional Code Review Cannot Govern AI-Generated Code

Your existing code review process was designed for a world where every line of code had a human author who made intentional choices. That world no longer exists.

Consider how traditional SAST tools work. They pattern-match against known vulnerability signatures and are good at the classes they have rules for: SQL injection, XSS, insecure deserialization, and hardcoded credentials. They are not complete. In one empirical study of five static analysis tools, their combined warnings flagged 78% of vulnerability-contributing commits, which means about a fifth went undetected ^[7]. Rules also lag behind new patterns, such as an LLM agent that hallucinates a database query builder or invents a JWT validation function that looks correct but bypasses signature checks in edge cases.

Some vendors now add LLM-based post-processing to signature detection to filter out false positives. Measure the false positive rate on your own codebase before you rely on it, because noisy findings train high-velocity teams to ignore the scanner.

The fundamental problem is that AI-generated code looks correct. It compiles. It passes unit tests. It follows naming conventions. It does not have obvious red flags like TODO: fix security issue comments. The bugs are semantic. The vulnerabilities are emergent. The technical debt accumulates through thousands of micro-decisions that optimize for "code that looks like Stack Overflow examples" rather than "code that handles production edge cases."

Here is what breaks:

Human reviewers assume intentionality. When they see a conditional branch, they assume the developer thought through why that branch exists. AI code has statistical plausibility instead. The branch exists because similar code in the training data had a branch there. It might handle an edge case. It might introduce a bug. The reviewer cannot know without deep investigation, which is why change size matters: SmartBear advises reviewing "no more than 200 to 400 lines of code (LOC) at a time" ^[8].

Static analysis tools miss context. Traditional SAST tools scan for patterns like eval(user_input) or SELECT * FROM users WHERE id = ${req.params.id}. AI-generated code is more sophisticated. It uses parameterized queries. It avoids obvious injection vectors. But it might construct the SQL dynamically from multiple user inputs in a way that creates a second-order injection risk that only appears in production when specific rate-limiting logic is triggered. Your SAST tool gives it a clean bill of health.

Code review bottlenecks create perverse incentives. Reviewers who lack confidence in AI-generated PRs slow down. Teams respond by splitting work to avoid AI-heavy PRs, hiding AI usage to bypass extra scrutiny, or escalating approval authority to senior engineers who become bottlenecks. The governance process creates friction, so teams route around it.

You cannot solve this with more human reviewers. You need a governance framework that understands AI-generated code as a distinct category with different risk profiles, different review requirements, and different merge gate policies.

What Agent Drift Looks Like in a Pull Request

Coding agents write code that works without knowing your architecture. They do not read your architecture decision records, and each session starts without memory of the conventions your team agreed on. Here is a service method of the kind an agent produces for a team that uses a repository pattern in its data layer:

# 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 convention injects a repository instead:

# 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 versions work, and both pass tests. The agent version bypasses the repository layer, opens its own database connection outside the team's connection pool, and puts raw SQL in the service layer. A formatter has nothing to fix, and injection rules have nothing to report because the query is parameterized. The defect is architectural, so it needs an explicit rule rather than a reviewer who happens to remember the convention.

The same gap shows up in three ways:

- Architectural drift. Module boundaries blur one working pull request at a time. Services that should be independent start sharing data structures directly, and the system gets harder to change with every merge.

- Dependency sprawl. Agents reach for whichever library their training data favors, so a codebase that standardized on one date or HTTP library can quietly gain two more. Each new package adds supply chain exposure and maintenance work.

- Convention erosion. Error handling splits between exceptions, result types, and error codes. Logging splits between structured and unstructured formats. Naming patterns fracture.

Each of these can be written down as a rule that runs before review. The illustrative policy file below declares a dependency allowlist, the import boundaries between layers, and naming conventions, and blocks the merge on a violation. Custom Semgrep or ast-grep rules can enforce the boundaries and naming patterns, and a CI step can compare newly added packages against an allowlist exported from your current package.json or requirements.txt.

# .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

These rules run in the first two layers of the stack below, so the mistakes agents make most often are caught before a human opens the pull request.

The Three-Layer Governance Stack

The solution is not "review AI code harder." The solution is a three-layer governance stack that separates mechanical checks from semantic analysis from risk-based approval gates.

Layer 1: Linting and formatting (table stakes). This is automated enforcement with zero human overhead. ESLint, Prettier, Black, gofmt, rustfmt, whatever matches your language. AI-generated code must pass the same style guides as human code. This layer catches formatting inconsistencies, unused imports, and obvious syntax errors. It runs pre-commit and blocks merge if it fails. No exceptions.

Layer 2: SAST/DAST security and code smell detection. This is where SonarQube, Snyk, Semgrep, and traditional static analysis tools operate. They catch known vulnerability patterns, code smells, complexity hotspots, and test coverage gaps. Some tools in this layer combine signature-based detection with LLM post-processing to reduce false positives. This layer runs in CI/CD and generates blocking findings for high-severity issues.

Layer 3: AI-powered semantic review. This is the frontier. Layer 3 tools analyze code for contextual correctness, maintainability, and emerging AI-generated code patterns that traditional SAST tools miss. They answer questions like "Does this error handling logic actually handle all the error cases from the upstream API?" and "Is this database query pattern safe under concurrent access?" and "Does this AI-generated authentication flow match our documented security requirements?"

The key insight: each layer operates independently and generates its own pass/fail signal. A PR must pass all three layers to reach human review. Human reviewers then focus on business logic, architectural fit, and compliance documentation, not hunting for missing semicolons or SQL injection risks.

Here is how this maps to real tools. Layer 1 is GitHub Actions workflows, GitLab CI/CD pipelines, or pre-commit hooks running formatters and linters. Layer 2 is SonarQube for code smells and complexity metrics, Snyk for dependency vulnerabilities, Semgrep for custom security rules, and CodeQL for semantic code analysis. Layer 3 is where SlopBuster, CodeRabbit, and similar AI code review tools operate, providing contextual analysis that goes beyond pattern matching.

The automation removes review friction for mechanical issues, allowing human reviewers to focus on the semantic and architectural concerns that actually matter.

Multi-Agent Validation Chains: The Production Pattern

The most effective governance pattern for AI-generated code is not "review harder." It is "generate with validation gates baked in."

Multi-agent validation chains work like this: one agent writes code, one critiques for maintainability, one tests edge cases, one validates compliance requirements. Each agent has defined capabilities, token limits, and input/output contracts. The code does not advance to the next stage until the previous agent gives explicit approval. This is not sequential review. This is adversarial generation with validation gates.

The pattern works because it forces AI code generation to address the same concerns a human reviewer would check (readability, testability, security, compliance) before the code ever reaches a pull request.

The emerging standard is what we call an Agent Manifest: a structured specification that defines each agent's capabilities (what it can read, write, and execute), token limits (how much context it can process), input/output contracts (what data structures it consumes and produces), and reliability signals (how to detect when it is hallucinating or stuck). Think of it like an API specification, but for AI agents. Documenting Agent Manifests for production multi-agent workflows gives auditors and incident responders a written record of what each agent was allowed to do.

Multi-agent orchestrations face the same problems as any distributed system: node failures, network partitions, message loss, and cascading errors. An agent that writes code might timeout. An agent that validates compliance might return incomplete results due to rate limits. An agent that generates tests might get stuck in a loop. Your governance framework needs circuit breakers, retry logic, and fallback paths, the same patterns you use for microservices.

The debate between self-organization (agents coordinate autonomously) versus orchestration (a controller directs agent actions) mirrors the microservices versus service mesh debate from five years ago. Self-organization works for exploratory tasks with evaluation gates, researching a design pattern, prototyping a feature, generating test cases. Orchestration works for customer-facing flows requiring repeatability and auditability, processing a compliance review, generating audit documentation, deploying to production. Most production systems use both: self-organization for generation, orchestration for validation and approval.

The Model Context Protocol is "an open-source standard for connecting AI applications to external systems," supported by assistants such as Claude and ChatGPT and by development tools including Visual Studio Code and Cursor ^[9]. Because many assistants connect to data and tools through the same protocol, it is a natural place to standardize which systems agents may reach; whether you can inspect or audit those interactions depends on the clients and servers you deploy.

Merge Gate Policies That Actually Work

Governance without enforcement is aspiration. Here are the merge gate policies that stop ungoverned AI code from reaching production. The AI-share thresholds below are example values to tune. Any policy keyed on an AI share depends on estimated attribution (declared in the PR template or reported by tool telemetry), so treat that estimate as a lead rather than proof:

Automatic rejection for high-severity findings in AI-generated code. Any PR where AI-generated code comprises 15%+ of the changeset and contains high-severity security findings or unresolved complexity warnings gets automatically rejected. No human review. No appeals. The code goes back to the developer with specific remediation tasks. This hard gate forces developers to validate AI-generated code before submission.

Mandatory second human reviewer for high-AI-percentage PRs. Any PR where AI-generated code exceeds 40% of the total changeset requires a second human reviewer beyond the standard CODEOWNERS approval. This is not about distrust. This is about risk distribution. CodeRabbit found more issues per PR in AI-co-authored changes ^[4]. The second reviewer specifically focuses on semantic correctness and edge case handling.

Compliance checkpoint for PII, authentication, or financial logic. Any AI-generated code that touches personally identifiable information, authentication flows, or financial transactions requires traceability documentation before merge. The documentation must answer: which tool generated this code, what prompt was used, which human reviewed and approved the output, and which compliance requirements it must satisfy. This documentation becomes part of your audit trail.

Quality threshold enforcement across the board. AI-generated code must pass the same cyclomatic complexity limits, test coverage requirements, and documentation standards as human code. No exceptions. If your team requires 80% test coverage for new code, AI-generated code gets the same bar. If your team limits cyclomatic complexity to 10 per function, AI-generated functions follow the same rule.

Shadow AI detection rules. Flag unapproved tool usage patterns in commit messages, code comments, or generation timing signatures. For example, a commit message that says "Generated with ChatGPT" when ChatGPT is not an approved tool triggers a policy violation. Code comments containing phrases like "AI-generated" or "from Copilot" when those tools are not on your approved list trigger review. Rapid commit timing patterns (hundreds of lines committed in seconds) that suggest copy-paste from an external tool trigger investigation.

These policies work because they are specific, automatable, and enforceable. The gates keyed on AI share are only as good as the attribution behind them, so pair them with the path-based and severity-based gates, which do not depend on it. They do not depend on manual review catching every issue. They create structural barriers that make it harder to merge ungoverned AI code than to follow the governance process.

Route Review Depth by Risk

Merge gates decide whether a pull request may merge. A separate rule decides how much human attention it gets. Score each pull request on the paths it touches, the size of the change to previously stable modules, and how close it sits to sensitive code, then route it to a review tier:

A small workflow can apply the tier automatically. This example assigns one of the four tiers from the changed paths, taking the highest tier any file reaches, and labels the pull request with it. Adjust the path patterns to your layout:

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

permissions:
  contents: read
  pull-requests: write

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - name: Score PR risk
        id: risk
        env:
          GH_TOKEN: ${{ github.token }}
          PR_NUMBER: ${{ github.event.number }}
        run: |
          TOUCHED=$(gh pr diff "$PR_NUMBER" --repo "$GITHUB_REPOSITORY" --name-only)
          RISK=low
          while IFS= read -r file; do
            case "$file" in
              migrations/*|models/*) RISK=critical; break ;;
              auth/*|payments/*) RISK=high ;;
              docs/*|tests/*|config/*|*.md) ;;
              *) if [ "$RISK" = low ]; then RISK=medium; fi ;;
            esac
          done <<< "$TOUCHED"
          echo "level=$RISK" >> "$GITHUB_OUTPUT"
      - name: Label the review tier
        env:
          GH_TOKEN: ${{ github.token }}
          PR_NUMBER: ${{ github.event.number }}
          RISK: ${{ steps.risk.outputs.level }}
        run: gh pr edit "$PR_NUMBER" --repo "$GITHUB_REPOSITORY" --add-label "risk:$RISK"

Create the four risk: labels in the repository first. The label records the tier; it does not enforce it, because a label on its own blocks nothing and branch protection applies one approval count to every pull request. The tier-specific sign-offs come from ownership instead. In CODEOWNERS, assign auth/ and payments/ to your security or compliance team and migrations/ and models/ to your architecture reviewers. Then turn on branch protection that requires approving reviews and requires code owner review, so a high or critical change cannot merge until the owning team approves it ^[10]. That is what this setup enforces: one approval from the owning team. If a tier needs two independent reviewers, raise the required approval count, which branch protection applies to every pull request on the branch, rather than relying on the label. Keep the router's path patterns and the CODEOWNERS paths in step, or the label and the enforced sign-off will drift apart.

Engineering Intelligence Dashboard Requirements

You cannot govern what you cannot measure. Your engineering intelligence dashboard must track AI-generated code as a distinct category with its own metrics, not just aggregate it into overall team productivity numbers.

Track AI-generated code percentage by team, repository, and time period. This is your shadow AI detector. If Team A suddenly shows 60% AI-generated code when the team average is 20%, you have either an approved pilot or an unapproved tool adoption. If Repository B sees AI-code percentage climb from 15% to 45% over two months, you need to understand what changed. Is a new developer relying heavily on Copilot? Did someone start using Cursor without approval? Is an agent autonomously committing code?

Monitor technical debt accumulation velocity. Track code complexity trends, test coverage trends, documentation completeness trends, and static analysis warning trends. If these metrics spike after AI tool adoption, your governance is failing. If they remain stable or improve, your governance is working.

Measure time-to-governance-approval as distinct from time-to-merge. AI-generated PRs should not wait longer simply because reviewers are uncertain. Track how long it takes from PR creation to passing all three governance layers (linting, SAST, AI semantic review) versus how long it takes from governance approval to human review to merge. If governance approval is fast but human review is slow, your reviewers need training on AI code patterns. If governance approval is slow, your tooling needs tuning.

Correlate AI tool usage with defect escape rates. For every merged PR, track which tool generated the code (Copilot, Cursor, Devin, none) and whether it caused a post-deployment incident. Calculate defect escape rates by tool. If Cursor-generated code has a 0.5% incident rate but Copilot-generated code has a 2% incident rate, you have a tool-specific problem. If AI-generated code across all tools has higher incident rates than human code, you have a governance problem.

That correlation needs attribution data, and git history does not record it: a commit written with an agent's help carries the developer's name. The cheapest place to start collecting it is the pull request template. When a repository has one, contributors automatically see its contents in the pull request body ^[11]. Save a section like this in .github/pull_request_template.md:

### AI assistance
- **Tool used**: Cursor agent mode / Copilot / Devin / Claude Code / None
- **What the agent produced**: which files or functions came from the agent, and what was changed by hand
- **Task given to the agent**: one line, such as "Generate CRUD endpoints for the inventory service"

These fields are self-reported context, not a measurement. The share of a diff a model wrote cannot be verified mechanically, so the template asks which parts came from an agent rather than for a percentage, and gates that use it should treat it as an estimate. Treat the tool field as a lead for review and incident triage, not as audit evidence or a basis for comparing teams.

Audit trail visualization showing code provenance. For regulated industries (healthcare, finance, defense), you need to visualize which agent or tool generated which code section, with linkage to compliance documentation. A heat map showing file-level AI code percentage, drill-down capability to see line-by-line attribution, and tags linking code sections to compliance requirements. This turns your audit from "search through six months of Git history" into "click three buttons and export a report."

Your dashboard must support incident response: when an AI-generated bug reaches production, you need to identify every other PR from that tool, that agent, or that time period for proactive review.

Tool Selection: Copilot vs Cursor vs Devin for Governed Environments

Three tools illustrate the governance trade-offs: GitHub Copilot for ecosystem integration, Cursor for AI-native editing, and Devin for autonomous task completion. Check each vendor's current pricing and plan features before you decide.

GitHub Copilot is sold per seat and integrates with GitHub Actions, GitHub Advanced Security, and GitHub audit logs. That integration matters for governance: policy enforcement can live in the same place as the code. The trade-off is that it fits best when your team already standardizes on GitHub.

Cursor is an AI-native editor, also sold per seat, with tab completion and multi-file editing built in, which many developers value for flow and rapid iteration. Governance usually sits outside the editor, so plan for tooling that tracks AI-assisted changes, enforces merge gates, and produces audit reports.

Devin is not a coding assistant. It is an autonomous agent aimed at well-defined tasks such as migrations, refactoring, and dependency updates. It suits well-scoped work with clear acceptance criteria and is a weaker fit for ambiguous requirements or novel architectural decisions, so its output needs the same merge gates as any other change.

A common pattern is hybrid: Cursor or Copilot for editing, Claude Code or Devin for complex tasks, and GitHub Actions or GitLab CI/CD for governance enforcement. This hybrid approach optimizes for developer experience during editing while maintaining centralized governance at merge time.

The governance question is not "which tool is best?" but "can you enforce consistent policies across whatever tools your developers choose?" A shared protocol such as MCP ^[9] helps by standardizing how assistants connect to data and tools, but merge gates in your CI remain the place where policy is actually enforced for every tool.

Your 90-Day Implementation Roadmap

Governance does not happen overnight. Here is the 90-day roadmap that moves you from unauditable to compliance-ready:

Days 1-30: Audit existing AI tool usage. Survey your engineering organization to identify which AI tools are in use (Copilot, Cursor, Claude, ChatGPT, others). Establish baseline metrics for AI-generated code percentage per repository, defect rates, security findings, and review cycle times. Deploy shadow AI detection rules to flag unapproved tool usage patterns. Document your current state: which teams are heavy AI adopters, which repositories have the highest AI code percentage, which tools are used most frequently.

Days 31-60: Implement three-layer governance stack. Deploy automated linting and formatting enforcement (Layer 1). Integrate SAST/DAST security scanning with AI-enhanced post-processing (Layer 2). Pilot AI-powered semantic review tools on 2-3 high-risk repositories (Layer 3). Implement merge gate policies for automatic rejection, second reviewer requirements, and compliance checkpoints. Train reviewers on AI code patterns: what hallucinations look like, what novel vulnerability classes to watch for, how to verify edge case handling in AI-generated logic.

Days 61-90: Validate governance effectiveness. Deploy your engineering intelligence dashboard tracking AI-generated code percentage, technical debt velocity, time-to-governance-approval, and defect escape rates by tool. Run a simulated compliance audit: can you explain which code was AI-generated, which tool generated it, which compliance requirements it satisfies, and how you validated correctness? Measure whether technical debt trends reversed after governance implementation. Document Agent Manifests for any production multi-agent workflows (capabilities, token limits, IO contracts, reliability signals).

The one metric to track obsessively: time from AI generation to governance-approved merge. Set a short target for small PRs (under 200 lines), for example two hours, and adjust it to your team. If you are hitting this target consistently, your governance framework has low enough friction that developers will follow it. If you are missing this target, your tooling is creating bottlenecks and developers will route around it.

Test your AI incident response plan. Run a tabletop exercise: an AI-generated bug caused a production incident. Can you identify every other PR from that tool this month? Can you proactively review them for similar issues? Can you generate an audit report for your compliance team? If the answer is "no," your governance framework is incomplete.

The EU AI Act uses a staged timeline. Transparency obligations began applying in August 2026, while the revised high-risk timelines depend on whether a system falls under Annex III or is embedded in a regulated product under Annex I ^[2][3]. Before setting an internal deadline, classify the system and its role, then map the applicable requirements for logging, technical documentation, human oversight, and other controls. A repository's code provenance may help an organization demonstrate its development process, but the Act does not impose a universal code-provenance control on every AI system.

The choice is not "govern AI code or don't." The choice is "govern AI code proactively or reactively." Proactive governance means lower friction, higher developer satisfaction, and audit readiness. Reactive governance means emergency policy rollouts, codebase archaeology to understand what was AI-generated, and compliance risks that show up as line items in breach notification reports.

Start with the audit. Build the governance stack. Validate it with a simulated compliance review. Establishing these controls early makes it easier to review AI-generated changes and produce evidence during an incident or audit.

Frequently asked questions

What is AI code governance?

AI code governance is the set of controls that decide whether AI-generated code may ship, rather than only whether it compiles. In practice it is a three-layer stack: linting and formatting for mechanical correctness, SAST and DAST scanning for known vulnerability and code-smell patterns, and AI-powered semantic review for contextual correctness against your codebase. Each layer produces its own pass or fail signal, and a change must clear all three before human reviewers spend attention on business logic, architectural fit, and compliance documentation. See AI code governance for how this maps to Connectory's review workflow.

Why does traditional code review fail for AI-generated code?

Traditional review assumes every line had a human author who made intentional choices. AI-generated code offers statistical plausibility instead: it compiles, passes unit tests, follows naming conventions, and carries no obvious red flags, while the defects are semantic and the vulnerabilities emergent. CodeRabbit's analysis of 470 open-source pull requests found about 1.7x more issues per PR in AI-co-authored changes than in human-only PRs ^[4]. Signature-based SAST tools are effective against vulnerability classes they have seen before, and weaker against novel patterns such as a hallucinated query builder or a JWT validation function that bypasses signature checks in edge cases. In one study, five tools combined still missed about a fifth of vulnerability-contributing commits ^[7].

What merge gate policies should govern AI-generated code?

This article describes five enforceable policies, with example thresholds to tune: automatic rejection when AI-generated code is 15% or more of a changeset and carries high-severity findings, a mandatory second human reviewer above 40% AI-generated code, a compliance checkpoint requiring traceability documentation when AI code touches PII, authentication, or financial logic, quality thresholds identical to those applied to human code, and shadow AI detection rules that flag unapproved tool signatures. The severity, quality and path-based gates are fully automatable; the AI-share gates rely on declared or telemetry-reported attribution, so treat their thresholds as estimates and examples to tune. For a scoring approach to routing review depth, see reviewer trust calibration.

When do EU AI Act high-risk obligations become applicable?

The date depends on the system category and the obligation. Transparency rules began applying in August 2026; under the revised timeline, high-risk rules for Annex III systems apply from December 2027 and those for AI embedded in regulated products under Annex I apply from August 2028 ^[2][3]. First classify the system and check any exception or transition rule. For an in-scope high-risk system, plan for applicable logging, technical documentation, human oversight, risk management, and other required controls. Code review records can support an engineering audit trail, but code provenance is not a universal standalone AI Act requirement.

How do you detect shadow AI tool usage?

Track AI-generated code percentage by team, repository, and time period so deviations stand out: a team at 60% when the organization averages 20%, or a repository climbing from 15% to 45% over two months, is a signal worth investigating. Complement that with detection rules for unapproved tool signatures in commit messages and code comments, and for commit timing patterns that suggest large external pastes. The stakes are real: breaches at organizations with high levels of shadow AI cost an average of $670,000 more, in IBM's 2025 study as reported by Cybersecurity Dive ^[1].

How do you keep coding agents from drifting away from your architecture?

Write the conventions down as rules that run before review instead of relying on reviewers to remember them. An agent session does not know that your service layer must go through a repository or that the team standardized on one date library, so it produces code that works and still crosses those lines. Import boundary rules between layers, a dependency allowlist checked in CI, and naming rules in Semgrep or ast-grep catch architectural drift, dependency sprawl, and convention erosion automatically. Then route review depth by risk, and use branch protection with code owner review so high-risk paths cannot merge without the right approvers ^[10].

Who owns AI code governance inside an engineering organization?

Ownership belongs to decisions, not to a team name. Approving a tool, accepting a change, and enforcing a merge gate are three separate decisions with three different owners, and a policy that assigns all of them to "engineering" or "security" stalls the first time a pull request crosses both. Give each decision one accountable owner, state who must be consulted and within what time bound, and write the escalation default before a disputed change forces it. Developers carry more of this than most policies admit, because they are the first to see an unapproved tool signature, a dependency with an unclear license, or an agent authoring in a path it should not touch. Who owns AI governance works through a RACI table for platform, security, legal, and product teams, and first-line AI governance explains why engineers tend to see these problems before anyone else does.

Which single metric should engineering leaders track?

Time from AI generation to governance-approved merge. Set a target for small pull requests that keeps governance friction low enough that developers follow the process instead of routing around it, then tighten it as your tooling improves. Measure it separately from time-to-merge so you can tell whether the delay sits in tooling or in human review.

References

[1] Cybersecurity Dive, "'Shadow AI' increases cost of data breaches, report finds," July 30, 2025, reporting IBM's Cost of a Data Breach Report 2025. https://www.cybersecuritydive.com/news/artificial-intelligence-security-shadow-ai-ibm-report/754009/

[2] European Commission, "AI Act." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

[3] European Commission, "AI Omnibus enters into force," July 2026. https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force

[4] CodeRabbit, "State of AI vs. Human Code Generation Report," 2025. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

[5] 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

[6] Stack Overflow, "2025 Developer Survey: AI," 2025. https://survey.stackoverflow.co/2025/ai

[7] W. Charoenwet, P. Thongtanunam, V.-T. Pham, C. Treude, "An Empirical Study of Static Analysis Tools for Secure Code Review," ISSTA 2024. https://arxiv.org/html/2407.12241v1

[8] SmartBear, "Best Practices for Peer Code Review." https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

[9] Model Context Protocol, "What is the Model Context Protocol (MCP)?" https://modelcontextprotocol.io/docs/getting-started/intro

[10] GitHub Docs, "About protected branches." https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

[11] GitHub Docs, "Creating a pull request template for your repository." https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository