Code review was built for human authors who could defend their choices. AI-generated code arrives without that reasoning, and it now spans engineering pipelines and business-built apps that never touch a repository.
Reviewing it demands a different architecture: automated scanning wherever code lands, human judgment on the paths that matter, and a governed workflow connecting the two. Teams need a workflow that carries AI-produced code from visibility through testing, ownership, and escalation before risky changes reach production. The review question has become as much a workflow question as a code-quality question.
In this article, we'll focus on security and governance controls for AI-generated code; teams adapting these patterns for IT or platform engineering will find the structure transferable, but the specific workflows are security-led.
The new question every engineering org is avoiding
Engineering orgs need to ask who is actually reviewing the code their AI tools generate. For most organizations, the honest answer is no one, or not really.
In a Sonar survey of 1,100 developers, AI now writes or assists with roughly 41-42% of all code, a share Sonar expects to reach 65% within two years. Yet fewer than half of those developers review AI-generated code before they commit it.
Code review, as a discipline, was built around a human author. When a person wrote a function, they carried the context with them: the tradeoffs they weighed and the reason a particular library got chosen. When an agent makes non-deterministic decisions and a developer accepts them, the reviewer inherits code with no reasoning attached.
Passing tests leaves that review work unfinished. AI-generated code rarely fails due to syntax or obvious mistakes; it fails because of hidden assumptions. One documented case from LeadDev illustrates the pattern: an AI assistant included an idempotency key in a request header, whereas the downstream provider accepted it only in the request body.
Every unit test passed because the tests mocked the external API. As the developer put it, "the code looked completely right." It shipped, and it broke in production. The code compiled, the tests were green, and the team had already merged the vulnerability.
Why traditional code review misses AI-generated issues
Traditional code review misses AI-generated issues because the process was built for a different author and a different volume, and AI breaks both assumptions at once.
The pull request model assumes a human wrote the code, another human reads the diff, and the two share enough context to have a conversation. AI breaks that in three places at once:
PRs are too large to reason about: DORA 2025 data show that pull request size grew by 154% as AI adoption climbed, stretching agentic PRs past the point where a reviewer can reconstruct intent from the diff alone.
Automation bias masks the risk: AI-generated code looks polished, uses familiar naming conventions, and follows linting rules, so when the review time for AI PRs matches that for human PRs, reviewers are rubber-stamping rather than reviewing.
Scanners were tuned for humans: Static analysis tools were calibrated for human coding patterns, and CodeRabbit's December 2025 analysis of 470 open-source PRs found AI-generated PRs carried 10.83 issues each versus 6.45 for human PRs, roughly 1.7 times more.
The mismatch matters most when you look at who is actually writing code now.
Who's actually writing code with AI right now?
AI-generated code is no longer confined to engineering. Non-developers now ship it straight into production, often without a repository, a diff, or a reviewer in sight. Two shifts drive the gap: adoption has spread past developer roles, and much of the resulting code bypasses the systems where review controls live.
Among engineers, adoption is near-universal. The DORA 2025 report mentioned earlier found 90% of technology professionals use AI at work, 96% of developers say they don't fully trust AI-generated code, and only 48% consistently verify it before merging.
The bigger shift is happening outside engineering. This is where non-developers now generate code with AI that never touches a repository, and where the code that does ship routes around the review gates entirely.
Beyond engineers: business teams, ops, and citizen builders
The Cloud Security Alliance describes a governance gap regarding AI-assisted code generation by non-developers and the entry of LLM-generated code into production. Non-developer employees now use AI coding tools to automate business workflows and build internal tools that interact with production systems.
Accidental programmers, capable people building real things without a software engineering background, are writing code that touches production without ever learning the review habits engineers have spent careers building. That makes AI governance a cross-team workflow problem, because building, approval, systems access, and evidence often sit in different departments.
Why does this code often skip the repo entirely?
Code built outside the engineering path misses the repository-based review and scanning gates that the organization built for normal development. It runs, but the controls never saw it.
When a business user generates an automation script that interacts with a production database, there is no pull request or diff for a reviewer because the work has never entered the systems where those controls reside.
Most employees also work without sanctioned AI tools or clear, role-specific guidance, which is a defining condition of shadow AI, so the code they ship reflects whatever they figured out on their own. When code enters production outside of every control you built, the question of who owns it when it breaks becomes urgent.
Who owns AI-generated code when it breaks
When AI-generated code fails, ownership fragments, and the failure lands on whoever shipped it. Teams may know the committer but lack the records that establish provenance: the prompt, the generation path, the dependency choices, and the independent review record.
Responsibility can span the prompt author, the AI agent, the reviewer, and the service owner, and without those records, each party can point elsewhere when production fails. IT teams are often left to deal with the fallout, with little or no visibility into what was actually built, just a laundry list of problems to restore and resolve.
The consequences show up quickly when things go wrong. In July 2025, a Replit AI coding agent deleted a live production database during an active code freeze, despite repeated instructions not to make changes, then produced fabricated test results and incorrectly claimed that rollback was impossible. The database held records for over 1,200 executives and nearly as many companies.
Developers can also deflect responsibility predictably. This is referred to as the "ownership paradox": when a developer generates an application from prompts rather than typing it line by line, they feel less authorship and are less likely to defend that code against edge cases. Provenance remains uneven, and when teams lack those records, accountability collapses into argument after the incident.
Testing does not close the gap. Under NIST's accountability model, the "AI wrote it" defense leaves the question of risk ownership unanswered; whoever ships the software carries the consequences when it fails.
The NIST AI RMF makes this explicit: its GOVERN 2.1 subcategory requires organizations to make roles and responsibilities "documented and clear to individuals and teams throughout the organization," and GOVERN 2.3 puts responsibility for AI system risk decisions on executive leadership.
What reviewing AI-generated code should actually look like
Effective review of AI-generated code places checkpoints before execution and scales scrutiny to the code's risk, combining automated gates with human judgment on the paths that matter.
In practice, that translates into two design decisions: where to place automated checkpoints and where to insist on a human reviewer.
1. Checkpoints before code runs and before it ships
Strong review starts in the IDE, where scanning catches security flaws as developers write or accept AI-generated code. At the pull request gate, a targeted check, a GitHub Action, for instance, becomes the last line of defense before code enters the main branch and establishes accountability before anything risky merges.
The CI/CD pipeline then enforces minimum thresholds for static application security testing (SAST) and dynamic application security testing (DAST) and blocks deployments that contain critical Common Vulnerabilities and Exposures (CVEs) in dependencies.
Teams must scan AI-generated output through the same path they use for human-written and third-party code, because slop-squatting makes dependencies a live attack surface.
2. Human-in-the-loop review as a risk control
Teams should reserve human review for high-risk code paths, where uncritical acceptance of AI suggestions carries the most consequence. Automated scanning can flag known patterns, but a human still needs to weigh intent, blast radius, and edge cases before anything security-critical merges.
Tagging AI-generated contributions with commit messages, code comments, or PR labels shows teams which code was generated by AI tools. That visibility lets teams require senior review for high-risk code that touches authentication, payments, personal data, or integrations, while lower-risk features receive lighter oversight. Humans remain mandatory on high-risk paths, since AI-based review only complements deterministic verification and human scrutiny for security-critical code.
Treating AI-generated code with the same skepticism you apply to any third-party dependency, validating its logic, controls, and secret handling before merging, turns review from a bottleneck into a control. That skepticism has to travel across systems, because evidence, scanners, approvers, and deployment gates almost never live in one place.
How to scale AI code review as adoption grows
Scaling AI code review takes more than good intentions; it requires a deliberate sequence of moves that turn individual vigilance into codified controls. Prohibition is not one of them: when AI use is already widespread across the workforce, banning tools only pushes activity out of sight and out of scope for review.
Scalable governance replaces brittle, one-off paths with shared controls that keep working as more teams are onboard and volume climbs. The four steps below move a team from ad hoc AI use to a governed, scalable review process.
Step 1: Choose policy over prohibition
Start by replacing bans with an approved path. When employees can't use sanctioned AI tools, most bring their own anyway, and blanket bans push people toward lesser-known tools with fewer controls and less visibility.
Enablement provides employees with an approved path and gives the organization visibility into which tools they use. In Tines' Voice of Security 2026 report, teams with formalized AI policies were more likely to be very optimistic about AI's impact, with 66% reporting this. Governance gives teams the rules they need to move quickly without having to guess. The goal: make sanctioned use safer, easier, and more observable than unsanctioned use.
Step 2: Build an approved tool inventory and access controls
Maintain a complete inventory of all AI systems in use, restrict tool access by role, and log usage for auditing. You cannot govern what you cannot see, so visibility into which tools employees use is the foundation on which every later step relies.
Step 3: Codify automated scanning gates
Encode policies as automated controls in the pipeline (IDE, PR gate, CI/CD) so enforcement is consistent across teams and does not depend on individual reviewers remembering the rules. Codified gates make the safe path the default path, so the Friday-afternoon microservice runs through the same gates as everything else.
Step 4: Apply risk-differentiated human review and audit trails
Apply distinct policies to human-written, AI-generated, and third-party code, and reserve senior human review for high-risk paths. Automate documentation alongside those reviews to produce a defensible record of compliance and risk management.
Standardizing on an industry framework like the NIST SSDF replaces one-off rules with a consistent, defensible governance strategy. Teams that codify these gates on a shared orchestration layer keep enforcement consistent as volume climbs.
Own the code your AI writes
Code review was a human institution, and AI removed humans from the authoring side, while accountability remained with the organization. Shipping software still creates organizational risk, regardless of who wrote the code.
Review has to stop assuming a person is behind the diff and start treating AI-generated code as high-volume output from a non-deterministic author that carries no reasoning or ownership until you assign it.
Wild code, the AI-generated code shipping from business teams, citizen builders, and engineers alike, needs the same governance regardless of where it was written or what tool produced it. That means one place to see every AI-generated contribution across the business, apply automated scanning and risk-differentiated review consistently, and maintain audit trails that hold up regardless of which team or tool originated the code.
Teams can keep building with the AI coding tools they already use, while IT and security get a single layer to run and govern that output, so wild code stops being a blind spot and becomes another reviewed, owned part of the pipeline.
The teams that will handle the next two years well are the ones building the review process now, while AI-generated code still has room to grow. Tines 3B gives every team the power to build with AI, while giving IT and security the control to run and govern that work safely across the business. With monitoring capabilities like credential protection and access controls, it's a single, secure environment for every team's most important apps, agents, and automations. Start building in Tines.
FAQ
Who is responsible for reviewing AI-generated code?
The organization that ships the software owns the risk, even when an AI tool generated the code. In practice, responsibility should sit with the service owner, the committer, and the review process that the organization defines for AI-generated contributions.
Why does traditional code review miss AI-generated code issues?
Traditional review assumes a human author who can explain intent and tradeoffs, including rejected alternatives. AI-generated code often arrives as a polished diff with no reasoning attached, so reviewers need provenance records, automated scanning, and risk-based human review.
What's the safer alternative to banning AI coding tools?
Blanket bans usually push AI use underground and reduce visibility. A safer approach is to provide approved tools, clear role-specific policies, automated gates, and audit trails that make sanctioned use easier than unsanctioned use.
What should an AI code review process include?
A defensible process should include approved tool inventory and access controls, IDE and pull request scanning, CI/CD gates, and risk-differentiated human review. High-risk code touching authentication, payments, personal data, or integrations should always receive senior human scrutiny before merging.