45% of AI-Generated Code Contains Security Flaws - Here's What That Means for Your Team

security_sam · February 19, 2026, 4:07am

Following up on the trust discussion happening in the community - I want to dig into the security implications because they’re more serious than most teams realize.

The Research That Should Alarm Everyone

Recent academic studies analyzing AI-generated code across multiple models and languages found that over 45% of AI-generated code solutions contain security vulnerabilities. This isn’t from a small sample - this is consistent across different LLMs and programming languages.

If you’re using AI coding tools in production (and 91% of engineering orgs are), you need to understand what this means for your security posture.

The Common Vulnerability Types

From both research and my own bug bounty work, here are the patterns I see repeatedly in AI-generated code:

1. Missing Input Sanitization (Most Common)
AI models consistently fail to add proper input validation. They generate code that works for happy-path scenarios but creates injection vulnerabilities.

Example pattern: AI generates a database query function that works great with expected inputs, but doesn’t sanitize user input. SQL injection vulnerability introduced.

2. Cross-Site Scripting (XSS)
AI-generated code is 2.74x more likely to introduce XSS vulnerabilities compared to human-written code. The model generates code that renders user input without proper escaping.

3. Insecure Deserialization
1.82x more likely - AI doesn’t understand the security implications of deserializing untrusted data.

4. Improper Authentication/Authorization
1.88x more likely for password handling issues. AI generates authentication code that looks reasonable but has subtle flaws.

These aren’t edge cases. These are fundamental security vulnerabilities that would fail even a basic security audit.

Why AI Models Generate Vulnerable Code

Understanding the root cause helps explain why this is so pervasive:

1. Training Data Contains Vulnerabilities
AI models are trained on public code repositories. Many of these repositories contain security vulnerabilities (that’s why bug bounties exist). The model learns that both secure and insecure patterns are “valid” solutions.

2. No Security Context
The model doesn’t understand threat modeling. It optimizes for “code that works” not “code that’s secure.” It can’t reason about attack vectors or adversarial scenarios.

3. Outdated Library Suggestions
Models may suggest libraries with known CVEs that were patched after the model’s training cutoff. You’re effectively re-introducing resolved vulnerabilities into new code.

4. Looks Professional, Is Insecure
This is the most dangerous aspect: AI-generated vulnerable code doesn’t look obviously wrong. It has proper formatting, reasonable variable names, even comments. It passes the “glance test” while failing the “security test.”

Real-World Example (Anonymized)

I recently did security consulting for a fintech startup. Found a critical vulnerability in their payment processing code. The pattern was unmistakable - AI-generated.

The code:

Had excellent formatting and comments
Worked perfectly in testing
Passed code review (reviewers saw professional-looking code)
Had a subtle race condition in payment verification

This could have cost them millions in fraud before being detected. The engineer who wrote it wasn’t malicious or incompetent - they accepted an AI suggestion that looked correct.

The False Confidence Problem

Here’s what keeps me up at night: AI code bypasses our natural skepticism.

When a junior developer writes authentication code, experienced reviewers look extra carefully. We expect potential issues.

When AI generates authentication code, it looks so polished that reviewers might give it less scrutiny. “This looks like production-quality code” - except it has a subtle auth bypass vulnerability.

We’re trained to spot amateur mistakes. We’re not yet trained to spot AI-generated vulnerabilities that look professional.

Practical Mitigation Strategies

If you’re using AI coding tools (and you probably should be, despite these risks), here’s how to do it more safely:

1. Security-Specific Prompting
Research shows this actually works. When prompts include explicit security requirements:

Claude Opus 4.5 with security reminders: 66% secure code
Without security reminders: 56% secure code

Simple addition to your prompts:
“Ensure this code includes proper input validation, follows OWASP security best practices, and handles edge cases securely.”

2. Critical Code Exclusion Zones
Some code should have zero AI involvement:

