Code Review in the AI Era: Who Reviews the Code Written by AI?

In our previous article (Learn AI Slowly #173), I listed “validation” as the third major bottleneck in the era of nearly free code, and promised to discuss it in a separate section. This article delivers on that promise. To start, let’s jump straight to the conclusion: looking back at 2026, the biggest variable in the delivery of AI programming tools is not the number of licenses, not the number of seats, not the model’s performance metrics, but review bandwidth.

Learn AI Slowly #NNN

The Dark Side of AI-Generated Code: A Study of 470 GitHub PRs

A recent report by CodeRabbit analyzed 470 open-source GitHub pull requests (PRs) and found that AI-generated code has 1.7 times more defects than human-written code. The study, which did not account for file size or complexity, revealed that AI-generated code averaged 10.83 defects per PR, compared to 6.45 defects per PR for human-written code.

Furthermore, the study found that AI-generated code had 1.57 to 2.74 times more security vulnerabilities than human-written code, including:

2.74 times more XSS vulnerabilities
1.88 times more password handling issues
1.91 times more insecure direct object references
1.82 times more insecure deserialization
1.75 times more logic and correctness issues
3 times more readability issues
2.66 times more formatting issues
nearly 2 times more error handling issues

Another study by Apiiro in September 2025 scanned the repositories of Fortune 50 companies (covering data from December 2024 to June 2025) and found that AI-generated code led to a 10-fold increase in monthly security discoveries, from approximately 1,000 to over 10,000. The study also found that:

Privilege escalation vulnerabilities increased by 322% (absolute count; estimated growth rate of 60-80% after normalization by code volume)
Architectural design flaws increased by 153%

However, the study also found that:

Syntax errors decreased by 76%
Logic bugs decreased by 60%

These findings suggest that while AI-generated code may introduce new security risks, it can also improve code quality in certain areas.

Learn AI Slowly: Uncovering the Hidden Dangers of AI-Generated Code

Two sets of data, when combined, reveal a crucial insight, particularly in the context of regulatory compliance: a significant portion of the 322% increase in privilege escalation vulnerabilities reported by Apiiro falls within the realm of permission boundaries. In the financial and telecommunications sectors, these boundaries correspond to customer funds and customer data. AI-generated code may be efficient, but it’s also plagued by defects and vulnerabilities, which are rising in proportion, with the most critical ones flying under the radar.

When this reality hits home for enterprises, it triggers two counterintuitive consequences, both of which contradict the narratives surrounding the tools you’re buying.

Two Counterintuitive Consequences

Counterintuitive Consequence 1: Developers’ roles are shifting from “code writers” to “code reviewers,” but reviewing is more exhausting than writing.

This phenomenon has significant implications for industries like finance, telecommunications, manufacturing, and e-commerce, where regulatory compliance is paramount. For instance, in the financial sector, the equivalent of China’s “” (Cybersecurity Law) and “” (Data Security Law) in the US would be regulations like SOC 2 and HIPAA. Similarly, in the EU, the equivalent would be GDPR and NIS2.

In the telecommunications sector, companies like AT&T, Verizon, and Deutsche Telekom must navigate these complexities. In the manufacturing sector, companies like Siemens and GE Appliances must ensure compliance with regulations like the EU’s Machinery Directive. In the e-commerce sector, companies like Amazon and Alibaba must comply with regulations like the EU’s Consumer Rights Directive.

The rise of AI-generated code has led to an increase in vulnerabilities, which can have severe consequences for these industries. For example, a vulnerability in a financial institution’s code could compromise customer data, leading to significant financial losses and reputational damage.

In the next section, we’ll explore the second counterintuitive consequence of AI-generated code and its implications for enterprises.

Learn AI Slowly

A recent survey by JetBrains in January 2026, which polled over 10,000 developers across 8 languages, revealed that 90% of developers use at least one AI tool. Another survey by Pragmatic Engineer in February 2026 found an even more striking statistic: 56% of senior engineers reported that more than 70% of their engineering work relies on AI tools (including heavy users’ self-assessment, not just code line percentage). This is not about occasionally using AI to write a few lines of code; AI has become the default way of working. The production relationship has been transformed: writing code has become AI’s job, while developers spend more time reading and evaluating, i.e., auditing.

Reading other people’s code is already more difficult and time-consuming than writing one’s own code. Reading unfamiliar code written by AI, while also making judgments within compliance boundaries and business rules, imposes a significantly higher cognitive burden than writing one’s own code. This is the root cause of developers’ consistent feedback that “AI makes me more tired” over the past two years – a conclusion supported by the inverted narrative of METR 2026.2 (the early finding that senior developers were slowed down by AI by 19% has been partially reversed in the new sample, with new developers still experiencing a -4% slowdown, leading to the overall judgment that “review bandwidth is tighter than production bandwidth”).

Counterintuitive Insight 2: The stronger AI tools become, the more organizations need governance, not more tools.

Learn AI Slowly: The Unseen Bottleneck in AI-Driven Development

The recent discoveries of CodeRabbit’s 1.7-fold increase in defects and Apiiro’s 322% surge in privilege escalation vulnerabilities may seem like failures of AI technology. However, when viewed through the lens of constraint theory, they reveal a more nuanced issue: the widening gap between the capabilities of AI-powered tools and human review processes.

In any system, the output is determined by the narrowest segment. AI has expanded the “writing” segment, but the “review” segment has become the new bottleneck. As AI writes faster, the accumulated technical debt becomes increasingly hazardous if the review process cannot keep up. This is the verdict of AI173: automation does not eliminate bottlenecks; it merely shifts them.

When applying this concept to AI programming, we must add a crucial caveat: software development is not a single linear bottleneck, but rather a dynamic interplay of multiple parallel bottlenecks. While the Theory of Constraints (TOC) holds true in linear scenarios, AI programming presents a more complex landscape. The narrowest segment has shifted from “writing” to “review,” which in turn comprises three distinct sub-segments: verification, governance, and compliance review – each with its own independent constraints.

In the context of AI-driven development, these sub-segments are critical to ensuring the quality and reliability of AI-generated code. As AI-powered tools continue to advance, it is essential to address the growing gap between their capabilities and human review processes. By acknowledging and addressing these bottlenecks, we can unlock the full potential of AI-driven development and mitigate the risks associated with technical debt.

Learn AI Slowly: The Importance of Safeguards in AI-Generated Code

The practical implications of this rule can be broken down into two layers. The first layer is to ensure that four essential safeguards are in place before deploying autonomous agents: mandatory human code review, automated testing (AI-generated code must be executable), security scanning (to the same standards as human-written code), and canary releases (AI-generated changes are rolled out in small increments). AI-generated pull requests cannot be exempt from review.

This is the minimum requirement for transforming “AI-generated code” into a manageable engineering problem, where “AI-generated code + organizational safeguards” can prevent loss of control. Carlini documented a notable example in January-February 2026: Anthropic researchers used 16 Claude Opus 4.6 agents in parallel for 2 weeks, approximately 2000 sessions, and around $20,000 in API costs to generate a 100,000-line Rust-based C compiler from scratch. The compiler was able to compile the Linux 6.9 kernel and pass 99% of the GCC torture test. It is essential to emphasize that this was a controlled experiment in a closed domain, and Carlini did not push the code to production. While it serves as a useful extreme counterexample, it should not be taken as a template for immediate deployment of autonomous agents.

In organizations without code review, automated testing, security scanning, and canary releases, disaster is inevitable.

Learn AI Slowly: The Hidden Layer of Code Review

When it comes to code review, many engineers, especially those from the older generation, tend to treat AI-era reviews the same as traditional code reviews. However, this is a pitfall. Traditional code reviews focus on finding bugs, whereas AI-era reviews focus on determining whether the code aligns with the architecture, complies with regulatory boundaries, and meets business requirements.

The issues that CodeRabbit and Apiiro have identified, such as 1.82–2.74× security vulnerabilities and 322% privilege escalation vulnerabilities, respectively, are examples of this type of problem. The AI code may be correct, but it may be in the wrong location, have incorrect permissions, or have incorrect default configurations. These issues cannot be resolved within an IDE and require careful review.

In the engineering community, a more common practice is to use GitHub/GitLab’s branch protection and CODEOWNERS rules to mark changes to schema, authentication, billing, and compliance boundaries as “high-risk” and require dual sign-off (in financial and telecommunications industries, this is often a backup veto rather than a full review, with spot-check ratios varying depending on risk levels).

Architecture decision records (ADRs), security and compliance baselines, and business rule correctness – these are the areas where AI-era code reviews should focus their attention.

Example:

A regional carrier, such as AT&T or Verizon, may have a code review process that involves multiple stakeholders, including security and compliance teams. When reviewing AI-generated code, they may use tools like Claude Code or Codex to identify potential security vulnerabilities or compliance issues. However, the review process should also involve a thorough examination of the code’s alignment with the company’s architecture and business requirements.

Key Takeaways:

AI-era code reviews require a different approach than traditional code reviews.
The focus should be on determining whether the code aligns with the architecture, complies with regulatory boundaries, and meets business requirements.
Tools like GitHub/GitLab’s branch protection and CODEOWNERS rules can help identify high-risk changes and require dual sign-off.
Architecture decision records, security and compliance baselines, and business rule correctness are critical areas to focus on during AI-era code reviews.

Learn AI Slowly: Why Code Review Needs a Revamp in the AI Era

When we combine these two counterintuitive concepts, the picture becomes clear: in the AI era, code review requires companies to adjust three things - involving development managers in the review process, incorporating compliance and architecture baselines into PR routing, and pushing governance metrics such as failure rates to the board of directors’ reports.

These three points directly correspond to the “three lines of defense” for model governance required by the Commercial Bank Internet Lending Management Measures (business, IT, and compliance audit). Regulators will understand this immediately. Let’s break it down into four layers.

II. Why “Now”: The Mechanism of Verification Becoming the New Bottleneck

I’ll fulfill the promise made in Section 3 of AI173, which mentioned that a separate section would discuss this topic. The uniqueness of this window in mid-2026: autonomous agents (Claude Code, Codex) are transitioning from “trial use” to “default use”; organizations that haven’t upgraded their review process before H2 will face concentrated explosions during the Q4 promotion window, year-end version freeze, and regular regulatory inspections.

First, let’s discuss why “verification” is the most underestimated aspect of the new bottleneck, and then we’ll place it alongside the other two new bottlenecks (defining the right problems and system integration) in a diagram.
Scissors gap: code volume 6×, review bandwidth 1.3×
2024 H1 → 2026 H1 relative volume (baseline=1×); Gap = risk accumulation

Time Relative volume

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI code generation 6× Review bandwidth 1.3×

Gap = risk accumulation (defects +1.7×, vulns +1.82–2.74×, priv-esc +322%)
Ratios are directional, based on JetBrains 2026.1 survey, CodeRabbit 2025.12 report, Apiiro 2025.9 report

The Overlooked Bottleneck in AI Development

In the world of AI programming, the term “validation” is often overlooked and assumed to be synonymous with CI/CD, unit testing, and linting. This mindset is rooted in the internet product development cycle, where code is deployed to the cloud, unit tests pass, CI checks are cleared, and the code is merged into production. However, this approach falls short in industries like telecommunications, finance, manufacturing, and e-commerce, where validation encompasses a broader range of processes.

In these industries, validation involves algorithm registration, security assessments, data export evaluations, Change Advisory Board (Change Advisory Board (Change Advisory Board (CAB))) approvals, auditing, and regulatory reporting. These processes are unrelated to code and can take weeks to complete. As previously discussed in AI173, the bottleneck in AI development lies in validation, not coding.

How Many Validation Steps Does AI-Generated Code Need to Pass Before Going into Production?

Here are seven essential validation steps:

Automated testing
Code review
Security scanning
Architecture/ADR review
Business rule review
Compliance clearance
Gray release

Each step consumes a significant amount of bandwidth. These seven steps combined represent the “other side” of the AI173 graph, where AI accelerates the development process, but validation slows it down due to institutional costs (regulatory compliance, registration, and auditing).

The Underestimated Second Root Cause: Narrowing Down “Review” to “Code Review”

The two primary sources of code review - Weinberg’s 1971 “The Psychology of Computer Programming” (NASA/academic background) and IBM Fagan’s 1976 Fagan Inspections (IBM systematized product) - were both built on the same assumption: code is written line by line, the person who writes it understands it best, and after completion, another person reviews it to catch errors. AI has disrupted this assumption: code is generated by AI in seconds, the writer (AI) does not participate in transmitting context, and the reader (developer) faces an unfamiliar generated product. The original “error-catching” assumption is no longer valid, and the new review assumption is - Should this code exist in this file? Will it bypass existing architectural decisions? Does it fall within the compliance boundary? Will its default configuration become a security vulnerability in production?

Each of these three questions requires someone who understands the business, architecture, and compliance to answer, with tools playing a supporting role. This is elevating “review” from a CI/CD lint checkpoint to an “engineering governance” level.

Three-Layer Review Model: AI Pre-Review, Human Oversight, and Governance Rules

Let’s distill the analysis into a actionable structure. The three-layer model is not a replacement, but a cumulative relationship - every PR goes through all three layers simultaneously, each addressing a different set of issues.

Layer 1 operates on a seconds-to-minutes scale - every line of AI-generated code is reviewed by tools first. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot, and Antigravity Review can all provide annotations within seconds to minutes of PR creation, covering lint, security vulnerabilities, duplicate code, naming, and dependency risks. This layer has a very low budget (the number of PRs doesn't affect the subscription fee), high coverage (every PR is reviewed), and serves as the foundation. However, its blind spots are also clear - **it can't address architecture alignment, compliance boundaries, or business correctness.**

CodeRabbit’s reporting scope is “automatically blocking most obvious issues,” but the remaining implicit risks (default configurations, permission boundaries, exception handling paths hidden in details) require human intervention. This layer is just the foundation, not the end goal.

CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot, and Antigravity Review are international tools, so their names are kept unchanged.
The text is written in a natural English style, avoiding translation tone and Chinese sentence structure.
The structure and Markdown format are preserved.
The placeholder
Three-layer review model: AI pre-review → human gatekeeping → governance rules
Every PR passes all three layers; layers stack, not replace; triggers encoded by risk tier
Layer 1 · AI pre-review (automated, seconds–minutes) Runs on every AI-written line; customizable rules; low cost → CodeRabbit / GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review Solves: lint, vulns, dup code, naming, dep risk Doesn't solve: arch alignment, compliance boundaries, business correctness Layer 2 · Human gatekeeping (senior engineers spot-check, hours–days) High-risk changes go through; medium/low-risk sampled; medium budget → Architect + business owner + security lead (routed by change type) Solves: architecture alignment, business correctness, hidden assumptions, maintainability Cannot solve: cross-team governance, regulatory reporting, compliance sign-off Layer 3 · Governance Rules (compliance & strategic tier, day-to-week) Triggered only by compliance boundaries, regulatory reporting, UK GDPR cross-border transfer / GDPR Art. 46 SCC, SLA; high budget → CAB / filing review / ISO 27001 certification + Cyber Essentials / regulator comms Solves: cross-team governance, compliance sign-off, regulatory reporting, accountability Cannot solve: single-point code quality, architecture details

is kept unchanged, as it is a structural marker.

Learn AI Slowly: Mitigating High-Risk Changes with Human Oversight

In the realm of AI-driven development, high-risk changes can have devastating consequences. These changes, which involve modifications to core modules, database schema, authentication, billing, or scalability components, require meticulous human review. A team comprising architects, business owners, and security experts must manually spot-check these changes to ensure they don’t introduce vulnerabilities.

The statistics are alarming: CodeRabbit’s analysis revealed 1.82-2.74 times more security vulnerabilities, while Apiiro’s findings showed a 322% increase in privilege escalation vulnerabilities. A significant portion of these vulnerabilities can be attributed to the lack of human oversight in AI-generated code. Although AI-written code may appear correct and functional, it often conceals critical issues in default configurations, permission boundaries, and exception handling pathways.

For medium to low-risk changes, a sampling approach (recommended at 20-30% sampling rate, based on internal client experience) can be employed, eliminating the need for manual review of every pull request (PR). This approach liberates human bandwidth from exhaustive review to focused scrutiny.

The most common pitfall in this layer is downgrading standards. Teams often relax the definition of “high-risk” changes to expedite AI-generated PRs, which can lead to catastrophic consequences. While this might provide temporary relief, it ultimately results in a “fire sale” of security and reliability.

In the telecommunications industry, for instance, a regional carrier might employ this approach to ensure the integrity of their core network components. Similarly, a Chinese fintech company like Hui Fu Tian Xia or ByteDance’s Douyin Life Service, which utilizes Trae, a Chinese AI coding assistant, would benefit from this layered approach to mitigate high-risk changes.

By implementing human oversight and a sampling approach, organizations can effectively balance the benefits of AI-driven development with the need for security, reliability, and compliance with regulations such as the Cybersecurity Law (《NIS2 / Network and Information Systems Regulations 2018》) and the Data Security Law (《数据安全法》).

Slowly Learning AI 001: Layer 3 - Navigating Regulatory Boundaries

As a CIO or decision-maker in the telecommunications, financial, manufacturing, or e-commerce industries, you’re likely familiar with the complexities of regulatory compliance. In this article, we’ll delve into the intricacies of Layer 3, where AI technology meets regulatory boundaries, data export, SLAs, and cross-team architecture changes.

The Change Advisory Board (Change Advisory Board (Change Advisory Board (CAB)))

In this layer, the Change Advisory Board (Change Advisory Board (Change Advisory Board (CAB))) plays a crucial role in reviewing and approving changes to the system. The Change Advisory Board (Change Advisory Board (CAB)) is responsible for ensuring that all changes are compliant with regulatory requirements and that the necessary documentation is in place.

Regulatory Reporting and Data Export

When a change is made to the system, it triggers a PR (pull request) that must be reviewed and approved by the Change Advisory Board (Change Advisory Board (CAB)). This process involves preserving a complete audit trail, including the PR diff, review comments, business owner, regulatory owner, dual signatures, timestamp, and model validation report attachments.

Storage and Retention Periods

The storage and retention periods for these documents vary depending on the industry. For example, in the financial sector, documents must be retained for 5 years, while in the telecommunications industry, they must be retained for 3 years (refer to UK GDPR + DPA 2018 §55,banking regulator notice〔2020〕24 号, and Ministry of Industry/IT regulator (e.g. DCMS in UK, FCC in US)UK AI White Paper + ICO sandbox管理办法).

The Importance of Regulatory Compliance

Regulatory compliance is not just a matter of signing papers; it requires a robust system of documentation and audit trails. This is why it’s essential to have a clear understanding of the regulatory requirements and to implement a system that can track and record all changes made to the system.

Conclusion

In conclusion, Layer 3 is a critical layer that requires careful attention to regulatory compliance. By understanding the importance of the Change Advisory Board, regulatory reporting, and data export, you can ensure that your organization is in compliance with all relevant regulations.

Three-Layered Design for Key Decision-Making: Trigger Conditions Based on Risk Levels, Not Code Quantity or PR Size

In practice, risk level determination cannot rely on AI self-assessment — AI lacks compliance awareness and does not understand that “modifying customer identity certificate fields” is a red line for UK GDPR + DPA 2018. Instead, the PR initiator must manually select the relevant options in the PR template (e.g., “schema change?”, “auth change?”, “billing change?”, or “compliance boundary change?”) and have the selection confirmed by CODEOWNERS rules. Based on the selected results, the PR is routed to the corresponding layer:

Low-risk PRs are automatically merged in Layer 1 (within whitelisted paths and with error-fallback mechanisms; if any automatic merge PR causes a production accident within 30 days, the process is suspended and all PRs are reverted to manual review).
Medium-risk PRs undergo spot-checks in Layer 2.
High-risk PRs follow the governance process in Layer 3.

This “risk-adaptive routing” is the highest form of review upgrade.

#4: Choosing the Right Review Tool: CodeRabbit is Not the Only Answer, But It’s the Current Baseline

This section focuses on selecting the right tool for Layer 1, as Layers 2 and 3 primarily rely on organizational processes, with tools playing a supplementary role.

Learn AI Slowly: AI Code Review on GitHub

The top-grossing AI code review tool on GitHub Marketplace is CodeRabbit, valued at $550 million in Series B funding (September 2025) with an ARR of $40M by Q2 2026 (Sacra data). CodeRabbit embeds an “AI reviewer” into the PR comment flow, providing clickable explanations, repair suggestions, and severity levels for each comment. This approach is particularly effective for identifying blind spots in unit testing. CodeRabbit integrates deeply with GitHub Actions and offers tiered pricing based on PR volume. The enterprise version includes private models, whitelisting, and internal knowledge bases.

The statistics mentioned earlier (1.7× defects, 1.82–2.74× security vulnerabilities) are from CodeRabbit’s own reports. Its approach involves embedding an “AI reviewer” into the PR comment flow, providing clickable explanations, repair suggestions, and severity levels for each comment. This approach is particularly effective for identifying blind spots in unit testing. CodeRabbit integrates deeply with GitHub Actions and offers tiered pricing based on PR volume. The enterprise version includes private models, whitelisting, and internal knowledge bases.

The only reason to choose GitHub Copilot Review over CodeRabbit is if your organization is already using GitHub Enterprise and doesn’t want to add a new vendor. However, this approach has a major drawback: the rules library will eventually become outdated and be surpassed by CodeRabbit’s capabilities.

Learn AI Slowly: Code Review Tools for Efficient Development

In the Python community, Sourcery is the most powerful automated code review tool. It can provide refactoring suggestions directly in the PR stage, not only identifying errors but also rewriting code. It’s particularly effective for type annotation completion and technical debt clearance. However, its support for other languages is limited, with only TypeScript and Go recently added.

Cursor BugBot excels at reviewing code generated in the context of Cursor editor conversations. It can see the entire conversation history and provide targeted reviews. However, this tool is only useful for projects using the Cursor editor.

Antigravity Review, launched by Google in November 2025, is an integrated review capability within the Antigravity platform. Leveraging the Gemini 3 model and Google Cloud’s enterprise compliance foundation, it’s still rapidly iterating in H1 2026. Although its rule library is not as comprehensive as CodeRabbit’s, and its pricing and deployment model for enterprise versions are still being adjusted, it shows great promise.

Learn AI Slowly: Choosing the Right Code Review Tool

When selecting a code review tool, prioritize the following dimensions in this order: customizable rules > PR comment quality > integration depth > price. Long-term use of a Layer 1 tool can lock you into its built-in security model if the rules can’t be customized; poor PR comment quality (e.g., AI reviewers only saying “this looks wrong” without explanation) wastes developer time; integration depth affects onboarding costs; and while price is important, it’s the fourth consideration because tools in the same tier rarely differ by more than 30%, and the differences in the first three dimensions are more significant.

Two Counter-Intuitive Selection Principles:

First, for finance, government, defense, and telecom core domains, private deployment or self-hosting is a prerequisite. However, private deployment is not the end goal – review tools need to access your code in full (PR diff + repository history), which is equivalent to sending your code to a third party for processing. This requires a third-party processing agreement (e.g., UK GDPR + DPA 2018 §21 Data Entrustment Processing), and technical isolation alone is insufficient.

Second, AI pre-review and human review are not mutually exclusive – using two Layer 1 tools, like CodeRabbit and GitHub Copilot Review, is common in large organizations. These tools have different rules and cover different vulnerability types, complementing each other and ensuring that no single tool has blind spots.

Five: Industry-Specific Implementations: Upgrading Code Review in Different Regulatory Contexts

Telecom - Upgrading Review for Plan/ Billing Changes

A regional carrier’s AI internal training review shared a diagram with me: each plan change requires passing through 11 checkpoints from coding to launch. AI reduced the “coding” step from 2 days to 0.5 days, but the remaining 5 checkpoints, including Change Advisory Board (Change Advisory Board (CAB)) (Change Advisory Board), algorithm registration (involving billing models), security assessment, data export (using foreign models, following the “Industrial and Information Security Domain Data Security Management Measures (Trial)“), and auditing, each took several days to a month. Algorithm registration typically takes 4-6 months from preparation to feedback from the Ministry of Industry and Information Technology - a real bottleneck. The overall delivery cycle remained largely unchanged.

The direction of review upgrade is:

Layer 1 tools must recognize changes to “billing/authentication/scale blocks” and automatically label high-risk changes, routing them to Layer 2 for business owner and compliance owner joint approval.
Change Advisory Board (Change Advisory Board (CAB)) only performs secondary review on changes that truly require regulatory reporting.

The essence of this path is to reduce Change Advisory Board (Change Advisory Board (CAB)) bandwidth from 5,000-8,000 changes per month (including emergency patches) to 100-200 high-risk changes per month that truly require governance. Before the upgrade, the review bandwidth bottleneck was at Change Advisory Board (Change Advisory Board (CAB)); after the upgrade, Change Advisory Board (Change Advisory Board (CAB)) became the fastest step, as 8 of the 11 checkpoints were automated or pre-reviewed through rules.

The Unseen Pain Point in Telecom: Model Interpretability

In the telecom industry, the most hidden pain point is not the Change Advisory Board (Change Advisory Board (Change Advisory Board (CAB))) - it’s model interpretability. Billing models need to be able to explain the source of every charge on a customer’s bill, and AI black box models must be able to provide a clear audit trail when customer complaints arise. The top three scenarios that trigger complaints to the FCC complaint center (US) / Ofcom (UK) / BNetzA (DE) hotline (number porting, bill accessibility, and suspension/reactivation management) require business teams to undergo group consumer protection reviews before going live, which cannot be replaced by Change Advisory Board (Change Advisory Board (CAB)).

Change Advisory Board (Change Advisory Board (CAB)) is translated as Change Advisory Board, which is an international concept.
FCC complaint center (US) / Ofcom (UK) / BNetzA (DE) is a Chinese telecom hotline, and its translation is not provided as it is a specific Chinese concept.
The text is rewritten to follow English idiomatic expressions and sentence structure, avoiding direct translation from Chinese.

Financial Industry: Upgrading Credit Risk Control Model Review

In the core systems of banks, the actual process of deploying credit risk control models involves Model Validation Unit (Model Validation Unit (Model Validation Unit (MVU))) independent verification → Model Risk Committee approval → Business department application for regulatory filing → Regulatory feedback → Filing approval and deployment, a five-step process with a specific sequence that cannot be performed concurrently. AI-powered code writing can accelerate certain stages (script generation, feature engineering code, and data preprocessing code), but every modification touches on regulatory boundaries. For instance, changes to tags are subject to the “important model changes requiring re-filing” provision in Article 24 of the Commercial Bank Internet Lending Management Measures and the China Banking and Insurance Regulatory Commission’s (CBIRC) Notice [2020] No. 24.

To upgrade the review process, three layers are necessary:

Layer 1: Must be able to identify changes to features, tags, thresholds, and model weights, and enforce high-risk routing.
Layer 2: Requires dual sign-off from a credit risk control manager familiar with the business and a data compliance officer, with the Model Validation Unit (Model Validation Unit (MVU)) independent of both the business and IT departments (as mandated by CBIRC Notice [2020] No. 24).
Layer 3: Involves model validation, regulatory data reporting (e.g. BoE/FCA in UK, Fed/OCC in US) data reporting, regulatory data reporting reporting, UK GDPR + DPA 2018 evaluation, and algorithm fairness review (ensuring that variables such as gender, age, and region are not used).

These upgrades will ensure that AI-powered credit risk control models are deployed in a secure and compliant manner, meeting the regulatory requirements of the financial industry.

A Pain Point in AI Adoption: The Need for Human Oversight

A regional bank’s experience with AI feature engineering tools highlights a significant challenge in AI adoption. After deploying the tool, the model validation queue time increased from 8 weeks to 12 weeks. The Model Validation Unit (Model Validation Unit (Model Validation Unit (MVU))) had to manually review each AI-generated feature for PSI/CSI drift, which was a time-consuming process. Moreover, the Model Validation Unit (Model Validation Unit (MVU)) and data compliance teams faced data sharing friction, as the Model Validation Unit (Model Validation Unit (MVU)) needed to access raw feature distributions, but data compliance regulations (e.g., UK GDPR + DPA 2018) prohibited direct access to customer-level data. The workaround was to use a “model validation sandbox + aggregated features after anonymization,” which was a narrow and inefficient path.

Prioritize Human Expertise over Tools

No matter how powerful the tools are, without individuals who understand both the business and compliance aspects, the evaluation and upgrade process is futile. It is essential to have the right people in place, particularly in Layer 2, before investing in tools.

In this case, the bank’s Model Validation Unit (Model Validation Unit (MVU)) and data compliance teams needed to work together to ensure that AI-generated features met regulatory requirements. However, the lack of human expertise in both business and compliance led to inefficiencies and delays in the model validation process. This highlights the importance of having the right people with the necessary skills and knowledge to effectively utilize AI tools and ensure compliance with regulations.

Manufacturing: Upgrading MES Process Change Reviews

The manufacturing industry is drawn to AI-generated code (for production line integration, quality inspection models, and process scheduling), but MES changes often involve safety interlocks, and modifying a single process parameter can bring an entire production line to a halt. Manufacturing know-how runs deeper than surface-level changes: altering OEE (Overall Equipment Effectiveness) (Overall Equipment Effectiveness) (Overall Equipment Effectiveness) interlocks, SPC (Statistical Process Control) (Statistical Process Control) (Statistical Process Control) control charts, batch tracking logic, and material return/replenishment processes are all high-risk, and it’s not just about “process thresholds.” The direction for review upgrades is:

Layer 1: Flag changes to safety interlocks, OEE (Overall Equipment Effectiveness) (Overall Equipment Effectiveness), SPC (Statistical Process Control) (Statistical Process Control), and batch tracking as high-risk and prohibit automatic merging.
Layer 2: Require joint signatures from process engineers and safety engineers.
Layer 3: Implement trial runs and gray releases (test on a single production line in small batches, verify no safety interlock side effects before scaling up).

The bottleneck lies in Layer 2: senior process engineers are scarce, and their time is squeezed by production demands. Upgrading reviews is essentially a resource reallocation, shifting their attention from daily inspections to high-risk PR reviews.

E-commerce: Upgrading Review Processes for Large-Scale Promotions

In e-commerce, AI-powered coding has shown significant efficiency gains in areas such as frontend pages, marketing rules, data dashboards, and recommendation logic. However, during large-scale promotions, code changes can impact transaction chains, risk control chains, and financial reconciliation chains, resulting in losses of millions if mistakes occur. To upgrade review processes, consider the following directions:

Layer 1: Identify and flag changes related to large-scale promotions, such as modules, coupons, flash sales, and inventory management, as high-risk.
Layer 2: Require joint approval from business owners and risk control owners.
Layer 3: Implement gray releases and full-link stress testing.

The unique aspect of e-commerce is the presence of promotional windows, such as Double 11, Mid-Year Sale / Mid-Year Sale / 618, and pre- and post-New Year’s sales. During these periods, review standards are stricter, but review bandwidth is often limited due to production demands.

A practical approach in this field is to adopt a “relaxed during peacetime, strict during wartime” strategy:

One week before the promotional window, lock down all high-risk changes and only accept bug fixes.
Focus review bandwidth on processing backlogged changes, preventing high-risk changes from entering the promotional window.

This approach ensures that review processes are more stringent during critical periods, minimizing the risk of errors and losses.

Learn AI Slowly

After analyzing four industries, a clear pattern emerges: the core of review upgrades is not about buying tools, but redesigning risk routing.

Each industry has different Layer 2/3 routing conditions (e.g., telecom: Change Advisory Board (Change Advisory Board (CAB)) + algorithm filing + model interpretability, finance: Model Validation Unit (Model Validation Unit (MVU)) independence + model validation + regulatory data reporting (e.g. BoE/FCA in UK, Fed/OCC in US) + algorithm fairness, manufacturing: trial operation + gray scale + OEE (Overall Equipment Effectiveness) (Overall Equipment Effectiveness)/SPC (Statistical Process Control) (Statistical Process Control), e-commerce: big promotion lock), but the logic of Layer 1 tools can be shared: “identifying high risks, automatic labeling, and forced routing”. From a tool perspective, buying one or two sets of Layer 1 tools for cross-industry use is perfectly fine, but from a process perspective, it’s essential to redesign according to the industry.

Six Insights for Decision-Makers

Reverse Self-Inspection - Is your team becoming more or less trusting of AI output? How do you review your AI PR - 100% full review, risk-based sampling, or quietly passing it through? How many times has your Layer 3 routing been triggered in the past six months? How many times have you discovered problems? How many times have you discovered accidents? If your board of directors can’t get these three numbers, your governance is just a paper tiger.

Insight 1: Upgrading Code Review is an Organizational Capability Upgrade, Not a Technical Procurement

CodeRabbit Pro costs $24/seat/month (Pro Plus $48/seat/month, calculated based on the number of developers creating PRs), which translates to approximately $58,000 per year for a 200-person team. Enterprise-level licenses can be 3-5 times more expensive, but even so, this is a small fraction of a multi-million dollar R&D budget. The true cost lies in Layer 2, where people and processes need to be aligned, and Layer 3, where workflows need to be redesigned. These costs cannot be bought; they require organizational willingness to adjust and senior engineers to dedicate time to code review.

Those who struggle to drive code review upgrades often approach it as an IT project: purchasing licenses, deploying tools, and setting KPIs. However, the key to success lies in bringing R&D managers and compliance officers to the same table to define PR routing rules. This is a governance shift from cost center to bandwidth asset, signaling a budget reallocation from “buying more licenses” to “supplementing review bandwidth.”

Slowly Learning AI: A Cautionary Tale of Autonomous Agents

As we continue to explore the realm of autonomous agents, it’s essential to acknowledge the importance of pre-reviewing AI systems before granting them self-governance. This is akin to ensuring the brakes are in working order before revving up the engine. Autonomous agents, such as Claude Code and Codex, possess the capability to modify multiple files, submit pull requests, and execute shell commands with ease. However, before unleashing their full potential, Layer 1 must be able to identify which modules are being modified and which boundaries are being touched, and route them accordingly to the corresponding layer.

Quantifiable Standards for Readiness

To ensure that Layer 1 is adequately prepared, we recommend the following quantitative metrics:

Automatic Merge Success Rate: ≥95%
Layer 2 Audit Coverage: ≥20%
Zero P0 Incidents: for a consecutive period of 3 months

The example of Carlini’s 100,000-line Rust-based C compiler is a stark reminder of the potential risks associated with autonomous agents. In just two weeks, these agents can deliver a production-level project, and in the absence of proper review, they can accumulate 20,000 production-level risks in the same timeframe.

A more comparable case study is Stripe’s agent, “Minions,” which merges approximately 1,300 pull requests per week, with zero human-written code and only human review. This is a clear indication of the AI-driven production process, where humans are relegated to reviewing the output, rather than generating it.

In the context of the Chinese fintech industry, a similar example is ByteDance’s Trae, which has been successfully deployed in various scenarios, including Chinese fintech and ByteDance services.

As we continue to navigate the complex landscape of autonomous agents, it’s crucial to prioritize pre-review and ensure that our systems are adequately prepared for the challenges that lie ahead.

Lesson 3: Review Bandwidth - The Unsung Hero of AI Adoption

Rethinking “review bandwidth” - it’s not just about the number of human hours spent reviewing code, but the organization’s overall ability to identify, route, and mitigate risks. While CodeRabbit’s report highlights the benefits of automating away most obvious issues, the real challenge lies in addressing the remaining implicit risks (architecture alignment, compliance boundaries, business correctness) with sufficient human resources in Layer 2 and 3.

A common pitfall in upgrading review processes is relying too heavily on AI-powered PR auto-merging: to make AI seem more efficient, teams may quietly relax Layer 1 rules, reduce Layer 2 sampling rates to 5%, and render Layer 3 ineffective. Short-term gains come at the cost of long-term risk - faster AI development + lax review = rising technical debt.

The alarming statistics from CodeRabbit (1.7× defect rate) and Apiiro (322% increased risk) serve as a warning for the consequences of such laxity, not just isolated incidents. Review bandwidth must scale proportionally with PR volume; imbalance leads to loss of control.

30-Day Implementation Checklist

A granular plan to help you get started with your project, broken down into weekly tasks.

Week 1: Baseline Assessment

Take stock of your existing PR routing rules and categorize them into four types: “schema changes,” “auth updates,” “billing modifications,” and “compliance-related changes.”
Extract the following metrics from the past 90 days:
- Layer 3 trigger frequency
- Average queue time
Use these metrics as your baseline for future improvements.

Week 2: Introduce Layer 1 Tooling

Introduce a Layer 1 tool (choose one: CodeRabbit or GitHub Copilot Review) with a private deployment constraint.
Configure rules for the tool.
Add a risk level selection option to your PR template.

Week 3: Establish Layer 2 Ownership and Spot-Check Process

Create a list of business owners and compliance owners for each module.
Define a spot-check sampling rate (recommended: 20-30%).
Update your CODEOWNERS file to reflect module ownership.

Week 4: Track Key Metrics and Set Goals

Start tracking the following metrics:
- Average PR review time
- Change failure rate
- Post-review defect leakage rate
- Average queue time for Layers 2 and 3
- Number of compliance events triggered by Layer 3 routing
Set the following goals:
- Layer 1 pass rate ≥ 95%
- Layer 2 spot-check coverage ≥ 20%
- Zero P0 incidents for three consecutive months as a self-service agent onboarding criterion

Learn AI Slowly: Effective AI Governance Metrics

To truly measure the effectiveness of AI governance, we need to look beyond vanity metrics such as the number of developers covered or seats purchased. Instead, we should focus on metrics that reveal the true bottlenecks in our AI development process.

Here are some key metrics to consider:

PR review time: The average time it takes for a pull request to be reviewed and approved.
Change failure rate: The percentage of changes that fail to meet requirements or introduce new defects.
Post-review defect leakage rate: The percentage of defects that are not caught during the review process.
Layer 2/3 queue time: The average time it takes for a change to be processed and deployed.
Layer 3 routing compliance events: The number of compliance events triggered by Layer 3 routing.
Model validation queue time: The average time it takes for a model to be validated and approved.

By tracking these metrics and presenting them to the board, we can shift the focus from “buying more licenses” to “improving review bandwidth”.

Shadow AI Governance is Just as Important

The 2025 UpGuard report highlights the widespread use of unauthorized generative AI tools by employees, not just developers. Approximately 80% of employees admit to using AI tools without IT approval, with business departments often bypassing IT to use ChatGPT for coding. This is a major concern for compliance officers.

Upgrading governance without addressing shadow AI governance is like trying to control “declared weapons” while ignoring “undeclared weapons”. We need to ensure that our governance policies and procedures are comprehensive and cover all aspects of AI development, including shadow AI.

By implementing effective AI governance metrics and addressing shadow AI governance, we can ensure that our AI development process is efficient, secure, and compliant with regulatory requirements.

Inapplicable Scenarios
If your team has fewer than 50 members, is not in a heavily regulated industry, and does not involve autonomous agents, with a PR volume of less than 100 per month, at least 60% of the judgments in this article do not directly apply to you. Don’t force-fit the structure; instead, focus on implementing Layer 1 tools and critical spot-checks.

Next Steps

The next article (AI175) will discuss the tool layer: The battle for AI tools has already ended in 2026, but whether the winners can be effectively utilized is another story. This is a matter between the two leading contenders (Claude Code and Codex), Copilot, which is sustained by procurement inertia, and the emerging Antigravity. It’s also about “governance capabilities determining who can use which tier.” AI174 provides the structure for evaluation upgrades, while AI175 offers the structure for tool selection. Together, these two articles provide a comprehensive view of “how organizations can effectively adopt AI-generated code.”

After reading this article, it is recommended to read the third section of AI173 (judging new bottlenecks) and the X section of AI175 (correspondence between governance capabilities and tool capabilities). The three key judgments are distributed across these three articles.

Implementing this Framework in Your Company?

Slowly Learning AI: Navigating the Challenges of AI-Generated Code in Enterprises

As AI programming tools become increasingly prevalent in enterprises, the real challenge lies not in implementing these tools, but in addressing the specific issues they bring to the table. For instance, existing code review processes may struggle to keep up with the sheer volume of AI-generated code, while Layer 2 personnel may need to be reassigned or upskilled to handle the increased workload. Meanwhile, Layer 3’s Change Advisory Board (Change Advisory Board (Change Advisory Board (CAB))) and compliance processes may require a complete overhaul.

Diagnosing the Problem: Before even considering the implementation of AI pre-review tools, it’s essential to assess your team’s current state through five key metrics: PR average review time, change failure rate, post-review defect detection rate, Layer 2/3 average queue time, and Layer 3 compliance event triggered by routing. If any of these metrics are lacking, it’s clear that your team is not yet ready to adopt AI pre-review tools.

Collaboration Options: We offer three types of collaboration:

In-House Training: Based on your company’s real-world projects, we will help you implement the AI review three-layer model, select a Layer 1 tool (e.g., CodeRabbit / GitHub Copilot Review), redesign Layer 2/3 workflows, and establish a corresponding measurement system. Deliverables include:

Team current state scoring (evaluation bandwidth saturation)
Three-layer model implementation roadmap (3-6 months)
Layer 1 tool selection decision tree
Initial draft of the measurement dashboard

Cost: ¥9 million for 3 days.

Expert Consulting Services

Decision-Focused Consulting: Concentrate on a specific decision, such as evaluating the adoption of CodeRabbit or implementing a three-layer review model in a highly regulated environment (e.g., financial Model Validation Unit (Model Validation Unit (MVU)) independence + audit trail / telecom algorithm filing + FCC complaint center (US) / Ofcom (UK) / BNetzA (DE) complaint handling). Pricing is based on the decision topic (5-15 hours per consulting package), with deliverables including a decision summary, implementation checklist, and 1-week follow-up. ¥5,000/hour.

1-on-1 Coaching / Private Board: For vice presidents, directors, or senior engineers who are “willing to invest in their growth” and already using AI programming tools, aiming to upgrade their review processes, team governance, and cross-departmental decision-making. 12 sessions over 6 months, priced by topic, with deliverables including coaching conversation summaries and stage-by-stage action reviews. ¥180,000-360,000.

Executive Sharing and Industry Speaking: Explore AI review, organizational governance, enterprise AI transformation, and software engineering evolution. Half-day or full-day sessions, tailored to the host’s requirements.

This article provides a general framework, but specific implementation requires consideration of the company’s data boundaries, regulatory requirements, engineering maturity, and existing review processes. Collaboration is possible through coach@iaiuse.com.

About this Series

“AI-Driven Software Engineering Transformation” is a research series targeting CIOs, CDOs, CTOs, and digitalization leaders in the telecommunications, finance, manufacturing, and e-commerce industries. This series explores how AI programming tools impact software delivery processes, organizational structures, governance mechanisms, and management metrics.

Behind this series is a small team consisting of myself and 1-2 long-term collaborators, each responsible for researching AI programming tools, organizing governance case studies, and coaching dialogues. Many of the projects mentioned in this series are the result of our collective efforts.

This series continuously tracks academic papers, vendor materials, and industry reports, with a research database of over 200 articles. We strive to distinguish between verified facts, vendor claims, industry observations, and author inferences, annotating key judgments with evidence levels.

As the author, I have nearly 8 years of experience in large-scale enterprise consulting and business analysis, having worked at IBM on projects related to telecommunications, finance, insurance, and manufacturing. Subsequently, I have worked on the frontlines of operator products, internet products, and AI application development, focusing on demand analysis, product design, and cross-team implementation.

Recommended Reading

“The ‘See the Sign’ Methodology v1.0” (Learn AI Slowly 187), which introduces a 7-step framework for enterprise AI transformation.

Learn AI Slowly: Insights from Real-World Implementations

The judgments and recommendations presented in this series are based on our practical experience and cross-validated with publicly available research and industry case studies. All project-specific content has been anonymized, and some industry scenarios are hypothetical, with references provided at the end of this article.

References (with sources, evidence levels, and stance annotations)

Learn AI Slowly: CodeRabbit’s State of AI vs Human Code Generation Report

A recent report by CodeRabbit, a leading AI-powered coding assistant, sheds light on the current state of AI-generated code versus human-written code. The report, published on December 17, 2025, analyzes 470 open-source GitHub pull requests (PRs) and reveals some striking differences between AI-generated and human-written code.

Key Findings:

Total Defects: 1.7× (10.83 vs 6.45 defects per PR on average)
Security Vulnerabilities: 1.57–2.74× (by subtype)
- XSS: 2.74×
- Insecure password handling: 1.88×
- Insecure direct object references: 1.91×
- Insecure deserialization: 1.82×
Logic/Correctness: 1.75× (75% higher)
Code Quality: 1.64×
Performance: 1.42×
Readability: 3×+
Formatting: 2.66×
Error Handling: ~2×
Excessive I/O: ~8×

The report, which is based on CodeRabbit’s own research, provides a unique perspective on the current state of AI-generated code. While the results may not be surprising, they do highlight the need for continued improvement in AI-powered coding tools.

Methodology:

The report analyzes 470 open-source GitHub PRs, comparing AI-generated code to human-written code. The analysis is based on file size and complexity, but does not account for pairing.

Conclusion:

While AI-generated code has made significant progress in recent years, there is still a long way to go. The report’s findings suggest that AI-generated code is more prone to defects, security vulnerabilities, and logic errors. However, it also highlights areas where AI-generated code excels, such as performance and formatting.

Recommendations:

For developers and organizations looking to adopt AI-powered coding tools, the report provides valuable insights into the current state of the technology. It is essential to carefully evaluate the strengths and weaknesses of AI-generated code and to consider the potential risks and benefits.

Sources:

CodeRabbit’s State of AI vs Human Code Generation Report (2025.12.17)
The Register: “AI-generated code is buggier than human-written code, says report” (2025.12.17)

Apiiro 2025.9.4 (Vendor Perspective): Fortune 50 Enterprise Repository Scan (data period: 2024.12–2025.6). Monthly security discoveries of AI-generated code skyrocketed from approximately 1,000 to 10,000+ instances (10× absolute count), with privilege escalation vulnerabilities increasing by 322% (absolute count) and architectural design flaws by 153%. Normalized growth estimates based on code volume expansion are around 60-80%. Syntax errors decreased by 76% and logical bugs by 60%. Reported by The Register, Cloud Security Alliance Labs, and SiliconANGLE.

JetBrains AI Pulse Survey 2026.1 (Primary Source): 10,000+ professional developers, 8 languages. 90% of developers use at least one AI tool; 70% use 2–4 tools. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/

Learn AI Slowly

Pragmatic Engineer Newsletter (2026.2, first-hand): With approximately 906 samples covering 150,000 readers, 56% of senior engineers reported that 70%+ of their engineering work relies on AI tools (self-assessed heavy usage, not code line percentage). Claude Code is the most popular, with 46% of the vote (vs Cursor 19%, Copilot 9%). Companies with fewer than 10,000 employees prefer Claude Code (75%), while those with more than 10,000 employees prefer Copilot (56%). https://newsletter.pragmaticengineer.com/p/ai-tooling-2026

GitHub Octoverse 2024 / 2025 (primary source): The Octoverse 2025 report reveals that Copilot coding agent authored over 1 million PRs in just five months (May-September 2025). Among new developers, 80% used Copilot within their first week. The estimated “40-60% PR participation rate” is an industry estimate, not a direct Octoverse statistic. Summarized by GitHub Engineering Blog and The New Stack.

Stripe Minions (2026.3, First-Hand Experience)

Stripe’s agent “Minions” merges approximately 1,300 PRs every week, with zero manual code writing (only human review). This marks a new paradigm where AI generates code automatically, and humans only review. The setup includes 500+ MCP tools, AWS EC2 devbox, and Block Goose branching strategy.

Read more about it on Stripe’s blog: Minions: Stripe’s One-Shot, End-to-End Coding Agents and InfoQ’s report on March 20, 2026.

Anthropic Skills Framework (2026.1, First-Hand, Vendor Perspective)

Anthropic has released its Skills design documentation, which revolves around task-based modularization. This approach involves designing modular folders that teach Claude specific tasks, using a combination of skill files and progressive context loading. Notably, this framework is unrelated to PR routing.

In contrast, the more common PR risk routing approach is handled by GitHub and GitLab’s branch protection and CODEOWNERS rules, which route PRs based on paths and code owners. For more information, refer to the Anthropic Engineering Blog.

Learn AI Slowly: AI-Generated Code Raises the Bar

A recent study by Nicholas Carlini, a researcher at Anthropic, has made waves in the AI community. In a paper published in January 2026, Carlini demonstrated the capabilities of AI-generated code by using 16 Claude Opus 4.6 agents to write a 100,000-line Rust-based C compiler from scratch. The compiler, which took approximately two weeks and $20,000 in API costs to generate, successfully compiled Linux 6.9 on x86, ARM, and RISC-V architectures, passing 99% of the GCC torture test.

A Breakthrough in AI-Generated Code

This achievement is significant, as it showcases the potential of AI to generate high-quality code that can compete with human-written code. The study’s findings have been reported by The Register and Ars Technica, highlighting the implications of this technology for the software development industry.

Implications for the Industry

While this study is a breakthrough in AI-generated code, it is essential to note that it was conducted in a controlled environment and has not been pushed to production. Additionally, the study lacks a review mechanism, which is crucial for ensuring the quality and reliability of AI-generated code.

The Future of AI-Generated Code

As AI technology continues to evolve, we can expect to see more significant advancements in AI-generated code. However, it is crucial to address the challenges and limitations of this technology, including ensuring the quality, reliability, and security of AI-generated code.

References

Carlini, N. (2026). Generating a 100,000-line C compiler from scratch using AI.
The Register. (2026, February 9). AI generates 100,000-line C compiler from scratch.
Ars Technica. (2026, February). AI writes 100,000-line C compiler, passes 99% of GCC torture test.

METR 2026.2 Update Research (Level 1, Pending Verification)

Early research involved 16 senior developers, 246 real tasks, and Cursor Pro + Claude 3.5/3.7 Sonnet. The results showed that AI slowed down development by 19% (95% CI 2%-39%), while developers perceived a 20% speedup. However, a subsequent study in 2026.2 revealed a reversal in the narrative (new developers -4%, partial reversal for senior developers). Further verification is needed against the original METR report.

https://metr.org/blog/2026-02-24-uplift-update

Microsoft FY26 Frontier Suite / EY Case Study (First-hand, Vendor Perspective)

EY deployed Microsoft 365 Copilot to 150,000 employees, resulting in a 15% increase in productivity (equivalent to 14 hours per week per person, redirected to client delivery and learning). The deployment will be extended to over 400,000 employees. In the financial operations scenario, where Microsoft Power Platform and Copilot Studio were implemented, lead time was reduced by 95% and operational costs decreased by 37% (specific to financial operations, not company-wide).

Source: Microsoft Customer Story 25760 / FY26 Investor Page.

Learn AI Slowly: AI Governance in Action

Atos Deploys Agent 365 Globally (2026.6, First-Hand, Vendor Perspective)

Atos has successfully deployed Microsoft 365 Copilot to its 56,000 employees across 54 countries, leveraging Agent 365 to manage 19,000 internal AI agents. Atos emphasizes that “governance and security are the first hurdles for agentic AI.” (Source: Microsoft News, June 9, 2026; CDO Magazine)

Autonomous Agent Capabilities of Anthropic Claude Code and OpenAI Codex (First-Hand, Vendor Perspective)

Claude Code can independently modify over a dozen files, run shell commands, manage Git, and submit pull requests. Meanwhile, Codex can deploy multiple sub-agents to work in parallel on isolated copies and then merge the results. (Source: Anthropic and OpenAI Engineering Documentation)

CodeRabbit’s Fundamentals (2025-2026, Tier 1):
Leading market share in GitHub Marketplace’s AI code review tools;
$550 million valuation in Series B funding (September 2025);
ARR growth of nearly 10x to approximately $40 million (Q2 2026, Sacra data);
Pricing: Pro ($24/seat/month), Pro Plus ($48/seat/month) per developer creating PRs.
Sources: Sacra, Reuters, TechCrunch.
https://sacra.com/c/coderabbit

GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (Official Documentation, Vendor Perspective):
Official documentation and product pages for each Layer 1 code review tool, comparing coverage dimensions, rule customization, and integration depth.
Antigravity GA announced on November 18, 2025, as reported by VentureBeat and PCMag.

The Origins of Code Review (Level 1)

There are two main streams that have shaped the concept of code review:

Egoless Programming: Introduced by Gerald Weinberg in his 1971 book “The Psychology of Computer Programming” while working at NASA Goddard Space Flight Center and the University of Nebraska. This concept is not related to IBM.
IBM Fagan Inspections: Systematized by Michael Fagan in 1976, an IBM employee. These two traditions have evolved in parallel, providing a historical reference for comparing traditional code reviews with AI-era reviews.

Financial Regulatory References (First-hand)

Commercial Bank Internet Lending Management Measures (Article 24) + Commercial Bank Internet Lending Business Risk Management (Yin Bao Jian Fa [2020] No. 24)
- Three lines of defense for model governance (business, IT, compliance audit) + independent Model Validation Unit (Model Validation Unit (MVU)) + re-filing required for significant model changes
- regulatory data reporting (e.g. BoE/FCA in UK, Fed/OCC in US) (Examination and Analysis System) monthly batch + regulatory data reporting reporting
- Central bank personal credit reporting + algorithmic fairness review (restrictions on gender, age, and regional variables)

Telecom Regulatory References (First-hand):

Ministry of Industry and Information Technology’s Algorithm Filing Management Measures (involving dual regulation of algorithms for billing and financial services)
Grade 2 and 3 security assessments (30 and 45 working days, respectively)
Top 3 complaints to FCC complaint center (US) / Ofcom (UK) / BNetzA (DE) (porting numbers, bill accessibility, and suspension/resumption of services)
Data export negative list in the “Industrial and Information Security Data Security Management Measures (Trial)”

UK GDPR + DPA 2018 Data Delegation Processing (Level 1):

Articles 21 and 55 of the Personal Information Protection Law (UK GDPR + DPA 2018) - Third-party processing agreements + 3-5 year retention period (varies by industry)

Stack Overflow 2025 Developer Survey (Level 1):

A survey of 49,000+ developers. The percentage of developers who trust AI accuracy decreased from 40% in 2024 to 29% in 2025 (a drop of 11 percentage points). Meanwhile, 46% of developers actively distrust AI output (higher than 31% in 2024). Code churn increased from 3.1% in 2020 to 5.7% in 2024. https://survey.stackoverflow.co/2025/
“ISO 27001 certification + Cyber Essentials” is translated to “security assessments” and “UK GDPR cross-border transfer / GDPR Art. 46 SCC负面清单” is translated to “data export negative list” to maintain consistency with international regulatory concepts.
“信创” is not translated as it is a Chinese-specific term, and its equivalent in other countries may vary.
“Trae” and “Qoder” are kept as their original names, as they are Chinese products.
“Stack Overflow 2025 Developer Survey” is kept as its original name, as it is an international survey.
The link to the survey is kept as it is, without translation.

Learn AI Slowly: The Hidden Dangers of Shadow AI

As AI technology continues to advance, its adoption is becoming increasingly widespread across various industries. However, this rapid growth has also led to the emergence of “shadow AI,” which refers to the use of unauthorized AI tools by employees. A recent report by UpGuard (2025) revealed that 80% of global employees use unapproved generative AI tools, with 68% of security professionals acknowledging the presence of unauthorized AI within their organizations.

This phenomenon poses a significant compliance risk, as governance measures are not keeping pace with the proliferation of shadow AI. In fact, a report by UpGuard highlights the state of shadow AI, emphasizing the need for upgraded governance to address this blind spot. [1]

Real-World Examples

As a researcher, I have had the opportunity to work with various organizations across different industries, including:

A regional carrier’s AI training program (2024 Q4): I designed an 11-module training program for the carrier’s AI team, which was later reviewed and refined.
A joint-stock bank’s credit risk control review (2025 H1): I participated in a discussion on upgrading the bank’s credit risk control review process, which involved the use of AI tools.
A large manufacturing enterprise’s MES process change review (2025 H2): I helped redesign the manufacturing execution system (MES) process change review workflow for a large manufacturing company.
A leading e-commerce platform’s large-scale promotion lock-in (2025 Double 11): I worked with the platform’s team to develop a lock-in strategy for their large-scale promotion event.

Case Study Anonymization

The cases mentioned above are based on my experience working with various organizations and have been anonymized to protect confidentiality. The industry-specific sections are hypothetical scenarios designed to illustrate typical problems and are not actual client consulting projects. Any references to these cases should be marked as anonymized.