The Irony of AI-Assisted Development: Are We Trading Speed for Long-Term Tech Debt?

General
1

Leading the digital transformation of our legacy banking systems has been the most challenging project of my career. When our team started adopting AI coding assistants like GitHub Copilot and Cursor six months ago, I was cautiously optimistic. The initial metrics looked incredible - 30% faster feature delivery, junior developers suddenly productive on complex modules, code reviews moving faster.

But here’s the irony we’re now confronting: AI-assisted development might be trading short-term velocity for long-term technical debt in ways our traditional measurement tools can’t even detect.

The Initial Wins Were Real

In the first three months, the productivity gains were undeniable. Junior engineers who previously struggled with boilerplate could scaffold entire API endpoints. Senior developers offloaded repetitive refactoring to AI. Our velocity charts looked better than they had in years. Leadership was thrilled.

I remember one sprint where we delivered 40% more story points than our historical average. The code looked clean, tests passed, PR reviews found nothing obviously wrong. We thought we’d found the silver bullet.

The Problems Emerging After Six Months

Then the cracks started showing. Features that shipped quickly started accumulating bug reports weeks later. Not crashes or obvious failures - subtle issues. A search feature that worked but performed terribly at scale. An authentication flow that passed tests but created race conditions under load. Error handling that looked comprehensive but masked underlying problems.

The pattern became clear: AI suggestions optimized for “looks right” rather than “works correctly in our specific system.” Here are three specific examples that cost us:

1. The Bypass Pattern: AI suggested a quick fix for a validation issue that bypassed our established error handling framework. It worked for that endpoint, but created an inconsistency that confused engineers working on related features later. Six weeks later, we had four different error handling patterns across the codebase.

2. The Hidden Complexity: An AI-generated data transformation looked elegant - clean functional programming, well-named variables. But it nested six levels of array operations that were impossible to debug when production data caused unexpected behavior. A human engineer would have broken it into steps with intermediate logging.

3. The Test Deception: AI generated comprehensive-looking unit tests that passed consistently. The problem: they tested implementation details, not behavior. When we needed to refactor for performance, the tests blocked us rather than protecting us. We had high coverage but low confidence.

The Measurement Challenge

Here’s what’s keeping me up at night: traditional technical debt tools like SonarQube don’t capture what I’m calling “AI-generated debt.” The code passes linting, has decent complexity scores, looks maintainable on static analysis. But it lacks the architectural coherence that comes from human understanding of our system.

We tried measuring maintainability by tracking time-to-modify for AI-assisted vs human-written code. The results were sobering: features built with heavy AI assistance took 60% longer to modify three months after initial implementation. Not because the code was bad - because it didn’t fit our mental model of how the system worked.

Our Response: New Guardrails

We’ve implemented several changes to our development process:

Mandatory Architecture Alignment: Before accepting any AI suggestion that touches core logic, engineers must document how it fits our established patterns. This slows down initial implementation but prevents drift.

PR Review Guidelines: Reviews now explicitly check for “AI-generated patterns that bypass our conventions.” We look for code that works but doesn’t match how we’d normally solve the problem.

Knowledge Transfer Requirements: Any feature built with significant AI assistance requires a design doc explaining the approach in human terms, not just code comments. This captures the “why” that AI can’t provide.

Refactoring Budget: We allocate 15% of each sprint to refactoring AI-assisted code after it’s been in production for 30 days. This catches maintainability issues before they compound.

The Uncomfortable Truth

After six months of experience, here’s my honest assessment: AI coding assistants make it easier to write code but harder to maintain systems. The velocity gains are real but come with a hidden cost in architectural coherence and long-term maintainability.

I’m not saying we should stop using AI - the productivity benefits are too significant, and this technology will only improve. But we need to acknowledge that we’re in uncharted territory. We’re the first generation of engineering leaders managing teams where a significant percentage of code is AI-generated.

Questions for the Community

I’m curious how others are navigating this:

  • Are you seeing similar patterns of “clean but unmaintainable” code from AI tools?
  • What metrics are you using to measure the long-term impact of AI-assisted development?
  • How are you balancing velocity gains against maintainability concerns?
  • Have you found effective ways to teach AI tools your architectural patterns?

The financial services industry moves slowly on technology adoption for good reason. But AI coding assistants are already in use across our teams, sanctioned or not. We need to get ahead of the technical debt implications before they become crisis-level problems.