Authentication and authorization logic
Cryptographic implementations
Payment processing
Security patch code
Anything handling PII or credentials
Password storage and verification
Session management
API key handling

The risk-reward doesn’t justify AI assistance in these areas.

3. Mandatory Security Review Process
If code is AI-generated (or even AI-assisted), require security-focused review:

Explicit check for input validation
Review of authentication/authorization logic
Verification of cryptographic usage
Check for common vulnerability patterns
Testing with malicious inputs

4. Static Analysis Integration
Your static analysis tools should scan AI-generated code with the same rigor. Consider adding AI-specific checks:

Flag common AI vulnerability patterns
Check for outdated library suggestions
Verify security-critical functions
Require security annotations for AI code

5. Developer Security Training
This is critical: Developers need to understand common vulnerability patterns to spot AI mistakes. If you don’t know what SQL injection looks like, you can’t catch it in AI-generated code.

Security training is now a prerequisite for safe AI tool usage.

The Skill Development Concern

If junior developers learn to code by accepting AI suggestions, do they develop the security intuition to spot these vulnerabilities?

Understanding why code is insecure requires understanding threat models, attack vectors, and security principles. These aren’t skills you develop by accepting suggestions and fixing test failures.

This is my biggest long-term concern: Are we creating a generation of developers who can generate features quickly but can’t reason about security?

Verification, Not Trust

I’ll say it again: The question isn’t “Do you trust AI?” It’s “How effectively do you verify AI output?”

Build verification into your workflow as a first-class concern:

Assume AI code is insecure until proven otherwise
Security review is mandatory, not optional
Testing includes adversarial scenarios
Static analysis is non-negotiable
Senior security review for critical paths

My Recommendations

Accept that AI tools are here to stay - Fighting adoption is futile
Build security verification processes - Assume AI output is untrusted
Define exclusion zones - Some code should never be AI-generated
Invest in security training - Developers need to spot AI vulnerabilities
Measure security outcomes - Track vulnerability rates in AI-assisted code

The 45% vulnerability rate is alarming, but it’s a process problem, not a tool problem. With proper verification processes, AI tools can be valuable while maintaining security standards.

How is your team handling security review of AI-generated code? What practices are working?

priya_security · February 19, 2026, 4:08am

Sam, this is absolutely terrifying from an identity and fraud prevention perspective. The stakes in fintech are so high that these vulnerability rates are simply not acceptable.

Front-Row Seat to the AI Fraud Explosion

Working in fraud detection at a fintech startup after years at Auth0 and Okta, I’m seeing both sides of this AI equation:

AI tools helping developers build features faster
AI-powered attacks exploiting vulnerabilities in AI-generated code

The attackers are using AI too. And they’re finding vulnerabilities faster than traditional security audits can.

Identity Systems Cannot Afford These Risks

Your 45% vulnerability rate is existential for identity systems. Let me put this in context:

A subtle authentication vulnerability can:

Expose thousands of user accounts
Enable account takeover at scale
Bypass multi-factor authentication
Leak personally identifiable information
Violate regulatory compliance (GDPR, CCPA, etc.)
Destroy user trust permanently

One AI-generated auth bypass vulnerability could end a fintech company. The fraud losses, regulatory fines, and reputational damage would be catastrophic.

Our Zero-Tolerance Policy

At our company, we’ve implemented an extremely strict policy for identity and security code:

ZERO AI-generated code in:

Authentication flows (login, MFA, password reset)
Authorization logic (permissions, access control)
Session management
Token generation and validation
Fraud detection algorithms
Identity verification processes
Encryption/decryption of sensitive data
API key handling

No exceptions. No “AI-assisted.” These systems must be written by senior engineers who understand threat models deeply.

The Problem: Where Do You Draw The Line?

Here’s where it gets complicated. We’re strict about core identity flows, but what about:

Utility functions that identity code uses?
Database query helpers?
Logging and monitoring code?
API client libraries?
Form validation on the frontend?

If a “harmless” utility function has a vulnerability, it can still compromise the identity system that uses it.

