Code written by AI must be reviewed for speed and safety separately.

Pearce et al. analyzed code from various security-related scenarios generated by GitHub Copilot and reported that a considerable proportion contained vulnerabilities. [1] Since the study addresses models and issues at a specific point in time, the same ratio cannot be extrapolated to all current assistance tools.

The key point is not the conclusion that AI is always dangerous, but that the ability to present functional code does not guarantee safety. Compilation success, unit test passage, and review approval each detect different defects; one does not serve as a proxy for the others.

In development evaluations, record time, functional quality, maintainability, and security separately. Shortened time may be offset by vulnerability fixes and additional verification. Categories that breach the safety floor do not expand even if productivity is high.

Do not divide targets by lines of code; instead, classify them by impact areas such as authentication, authorization, cryptography, input validation, secrets, and external communication, because a short line can break authorization boundaries.

• Function: Does it work as required?
• Safety: Have known vulnerabilities and exploitation paths been mitigated?
• Maintainability: Can dependencies and intent be tracked?
• Total Cost: Does it include post-generation testing, correction, and re-review?

In Perry et al.'s experiment, while code from participants using AI assistance was less safe in some issues, participants tended to consider their own code to be safe. [2] The gap between actual quality and subjective confidence may lead to the omission of reviews.

This result does not mean that all developers or tools lead to overconfidence. Participants, languages, issues, and assistance models were limited, and differences in experience also exist. [2] Therefore, our organization measures not only the number of vulnerabilities but also the identification and verification behavior of generated parts.

Hiding or showing AI-generated parts in the review screen has pros and cons. Displaying them draws attention but may lead to the mistaken belief that non-AI parts are safe. Inspect all code by the same standards, while using the generation source for tracking and improvement.

Self-reported confidence is an entry point for education but not a basis for approval. Identify areas where high confidence overlaps with failed tests, and provide feedback with specific counterexamples and correction reasons.

In a study by Sandoval et al. on C language assignments for students, results were also reported where the AI-assisted group did not show a significantly larger security deterioration than the control group. [3] This evidence does not support a simple narrative that the security impact of AI assistance is always in one direction.

Differences among studies include participants, issues, languages, methods of questioning AI, and evaluation rules. [1] [2] [3] Do not average contrary results to decide on safety or danger; instead, map where differences occurred to your own usage scenarios.

In particular, the responsibility path differs when AI creates a complete function versus when developers select proposals and perform small completions. Sample not only adopted proposals but also rejected and modified ones, evaluating including selection behavior.

It is not guaranteed that safety comes from experienced users. While experts are good at spotting errors, they may omit verification in favor of speed. Analyze discovery rate, correction time, overconfidence, and critical defects by experience level.

• Issues: Separate input processing, authentication, cryptography, and memory safety.
• Usage Mode: Separate completion, function generation, and interactive correction.
• Experience: Compare discovery and correction between beginners and experts.
• Selection: Track adopted, modified, and rejected proposals.

Static analysis can broadly search for known patterns but does not understand all business logic or runtime authorization relationships. Dynamic testing can verify execution paths but misses paths not taken. Dependency checks and secret information checks also address different defects.

Do not apply special testing only to AI-generated code while excluding hand-written parts. Apply the same floor regardless of generation source, using AI-origin tags for additional focus. Link tags to change history to prevent loss during partial regeneration.

Do not rely solely on re-querying the model to fix security test failures. Because corrections may create other vulnerabilities, humans must verify causes, countermeasures, and re-testing. Automated corrections must leave diffs and rationale.

Assume that unknown vulnerabilities not found by testing remain, and implement least privilege, secret separation, input restriction, and monitoring in the execution environment. Do not complete defense solely through code review.

Code touching authentication, payments, personal data, and infrastructure changes is an area with greater failure impact than general boilerplate. Instead of prohibiting or freely allowing AI use, phase generation, testing, review, and release permissions according to impact.

For high-impact categories, save the input used for generation, reference materials, model version, adopted diffs, test results, and independent reviewers. Also verify controls that prevent sending confidential information to prompts. Safe output cannot be adopted if input leakage occurs.

Independent review means not just in name, but that someone other than the generator verifies requirements and threats and holds the power to reject. If review time is insufficient, do not tilt toward approval due to deadlines; instead, reduce the scope of targets.

Attach expiration and compensating controls to exception approvals. Do not turn expired exceptions into permanent rules; track additional testing, authorization restrictions, monitoring, and replacement plans.

Vulnerabilities found in production are not classified solely as model failures. Separate missing requirements, dangerous samples, review oversights, test settings, and excessive permissions, as owners differ for each cause.

Regression sets retain actual defect structures without secrets. Test not only the ability to generate correct code but also the ability to reject or confirm dangerous requests, and whether corrections break other functions.

Operational metrics should be the leakage of critical defects, pre-review discovery rate, correction recurrence rate, verification time, and exception backlog, not the AI adoption rate. If adoption rate is the goal, rejecting dangerous proposals becomes a disadvantageous action.

The value of AI code assistance is not just writing quickly. It has value if it creates inspectable small diffs, explains dangerous areas, and allows humans to safely reject them. Approve processes that meet these conditions.

If code assistance models are updated, they may propose different libraries, APIs, and exception handling for the same instructions. Record not only the model name but also the provided version and settings, and re-run regression sets for high-impact areas after updates.

Verify proposed dependency packages for existence, maintenance status, license, and known vulnerabilities. Do not automatically introduce plausible fictional packages or malicious packages with similar names as part of the generated code.

If AI proposes an old API, it may break in future updates even if it passes functional tests. Cross-reference with official documentation for target versions, and include deprecated features, maintenance deadlines, and replacement plans in reviews.

When sending source to external tools, verify secrets, personal information, customer code, and contractual export restrictions. Ensure not only the safety of output code but also that input is not leaked during the generation process, applying the same adoption gate.

If the supplier cannot disclose update content or retention conditions, limit usage to low-impact code. Do not accept unauditable conditions for the sake of convenience; maintain alternative tools and manual recovery paths.

The release record separates tool version, dependencies, and target repository from criteria: zero tolerance for critical vulnerabilities and secret exposure, maxima for ordinary defects and recovery time, and a minimum quality-adjusted throughput. A critical event or other breached limit in high-impact code stops generation and automatic approval, returning work to standard review. Restart requires the AppSec owner to approve an independent scan, a manual-recovery drill, and traceability of affected changes.