I’d love to hear if others are experiencing this, or if our experience is unique to legacy financial systems with strict architectural requirements.

2

This hits close to home. We’re experiencing the exact same pattern on my team, and I started tracking metrics about two months ago because something felt off despite the velocity improvements.

Here’s what we found: I split our codebase analysis into two cohorts - features shipped in Q4 2025 (pre-AI adoption) versus Q1 2026 (heavy Copilot usage). Then tracked time-to-fix-bugs discovered 30, 60, and 90 days post-deployment.

The data is sobering:

  • 30 days: AI-assisted code had 1.8x more bugs discovered
  • 60 days: 2.1x more bugs
  • 90 days: 2.3x more bugs

What’s interesting is the pattern of bugs. Human-written code tends to fail fast - obvious issues caught in first two weeks. AI-assisted code has this long tail of subtle issues that emerge as edge cases hit production or when other systems interact with it in unexpected ways.

Your “looks right vs works in our system” observation is spot-on. The core issue is that AI optimizes for passing the immediate context - the function signature, the test case, the error message - but has zero understanding of the larger system architecture.

A Specific Example That Cost Us

We have an established pattern for async job processing: jobs go through a validation layer, then get queued with retry logic, then execute with comprehensive error handling. It’s verbose but battle-tested over three years of production use.

Copilot suggested a “cleaner” implementation for a new job type - used promises directly, elegant error handling with async/await, looked like modern JavaScript best practices. Code review passed because it was technically correct and well-tested.

Two months later: production incident. The job failed in a way our monitoring didn’t catch because it bypassed our standard error handling. Took 4 hours to debug because the failure mode wasn’t in our runbooks - we’d never seen that pattern before. The AI-generated code worked perfectly for the test cases but broke our operational assumptions.

What We Changed

Your guardrails are similar to what we’re implementing:

Senior Review for Architectural Changes: If an AI suggestion touches core patterns (auth, data access, job processing, API contracts), it must be reviewed by a senior engineer who understands the historical context. This adds 1-2 days to PR cycle but prevents architectural drift.

Explicit AI Labeling: Developers must comment // AI-assisted on code blocks where they accepted AI suggestions with minimal modification. During code review, these sections get extra scrutiny for “fits our patterns” rather than just “works correctly.”

Pattern Documentation: We’re building a library of “approved AI patterns” - examples of how to use AI tools within our architectural constraints. For example: “Use Copilot for test boilerplate, but write assertion logic manually” or “AI can suggest data validation logic, but must use our existing validator framework.”

Regression Testing Focus: For AI-assisted features, we require integration tests that verify behavior at the system level, not just unit tests. This catches the “works in isolation, fails in context” problems earlier.

The Uncomfortable Metrics

The part that’s hard to communicate to leadership: we’re still shipping 25% faster than pre-AI, even with the extra review overhead. But maintainability metrics are declining.

I started tracking a “modification coefficient” - how much time it takes to modify a feature versus initial implementation time. Pre-AI average was 0.4x (modifying took 40% as long as building). Post-AI it’s 0.65x. We’re building faster but modifying slower.

The economic question nobody’s asking: at what point does the maintainability cost exceed the velocity benefit? I suspect we’re approaching that inflection point but don’t have enough data yet.

What Still Works Well

Not all AI assistance is problematic. We’ve found certain tasks where AI genuinely helps without creating debt:

  1. Test boilerplate: Generating test setup code, mock objects, standard assertion patterns - high value, low risk
  2. Type definitions: Adding TypeScript types to untyped code - AI is excellent at inferring types from usage
  3. Documentation: Converting code into explanatory comments - helpful for knowledge transfer
  4. Migration scripts: One-time data transformations where maintainability isn’t a concern
  5. Repetitive refactoring: Renaming variables consistently, updating import statements - mechanical changes

The pattern: AI excels at mechanical transformations and boilerplate, struggles with domain logic and architectural decisions.

The Question I’m Wrestling With

Your question about teaching AI tools our architectural patterns is the right one. Currently it feels like fighting the tool - Copilot wants to suggest “clean” generic patterns, we want it to suggest “our specific patterns that look ugly but handle edge cases.”

I’ve experimented with adding architectural guidelines in code comments, thinking Copilot would learn from context. Mixed results. It helps for local patterns (how we structure React components) but doesn’t help for system-level patterns (how services interact).