We’re still figuring out where to draw boundaries. It’s not black and white.

The Emerging Threat: AI-on-AI Attacks

Here’s what keeps me up at night: Attackers using AI to generate exploits for vulnerabilities in AI-generated code.

We’re already seeing:

AI-generated phishing campaigns that sound perfectly natural
AI-powered social engineering at scale
AI finding patterns in leaked code to identify vulnerabilities
Automated exploit generation for common AI vulnerability patterns

If 45% of code has vulnerabilities and attackers can use AI to find them systematically, we’re in trouble.

The Long-Term Skill Concern

Your point about junior developers is critical from a security perspective.

If engineers don’t deeply understand:

How authentication should work
Why certain patterns are vulnerable
How attackers think and operate
What secure-by-design means

…then they can’t spot AI security mistakes. They don’t have the mental models to recognize that “working code” isn’t the same as “secure code.”

Security isn’t about following a checklist. It requires threat modeling, understanding attack vectors, thinking adversarially. These are skills you develop through experience and deep learning, not by accepting AI suggestions.

What We’re Doing

Beyond the zero-AI zones, our approach for other code:

1. Security-First Prompting
Every AI prompt must include: “Implement secure coding practices. Validate all inputs. Follow OWASP guidelines. Consider security implications.”

2. Mandatory Security Review
Any AI-assisted code (even utility functions) requires review by someone with security expertise.

3. Adversarial Testing
We test AI-generated code with malicious inputs, not just happy-path scenarios.

4. Static Analysis + Penetration Testing
Regular security scans plus quarterly penetration testing specifically looking for AI-generated vulnerability patterns.

5. Developer Security Training
Monthly security training sessions. Recent focus: Spotting vulnerabilities in AI-generated code.

The Question I’m Struggling With

How do you scale identity and fraud detection systems when:

Pressure to ship features fast (AI tools enable this)
Security cannot be compromised (zero tolerance for auth vulnerabilities)
Junior engineers want to use AI tools
Senior engineers are overwhelmed with security reviews

There’s tension between velocity and security. In fintech, security must win. But that puts us at a competitive disadvantage against companies willing to take more risk.

Is there a world where AI coding tools can be used safely for security-critical systems? Or do we need to accept that certain domains require traditional, manual development?

I honestly don’t know yet. But the 45% number tells me we’re not there yet.

eng_director_luis · February 19, 2026, 4:09am

Sam and Priya - excellent breakdown of the security challenges. Let me share how we’re addressing this at the enterprise level with Fortune 500 financial services regulatory constraints.

The Regulatory Context Changes Everything

When you’re operating under PCI-DSS, SOC 2, GDPR, and various financial regulations, the 45% vulnerability rate isn’t just a security problem - it’s a compliance nightmare.

Our auditors don’t care if code was AI-generated or human-written. They care about:

Security controls and verification processes
Audit trails and accountability
Compliance with security standards
Evidence of secure development practices

AI tools introduce new compliance questions we’re still navigating.

Our Three-Tier Governance Framework

After 8 months of iteration, we’ve settled on a tiered approach that balances security with developer productivity:

Tier 1 - Critical (NO AI Code)

Payment processing and financial transactions
Authentication and authorization systems
Compliance-required audit logging
Cryptographic implementations
Customer PII handling
Security controls and incident response

Zero AI involvement. Must be written by senior engineers with security training. Mandatory security architecture review before implementation.

Tier 2 - Sensitive (AI with Security Review)

Business logic involving money or sensitive data
API endpoints and integrations
Database schemas and migrations
Background job processing
Third-party service integration

AI-assisted code allowed, but requires:

Security-focused code review from certified reviewer
Static analysis with security-specific rules
Penetration testing for new features
Documentation of AI usage in change management

Tier 3 - General (AI with Standard Review)

UI components and frontend code
Internal tools and utilities
Test code and fixtures
Documentation generation
Boilerplate and scaffolding

Standard code review process applies. Still requires testing and quality checks.

The Classification Challenge

The hard part is teaching 40+ engineers how to classify their work correctly. We’ve had situations where:

Engineer thinks code is Tier 3, but it handles financial calculations (Tier 1)
Utility function seems harmless but is used in payment flow (Tier 1)
Frontend code that validates sensitive inputs (Tier 2)

We’ve created a decision tree and hold weekly training sessions. It’s getting better but still requires judgment calls.

Security Review Process Enhancements

Traditional code review wasn’t sufficient for AI-generated code. We’ve added:

AI-Specific Review Checklist:

Input validation on all user-facing inputs
Proper error handling (no information leakage)
Authentication/authorization checks appropriate for data sensitivity
No hardcoded secrets or credentials
Secure defaults (fail closed, not open)
Proper use of cryptographic functions
SQL injection prevention (parameterized queries)
XSS prevention (proper output encoding)
Library versions checked against CVE databases

Reviewer Certification:
We’ve trained senior engineers specifically on:

Common AI-generated vulnerability patterns
Security review techniques for AI code
How to spot “looks good but is insecure” code
Threat modeling for new features

Only certified reviewers can approve Tier 1 and Tier 2 code.

Tooling and Automation

We can’t manually review everything at scale. Our automated security pipeline:

1. Static Analysis (Enhanced)

SAST tools configured with AI-specific rule sets
Custom rules for common AI vulnerability patterns
Automatic flagging of security-sensitive code paths
Library dependency scanning for CVEs

2. AI Detection and Flagging
Working on tooling to detect likely AI-generated code (pattern analysis, comment style, etc.) and automatically route for enhanced review.

3. Security Testing Integration

Automated penetration testing in staging
Fuzzing with malicious inputs
Security regression tests
Integration with bug bounty program findings

The Cultural Shift Required

This isn’t just a technical change. We’ve had to shift engineering culture:

From: “Move fast and break things”
To: “Move safely and verify everything”

In financial services, “breaking things” means customer financial harm and regulatory penalties. The cultural change has been:

1. Security Is Everyone’s Job
Not just the security team’s problem. Every engineer is responsible for secure code, whether AI-generated or not.

2. Speed Is Not The Primary Metric
We measure:

Time to secure implementation (not just implementation)
Vulnerability detection rate in review
Post-deployment security incidents
Compliance audit findings

3. Senior Engineers Are Security Multipliers
Rather than just writing code, senior engineers:

Review security-critical implementations
Train junior engineers on secure practices
Update security guidelines based on new AI patterns
Serve as security consultations for complex features

Cross-Functional Collaboration

This required alignment across:

Engineering: Implementing secure development practices
Security Team: Defining security requirements and review processes
Compliance: Ensuring regulatory requirements are met
Legal: Understanding liability for AI-generated code
Leadership: Accepting that security slows feature velocity

The conversation with leadership was challenging. AI tools promised productivity gains. Security reviews reduced that gain. We had to demonstrate that velocity without security isn’t sustainable.

What’s Working

After 6 months of this framework:

Security incidents have decreased 40%
Audit findings related to code quality down significantly
Developer clarity improved (less ambiguity about when to use AI)
Security review process is more predictable

What’s Still Hard

1. Keeping Up With AI Tool Evolution
New AI coding tools release constantly. Each needs security evaluation before approval.

2. Junior Developer Frustration
They see AI tools as productivity enhancers. Security restrictions feel like blockers. We’re working on education and mentorship to help them understand why.

3. Competitive Pressure
Fintech competitors using AI aggressively, shipping faster. Explaining to leadership why we’re more cautious requires ongoing education.

4. Emerging Attack Vectors
As Priya mentioned, AI-powered attacks are evolving. We’re in an arms race.

Advice for Teams Starting This Journey

If you’re earlier in your AI governance journey:

1. Start with clear risk classification
Not all code is equally sensitive. Focus strictest controls on highest-risk areas.