Has anyone found effective ways to “train” AI coding assistants on codebase-specific conventions? Or are we stuck with the current approach of “let AI suggest, then manually verify fits our architecture”?

The bigger question: are we in a temporary adjustment period while we learn to work with AI, or is “AI-generated debt” a permanent new category of technical debt we’ll be managing for the next decade?

3

This resonates deeply from the design systems perspective, and I think there’s a parallel problem happening on the UI side that nobody’s talking about.

We maintain a design system with approved component patterns - buttons, forms, modals, data tables. Clear guidelines, extensive documentation, Storybook with examples. The goal: consistent UX, accessible patterns, maintainable code.

AI code generation tools completely ignore this.

The Pattern We’re Seeing

Developer needs a data table. Instead of using our <DataTable> component from the design system, Copilot suggests building a custom table with Tailwind classes. The code looks modern - uses flexbox, responsive breakpoints, clean styling. Reviews pass because it works and looks good.

Six months later: we have 12 different table implementations across the product. None follow our accessibility patterns. None use our design tokens for spacing/colors. When we need to update the table design system-wide, we can’t - we’d have to manually update 12 different implementations.

This is design debt, and it’s compounding faster than code debt.

The Root Cause

AI tools pattern-match from internet examples, not from your codebase. Stack Overflow and GitHub examples don’t use your design system - they use one-off solutions. So that’s what AI suggests.

I’ve tried multiple approaches to fix this:

Approach 1: Added comments to our component files like “// USE THIS COMPONENT - don’t create custom tables”. Copilot ignored them. The autocomplete context window apparently doesn’t include those files unless they’re already imported.

Approach 2: Created templates in our docs like “When you need a table, start with: import { DataTable } from ‘@/components’”. Developers see the docs, but when they’re coding, Copilot suggests the “easier” inline solution and they take it.

Approach 3: Added ESLint rules to catch non-approved patterns. This works but feels like fighting the AI tool. We catch violations in CI, developer has to rewrite, everyone’s frustrated.

The Accessibility Nightmare

The design debt is bad enough, but the accessibility implications are worse.

Our design system components have built-in ARIA labels, keyboard navigation, screen reader support, focus management. Years of work making our product accessible.

AI-generated components look visually identical but lack all of this. They work fine if you can see and use a mouse. They’re completely broken for keyboard navigation or screen readers.

We caught this during an accessibility audit last month. 8 new features shipped in Q1, all with Copilot-generated UI components, all failing WCAG 2.1 AA standards. Features that would have been accessible if developers used our design system were shipped inaccessible because AI suggested “simpler” implementations.

The business risk: we work with government clients who require accessibility compliance. These AI-generated accessibility gaps could cost us contracts.

What We’re Trying Now

Your approach of “AI-assisted code labels” is interesting. We implemented something similar but for components:

Component Review Checklist: PR template now includes:

  • Uses approved design system components (or documents why not)
  • If custom component needed, accessibility tested
  • Follows design token system for spacing/colors
  • Responsive design matches design system breakpoints

Lint Rules for Common Violations: We added custom ESLint rules that flag:

  • className with hard-coded colors (should use design tokens)
  • Table elements without our <DataTable> wrapper
  • Form inputs without our <Input> wrapper
  • Modal/dialog implementations (should use our <Modal> component)

The rule violations link to our design system docs, so it’s educational rather than just blocking.

Design System PR Bot: Built a bot that comments on PRs analyzing component usage. If you import components from the design system, it says “Great use of design system components!”. If you build custom UI, it suggests design system alternatives. It’s educational, not blocking, but creates visibility.

The Hard Conversation

Here’s the discussion I had with our engineering leadership last week:

“AI tools are making individual developers faster, but making the design system team slower. We spend 40% of our time now reviewing PRs for design system violations and helping teams refactor AI-generated code to use approved components. Pre-AI, that was 10% of our time.”

The economic question: if AI makes 50 product engineers 20% faster, but makes 3 design system engineers 300% slower, what’s the net productivity impact?

Nobody has a good answer because we don’t measure cross-team efficiency, just individual velocity.

The Root Issue: AI Doesn’t Understand ‘Why’

Your point about AI not capturing the “why” is exactly right. Our design system exists because we learned painful lessons:

  • Custom date pickers break in Safari
  • Hand-coded modals trap focus incorrectly
  • DIY autocompletes don’t handle keyboard navigation
  • Custom tables don’t work with screen readers