2. Invest in security training
Developers can’t spot AI vulnerabilities they don’t understand. Training is foundational.

3. Automate what you can
Manual security review doesn’t scale. Build automation and tooling.

4. Accept reduced velocity in security-critical areas
AI speed gains don’t apply equally everywhere. Some code should be slow and careful.

5. Measure security outcomes, not just productivity
Track the metrics that matter for your risk profile.

The Long-Term Question

Sam asked about skill development for junior engineers. In enterprise environments, I’m seeing this play out:

Junior engineers who rely heavily on AI can ship features but struggle with:

Debugging complex security issues
Threat modeling for new features
Understanding why certain patterns are secure/insecure
Making security tradeoff decisions

We’re experimenting with structured learning paths that ensure junior engineers develop security fundamentals even in an AI-assisted world.

The goal: Engineers who can use AI tools effectively while maintaining security rigor.

How are other teams handling the balance between compliance requirements and AI tool usage?

alex_dev · February 19, 2026, 4:10am

This is really valuable information from the security and enterprise perspectives. But I want to bring this back to ground level - what does this actually look like for an individual developer day-to-day?

The Reality of Shipping Features

I appreciate the comprehensive security frameworks Luis described. But here’s my tension as a senior IC:

The pressure: Ship features to hit sprint goals, keep velocity up, maintain team metrics
The challenge: Every AI suggestion needs deep security review, which takes time
The question: How do I actually balance these in my daily work?

My Current (Imperfect) Approach

I’ve settled into some personal rules, but I’m not confident they’re sufficient:

Rule 1: Use AI for boilerplate only

Test scaffolding
Basic CRUD operations
Type definitions
Configuration files

Rule 2: Write security-critical code manually

Anything involving authentication or authorization
Database queries that could expose sensitive data
API endpoints handling user input
Payment or financial logic

Rule 3: Extra scrutiny for “looks good” code
Sam’s point about AI code looking professional is so true. I’ve caught myself almost merging AI-generated code because it looked clean and well-formatted, only to find it had a subtle bug on closer inspection.

The Time Tradeoff

Here’s where I’m struggling: The security review you’re all describing takes significant time.

If I use AI to generate a feature in 2 hours instead of 4 hours, but then spend 3 hours doing security review and testing… did AI actually save me time?

Sometimes yes (boilerplate, tests, docs). Sometimes no (complex business logic that looks right but isn’t).

The Skill Gap I’m Feeling

Reading this thread, I realize I probably don’t have the security expertise to properly review AI-generated code for vulnerabilities.

I can spot obvious bugs. I can’t necessarily spot:

Subtle SQL injection opportunities
Race conditions in async code
Authorization bypass vulnerabilities
Cryptographic implementation issues

Question for Sam and Priya: Are there good resources or tools for developers who want to get better at spotting AI-generated security vulnerabilities?

I feel like this is becoming a mandatory skill, but I don’t know where to learn it systematically.

The Tooling Question

Luis mentioned working on tools to detect AI-generated code and route it for enhanced review. This would be incredibly valuable.

Right now, our PR template asks “Did you use AI?” but it’s honor system. And honestly, I sometimes forget to mark it if I used Copilot for autocomplete suggestions throughout.

What I wish existed:

IDE plugin that automatically tags AI-generated code sections
Static analysis rules specifically for common AI vulnerability patterns
Code review checklist that adapts based on whether code is AI-generated
Educational resources on security review for AI code

Does any of this exist yet? Or are we all just making it up as we go?

The Junior Developer Problem

I mentor two junior engineers on my team. They want to use AI extensively because it helps them be productive.

But I’m seeing exactly what Maya described in her thread: They can ship features but struggle with debugging when things go wrong. And they definitely can’t spot security issues in AI-generated code - they don’t have the experience yet.

My concern: If I slow them down by restricting AI usage or requiring extensive security review, they get frustrated and fall behind on their goals. If I don’t, they’re potentially shipping vulnerable code.

How are other teams handling mentorship in the AI era while maintaining security standards?

Practical Question

For teams that have implemented the tiered frameworks (like Luis described):

How do you actually enforce it day-to-day?

Is it automated? Manual review? Honor system?
How do developers know if their code is Tier 1, 2, or 3?
What happens if someone accidentally uses AI for Tier 1 code?
How long does the enhanced review process take?

I want to implement something similar on my team, but I need to understand the practical mechanics.

The Honest Truth

The 45% vulnerability rate is alarming. I believe the security concerns are real. But I also face pressure to ship features fast, and AI tools help with that.

I’m trying to find the balance between:

Using AI to be productive
Not shipping security vulnerabilities
Not spending so much time on review that I lose the productivity gains
Helping junior engineers grow their skills safely

I don’t think I have it figured out yet. This thread is helping me realize I need to invest more in security understanding and better processes.

What are other ICs doing day-to-day to handle this balance?

vp_eng_keisha · February 19, 2026, 4:11am

Alex raises exactly the right questions. From a leadership perspective, I want to address both the process implementation and the broader organizational thinking here.

Verification, Not Trust - Making It Practical

Sam’s framing is perfect: This is about verification, not trust. But we need to make verification practical and scalable, or it won’t happen consistently.

Here’s how we’re operationalizing this at our organization:

Making Security Review Sustainable

1. Not All Review Requires Deep Security Expertise

Alex, you’re right that you might not spot every security vulnerability - most developers can’t, and that’s okay. But you can absolutely implement a basic security checklist:

Basic Security Review (Any Experienced Developer Can Do):

Are user inputs validated before use?
Are database queries parameterized (not string concatenation)?
Are error messages generic (not leaking system information)?
Are secrets/credentials hardcoded anywhere?
Is sensitive data logged?
Are authentication checks present on protected endpoints?

Deep Security Review (Requires Security Expertise):

Cryptographic implementation correctness
Authorization logic completeness
Race condition analysis
Advanced injection attack vectors
Session management security

We train all senior engineers on the basic checklist. Only security-certified reviewers do deep reviews for Tier 1 code.

2. Tooling Reduces Manual Burden

We’re investing heavily in automation because manual security review doesn’t scale:

Static Analysis Pipeline:

Runs automatically on every PR
Flags common AI vulnerability patterns
Checks for insecure library usage
Identifies sensitive code paths requiring enhanced review

AI Code Detection (Experimental):
We’re testing tools that analyze code patterns to detect likely AI-generated sections. When detected, the PR is automatically labeled for enhanced review.

Security Test Automation:

Automated security regression tests
Fuzzing with malicious inputs for API endpoints
Dependency vulnerability scanning

The goal: Automate what can be automated, focus human review on what requires judgment.

3. Process That Doesn’t Kill Productivity

The tiered framework works because it’s proportional:

Tier 3 (General) Code:

Standard code review (one approval)
Automated security checks must pass
Usually 1-2 hours from PR creation to merge

Tier 2 (Sensitive) Code:

Standard review + security-focused review
Enhanced test coverage required
Usually 4-8 hours from PR to merge

Tier 1 (Critical) Code:

Architecture review before implementation
Security team involvement during development
Multiple review rounds
Comprehensive security testing
Days to weeks from PR to merge

The key: Most code is Tier 3. Only ~15% of our code is Tier 1 or 2. So the enhanced process doesn’t impact most development velocity.

Addressing the Junior Developer Challenge

Alex mentioned the mentorship challenge. This is critical for long-term success.

Our Approach:

Month 1-2 (Onboarding):

Limit AI tool usage to specific approved scenarios
Focus on learning fundamentals and codebase patterns
Pair with senior engineers on security-critical code
Security training introduction

Month 3-6 (Guided AI Usage):

Can use AI for clearly defined use cases (tests, boilerplate)
Must explain AI suggestions in code review
Practice security review with supervision
Continue security training