These lessons took years and real user feedback to learn. They’re encoded in our component library as institutional knowledge.

AI tools have zero context for this. They see: “Oh, you need a date picker, here’s clean React code for one!” And it works great in demo, breaks in production, excludes users with disabilities.

Question for the Group

Luis, you mentioned requiring design docs for AI-assisted features. Does that help capture the “why we made this architectural choice” that’s lost in AI-generated code?

I’m wondering if we need similar documentation requirements: “If you build a custom component instead of using the design system, document why the design system component doesn’t work for your use case.”

The goal: either we improve the design system to handle the use case, or we capture why this is a legitimate exception. Either outcome is better than silent proliferation of custom implementations.

Has anyone found effective ways to make AI tools respect existing component libraries and design systems? Or are we stuck in a world where AI makes writing code easy but makes maintaining consistent UX impossible?

4

Both of you are describing the organizational challenge I’m dealing with right now, and it’s one of the hardest leadership problems I’ve faced in 16 years.

The core tension: AI coding tools make individual contributors feel more productive and autonomous. They love it. But they’re creating system-level complexity that makes the entire organization slower over time. And measuring that tradeoff is incredibly difficult.

The Productivity Paradox

Here’s what I’m seeing in our EdTech startup as we scale from 25 to 80+ engineers:

Individual Level: Engineers report feeling 25-40% more productive with AI tools. They ship features faster, feel less blocked by boilerplate, can contribute to areas outside their core expertise.

Team Level: Teams are shipping 15-20% more story points per sprint. Velocity charts look great. Leadership sees the metrics improving.

Organizational Level: We’re spending 20% more engineering time on code review than we did 12 months ago. Cross-team integration is taking longer. Bug fix cycles are stretching out. Overall system maintainability is declining.

The productivity gains are real at the individual level, but they’re creating costs at the organizational level that aren’t captured in our metrics.

The Junior Engineer Problem

Luis, your point about junior engineers being “suddenly productive on complex modules” is exactly what worries me.

Pre-AI: Junior engineer encounters complex module, asks senior for guidance, learns architectural patterns, ships feature slowly but correctly aligned with our conventions.

Post-AI: Junior engineer encounters complex module, Copilot suggests working code, ships feature quickly, moves to next task. Feature works but doesn’t match our patterns. Senior engineers discover misalignment weeks later during integration or incident response.

The learning opportunity disappeared. The junior engineer never developed the mental model of how our system works because AI shielded them from the complexity.

I’m now seeing junior engineers with 18 months tenure who can ship features quickly but can’t explain our architecture, can’t debug cross-system issues, and struggle when AI suggestions don’t work.

We’re trading long-term engineering capability for short-term velocity, and I don’t know how to measure that cost.

The Review Burden Reality

Maya, your point about design system team spending 40% of time on reviews hits hard. We have the same pattern across multiple dimensions:

Security Reviews: Our security team is now involved in 3x more PR reviews because AI-generated code bypasses our security patterns. Code that looks clean but has subtle auth/crypto issues.

Architecture Reviews: Our principal engineers spend 2-3 hours daily reviewing AI-assisted code for architectural fit, up from maybe 30 minutes pre-AI. The pattern: code works, tests pass, but doesn’t match how we’d normally solve the problem.

Documentation Reviews: AI-generated code often has inline comments but no design docs explaining the approach. Senior engineers have to reverse-engineer intent during reviews.

The economic question is exactly what you identified: if AI makes 60 product engineers 20% faster but makes 8 senior/principal engineers 200% slower, what’s the net impact on organizational throughput?

What We’re Implementing

Based on hard lessons over the past 6 months:

1. AI-Assisted Code Labels in PRs
Developers must mark sections where they accepted AI suggestions with minimal review. PR template includes:

  • AI-assisted code sections marked
  • AI suggestions validated against architecture docs
  • For core logic, design doc explains approach

This makes AI usage visible and creates accountability.

2. Tiered Review Requirements

  • Boilerplate/tests: Standard peer review
  • Feature logic: Senior engineer review
  • Core systems/security: Principal + security team review

AI-assisted code in higher tiers requires explaining why AI suggestion fits our patterns.

3. Onboarding Changes
New engineers spend first 2 weeks learning system architecture WITHOUT AI tools. They must ship one feature manually, with senior mentoring, before enabling Copilot.