Month 6+ (Autonomous with Oversight):

Can use AI more broadly
Required to follow tiered framework
Participate in security reviews
Ongoing security education

The Goal: Develop both AI tool proficiency AND security fundamentals. Not one or the other.

Resources for Security Skill Development

Alex asked about learning resources. Here’s what we’re using:

Internal Training:

Monthly “Secure Coding in the AI Era” workshops
Real examples from our codebase of AI-generated vulnerabilities caught in review
Threat modeling exercises
Practice security review sessions

External Resources:

OWASP Top 10 (foundational)
Specific modules on reviewing AI-generated code
Bug bounty write-ups (learn how attackers think)
Security-focused code review courses

We budget for security training as mandatory professional development, not optional.

The Metric That Actually Matters

Luis mentioned this, but it’s worth emphasizing:

We don’t measure “AI usage rate” or even “review time.”

We measure:

Security incidents per 1000 deployments (down 40% since implementing framework)
Vulnerabilities caught in review vs production (99% caught in review now)
Time from vulnerability detection to fix (average 2 days)
Security audit findings (decreased significantly)

These are the metrics that matter for organizational health and customer trust.

Speed matters, but security incidents are far more expensive than slower development.

Making Tier Classification Clear

Alex asked how developers know what tier their code is. We have:

1. Decision Tree Tool
Web-based tool where developers answer questions:

Does this code handle money or financial transactions? → Tier 1
Does this code authenticate or authorize users? → Tier 1
Does this code process PII or sensitive data? → Tier 2
Does this code integrate with third-party services? → Tier 2
None of the above? → Tier 3

2. Code Path Mapping
We’ve mapped our codebase into tiers. If you’re modifying existing code, you can check the tier of the file/module you’re working in.

3. When in Doubt, Ask
Better to ask and get clarification than guess wrong. We have a #security-questions Slack channel with fast response times.

4. Review Catches Misclassification
If a developer classifies Tier 1 code as Tier 3, reviewers will catch it and educate them. It’s a learning opportunity, not a punitive issue.

The Enforcement Mechanism

Automated Enforcement Where Possible:

Pre-commit hooks check for secrets/credentials
CI pipeline runs security checks before merge
Tier 1 code paths are tagged in the codebase - modifying them requires specific approvals

Process Enforcement:

PR templates require tier declaration
GitHub CODEOWNERS routes PRs to appropriate reviewers based on code paths
Security team has visibility into all Tier 1/2 PRs

Cultural Enforcement:

Security is part of performance reviews
Incident post-mortems include process improvement
Celebrating security catches (not punishing mistakes)

The goal: Make it easier to do the secure thing than to bypass the process.

The Balance You’re Seeking

Alex, here’s my advice for finding your personal balance:

1. Invest in Security Fundamentals
Dedicate time to understanding common vulnerabilities. It’s now a core skill for AI-assisted development.

2. Use AI Where Risk Is Low
Tests, documentation, boilerplate, refactoring for readability - AI is great here.

3. Write Critical Code Manually
Auth, payments, sensitive data handling - do this yourself or with heavy oversight.

4. Build Your Review Checklist
Start simple. Add to it as you learn. Make it habitual.

5. When Unsure, Get Security Review
Better to ask for security review and learn than to ship a vulnerability.

6. Measure Your Own Outcomes
Track: How often do you catch issues in your own AI-generated code? Are you getting better at spotting problems earlier?

The Long-Term Vision

Our industry is figuring this out in real-time. There’s no established playbook yet.

But the organizations that will succeed are those that:

Accept AI tools as permanent parts of the toolkit
Build verification processes that scale
Invest in developer security education
Measure security outcomes, not just velocity
Adapt quickly as tools and threats evolve

The 45% vulnerability rate is alarming, but it’s solvable with process, education, and cultural commitment to security.

We don’t need to choose between AI productivity and security. We need to build systems that enable both.