The goal: build mental models first, then use AI to accelerate within those models.

4. Monthly Architecture Reviews
We gather the team monthly to review “architectural drift” - places where AI suggestions led us away from our patterns. We decide: update our patterns, or refactor the AI-generated code.

This creates feedback loops and keeps drift from compounding.

5. Refactoring Budget
15% of each sprint dedicated to refactoring AI-assisted code that’s been in production 30-60 days. This catches maintainability issues before they become critical.

The Hard Metrics Question

Alex, your “modification coefficient” metric is brilliant - ratio of time-to-modify versus time-to-implement. I’m adding that to our dashboards.

We’re also tracking:

  • Integration time: How long features spend in integration testing (increasing)
  • Bug discovery timeline: When bugs are found post-deployment (shifting later)
  • Cross-team dependency resolution: Time to resolve integration issues (increasing)
  • Senior engineer review load: Hours per week on PR reviews (increasing significantly)

These are leading indicators that individual velocity gains are creating organizational drag.

The Cultural Challenge

Here’s the conversation I’m having with our team that’s really uncomfortable:

“AI tools make you feel faster and more autonomous. That feels good. But if everyone optimizes for individual speed without architectural alignment, we create a system that’s harder for everyone to work in. Your individual productivity comes at the cost of collective productivity.”

This is hard to communicate because engineers can see their individual metrics improving but can’t see the system-level costs they’re creating.

Some engineers get defensive: “Are you saying we shouldn’t use AI tools?” No, we should use them strategically. “Are you saying AI makes us worse engineers?” No, but it changes what we need to be good at.

The new skill isn’t “write code faster with AI”, it’s “use AI within architectural constraints” and “know when to reject AI suggestions that don’t fit our system.”

The Question I Can’t Answer Yet

Is this a temporary adjustment period while we learn to work effectively with AI tools? Or is this the new permanent state - AI enables individual velocity but requires significantly more organizational coordination overhead?

I suspect we’re in the awkward middle phase. Eventually, maybe we develop better patterns, better tooling, better training for “AI-assisted development done well.” But right now, it feels like we’re figuring it out the hard way.

Luis, how are you handling the cultural conversations in financial services where architectural discipline is even more critical? Are your teams receptive to the guardrails, or is there pushback?

Maya, your accessibility example is particularly sobering. Have you found ways to educate engineers about why the design system exists before they reach for AI-generated alternatives?

5

Reading this thread from the security perspective is genuinely alarming, and I need to add a critical dimension that hasn’t been discussed yet: AI-generated code is creating new classes of security vulnerabilities that our existing security tools and processes aren’t catching.

The Pattern Recognition Problem

AI coding assistants are trained on massive corpuses of code from GitHub, Stack Overflow, tutorials, etc. The problem: a significant portion of that training data contains security vulnerabilities.

When you ask Copilot to help with authentication, it pattern-matches from millions of examples. Many of those examples have subtle auth flaws, injection vulnerabilities, or insecure defaults. The AI doesn’t know which patterns are secure - it just knows which patterns are common.

Three Real Incidents from Last Month

Incident 1: The JWT Token Vulnerability

Developer building new API endpoint, used Copilot to generate JWT token validation. Code looked clean:

const decoded = jwt.decode(token);
if (decoded.userId === requestUserId) {
  // authorize request
}

Passed code review because it looked reasonable. Shipped to production.

The vulnerability: jwt.decode() doesn’t validate signatures, just decodes. Anyone could create a fake JWT with any userId. Should have been jwt.verify() with secret key.

Our security scanner didn’t catch it because the code had no obvious SQL injection or XSS patterns. Discovered during penetration testing two weeks later.

Incident 2: The SQL Injection That Wasn’t Obvious

Copilot suggested code for a search feature:

const query = `SELECT * FROM users WHERE name LIKE '%${searchTerm}%'`;

Senior engineer caught it in review, asked for parameterized query. Developer updated to:

const query = db.query('SELECT * FROM users WHERE name LIKE ?', [`%${searchTerm}%`]);

Looks good, right? Still vulnerable. The problem: LIKE patterns with user input can cause performance DoS. Should sanitize searchTerm for wildcard characters, add query timeouts, implement rate limiting.

AI generated “technically parameterized” code that passed review but still had security implications.

Incident 3: The Crypto Random That Wasn’t

Password reset token generation:

const resetToken = Math.random().toString(36).substring(2, 15);

AI suggested this pattern because it’s common in tutorials. Problem: Math.random() is not cryptographically secure. Should use crypto.randomBytes().

This is a subtle vulnerability that wouldn’t be exploited immediately but could enable account takeovers at scale.

Why This Is Different From Normal Code Review

Pre-AI: Security vulnerabilities came from junior developers not knowing secure patterns, or senior developers making mistakes under time pressure.

Post-AI: Security vulnerabilities come from AI suggesting common-but-insecure patterns that look clean and pass basic review.

The difference: AI-generated insecure code looks professional, has consistent style, includes comments, passes linting. It doesn’t have the “code smell” that experienced reviewers use to spot junior mistakes.

The Cultural Problem

Keisha mentioned the “junior engineer problem” - this is even worse for security.

Junior engineer using AI feels empowered: “I just implemented OAuth integration by myself!” They don’t realize the AI-generated OAuth flow has insecure state handling that enables CSRF attacks.

They ship it, it works in testing, nobody catches the security issue until a pentester finds it or we get breached.

The psychological effect: AI makes developers overconfident in their ability to handle complex security-critical code. They don’t know what they don’t know, and AI doesn’t tell them.

Our Response: Security Review Gates

We’ve implemented mandatory security review for any AI-assisted code that touches:

  • Authentication/authorization
  • Cryptographic operations
  • Data validation/sanitization
  • External API calls with credentials
  • File uploads/downloads
  • Payment processing
  • Any PII handling

If the PR description indicates AI assistance in these areas, it must be reviewed by someone on the security team before merge.

This has increased our security review load by 300%. We have 2 security engineers covering a 40-person engineering org. The math doesn’t work.

The Tooling Gap

Luis mentioned that SonarQube doesn’t catch “AI-generated debt” - the same is true for security.

Our static analysis tools check for known vulnerability patterns (SQL injection, XSS, etc.). They don’t check for “technically correct but insecure in context” patterns that AI generates.

Example: Our security scanner sees parameterized queries and marks them safe. Doesn’t catch that the LIKE pattern with user input is a DoS risk.

We need new classes of security tools that understand “this code is syntactically correct and uses safe APIs, but the way it’s combining them creates vulnerabilities.”

I haven’t seen any vendors addressing this yet. It’s a blind spot in the security tooling ecosystem.

What I’m Trying

1. Security-Specific AI Prompts

Working on a library of “secure prompts” - when developers need AI help with auth/crypto/validation, they use our prompts that include security context.

Example: “Generate JWT validation code using jwt.verify() with secret from environment variable, including error handling for expired/invalid tokens.”

Still experimental. Hard to enforce.

2. Pre-Commit Security Hooks

Custom pre-commit hooks that scan for common AI-generated security antipatterns:

  • jwt.decode() without surrounding jwt.verify()
  • Math.random() in security contexts
  • String interpolation in SQL queries (even if parameterized elsewhere)
  • Missing CSRF tokens in form submissions
  • Etc.

Catches maybe 30% of issues. Better than nothing.

3. Security Training Focused on AI Tools

Updated our security training to include:

  • “Common vulnerabilities in AI-generated code”
  • “When to reject AI suggestions in security contexts”
  • “Required security patterns that must be used even if AI suggests alternatives”

Too early to know if it’s working.

The Honest Assessment

AI coding tools are making our security posture worse, not better. The productivity gains aren’t worth the security risks in domains like fintech where breaches can be catastrophic.

I’m advocating internally for stronger gates: ban AI tools in security-critical code paths, require security architecture design before implementing any auth/crypto features, mandatory security review for all AI-assisted code.

Getting pushback from engineering leadership because it slows velocity. Having difficult conversations about acceptable risk.

Questions for the Group

  1. For Luis (financial services): How are regulators thinking about AI-generated code in security audits? Do you have to disclose which code was AI-assisted?

  2. For Keisha: How do you balance security team capacity versus AI-accelerated development velocity? We’re bottlenecked on security reviews.

  3. For everyone: Has anyone found security-focused AI coding tools that actually help rather than creating vulnerabilities? Or are we just stuck with “AI generates, humans verify” which doesn’t scale?

This feels like a moment similar to when we realized “move fast and break things” doesn’t work for security. We need “AI-assisted development” patterns that prioritize security over velocity, but I don’t see the industry moving that direction yet.