Módulo 1: Solo 3% Confía — Por Qué y Qué Hacer

Dos Extremos Peligrosos

Siguiente →

Dos Extremos Peligrosos

Descripción de la cápsula

Cuando un developer empieza a usar AI coding tools, tiende a caer en uno de dos extremos: aceptar todo lo que genera ("funciona, ship it") o rechazar AI por completo ("no confío en código que no escribí"). Ambos extremos parecen razonables. Ambos son profesionalmente peligrosos. En esta cápsula vas a entender por qué, con ejemplos concretos de cómo cada extremo afecta tu trabajo.

El punto no es juzgar — es reconocer. Si te identificas con alguno de los extremos, no es un defecto. Es un patrón natural que casi todos experimentan. Lo que importa es que lo reconozcas y avances hacia el punto medio: confianza calibrada.

Extremo 1: Aceptar Todo

El patrón

Developer pide → AI genera → "Se ve bien" → Acepta → Commit → Push

Sin revisión significativa.
Sin verificación de lógica.
Sin chequeo de seguridad.

Por qué es tentador

  • Velocidad. Revisar toma tiempo. Aceptar es inmediato.
  • Confianza en la herramienta. "Claude Code es de Anthropic, debe saber lo que hace."
  • Sesgo de confirmación. El código se ve bien, funciona en el happy path, y no quieres buscar problemas.
  • Presión de tiempo. Deadlines reales hacen que "funciona" sea suficiente.
  • El efecto de la primera impresión. Código bien formateado con buenos nombres de variables parece correcto. AI es muy buena generando código que se ve profesional.

El peligro concreto

Veamos un ejemplo real de lo que puede pasar:

# Claude Code generó este endpoint de login
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import jwt
import hashlib

app = FastAPI()

SECRET_KEY = "my-super-secret-key-2024"

class LoginRequest(BaseModel):
    email: str
    password: str

@app.post("/login")
async def login(request: LoginRequest):
    user = get_user_by_email(request.email)
    if not user:
        raise HTTPException(status_code=401, detail="Invalid credentials")
    
    password_hash = hashlib.md5(request.password.encode()).hexdigest()
    if password_hash != user.password_hash:
        raise HTTPException(status_code=401, detail="Invalid credentials")
    
    token = jwt.encode(
        {"user_id": user.id, "email": user.email},
        SECRET_KEY,
        algorithm="HS256"
    )
    
    return {"access_token": token, "token_type": "bearer"}

A primera vista se ve profesional. FastAPI, Pydantic, JWT. Pero tiene 4 problemas graves:

Problema 1: SECRET_KEY hardcoded en el código
→ Cualquiera que vea el repo tiene tu secret
→ Consecuencia: pueden forjar tokens JWT válidos

Problema 2: MD5 para password hashing
→ MD5 es inseguro para passwords (rainbow tables)
→ Debería usar bcrypt o argon2
→ Consecuencia: passwords crackeables en minutos

Problema 3: Token sin expiración
→ El JWT no tiene campo "exp"
→ Un token robado es válido para siempre
→ Consecuencia: compromiso permanente de la cuenta

Problema 4: No valida formato de email
→ Acepta "no-soy-email" como email válido
→ Consecuencia: datos inconsistentes en base de datos

Un developer que acepta este código sin revisar acaba de introducir 4 vulnerabilidades de seguridad. Y el código funciona perfectamente en el happy path — login correcto devuelve token, login incorrecto devuelve 401.

Síntomas de que estás en este extremo

  • ✅ Aceptas output de Claude Code si no tiene errores de sintaxis
  • ✅ Tu criterio principal es "¿funciona?" no "¿es correcto?"
  • ✅ No recuerdas la última vez que rechazaste una sugerencia de AI
  • ✅ Nunca has encontrado un bug en código AI-generated (probablemente no los buscas)
  • ✅ Tu velocidad de aceptación es < 30 segundos para cualquier cantidad de código

Extremo 2: Rechazar Todo

El patrón

Developer pide → AI genera → "No confío" → Reescribe todo → Commit → Push

Usa AI como brainstorming pero reescribe cada línea.
O directamente no usa AI por desconfianza.

Por qué es tentador

  • Control. Si lo escribes tú, lo entiendes todo.
  • Experiencias previas. Una vez AI generó algo incorrecto y ahora no confías.
  • Orgullo profesional. "Un buen developer escribe su propio código."
  • Perfeccionismo. El código AI no es exactamente como lo harías tú.
  • Miedo a lo desconocido. No entiendes cómo genera el código, entonces no confías.

El peligro concreto

Veamos el costo real:

Escenario: Construir un CRUD API con 5 endpoints

Sin AI:
- Escribir modelos: 45 min
- Escribir endpoints: 1.5 hrs
- Escribir validaciones: 1 hr
- Testing manual: 30 min
- Total: ~3.5 hrs

Con AI (aceptando todo sin revisar):
- Prompt + aceptar: 15 min
- Total: 15 min (pero con 4 bugs)

Con AI (confianza calibrada):
- Prompt: 5 min
- Revisar lógica de negocio: 20 min
- Verificar seguridad: 15 min
- Ajustar 2 issues encontrados: 10 min
- Total: 50 min (sin bugs significativos)

Con AI (rechazando todo):
- Prompt: 5 min
- Leer output, descartarlo: 10 min
- Reescribir todo manualmente: 3 hrs
- Total: 3.25 hrs (mismo resultado que sin AI)

El developer que rechaza todo gasta casi lo mismo que sin AI. Tiene la herramienta pero no la usa.

El costo oculto

No es solo tiempo. Es oportunidad:

Developer A (confianza calibrada):
- Genera CRUD con AI: 50 min
- Usa el tiempo restante para:
  - Mejorar la arquitectura
  - Escribir tests más completos
  - Documentar edge cases
  - Implementar feature adicional
  
Developer B (rechaza todo):
- Reescribe CRUD manualmente: 3.5 hrs
- No le queda tiempo para:
  - Mejoras de arquitectura
  - Tests exhaustivos
  - Documentación
  - Features adicionales

El developer que rechaza AI no solo pierde velocidad — pierde la oportunidad de invertir tiempo en trabajo de mayor valor.

Síntomas de que estás en este extremo

  • ✅ Usas AI para generar código pero reescribes la mayoría
  • ✅ Te cuesta aceptar código que tú no escribiste, de cualquier fuente
  • ✅ Tu argumento principal es "yo lo haría diferente"
  • ✅ Pasas más tiempo modificando output AI que usándolo
  • ✅ Sientes que usar AI es "hacer trampa" o es para "juniors"

Comparación: Los Dos Extremos vs El Punto Medio

CriterioAcepta TodoRechaza TodoConfianza Calibrada
VelocidadMáximaMínimaAlta
CalidadImpredecibleConsistente (tu nivel)Consistente (tu nivel + AI)
RiesgoAlto (bugs ocultos)BajoBajo
ProductividadAlta aparente, baja realBajaAlta real
AprendizajeBajo (no revisas)MedioAlto (revisas y aprendes)
SostenibilidadNo (problemas acumulan)No (burnout por velocidad)Sí
SecurityPeligrosoDepende de tiVerificado

La trampa de la "velocidad"

El extremo de aceptar todo parece más productivo. Pero la productividad real incluye el costo de bugs, fixes, y refactorizaciones:

Productividad real = 
  (Velocidad de generación) 
  - (Tiempo de debugging de bugs ocultos)
  - (Tiempo de refactorización)
  - (Impacto de security issues)
  - (Deuda técnica acumulada)

Cuando incluyes estos costos, el extremo de aceptar todo es frecuentemente MENOS productivo que el punto medio.

Cómo Se Manifiestan en el Día a Día

Escenario 1: Feature request urgente

Acepta todo: "Claude Code, genera el endpoint. Listo, funciona, PR creado." Rechaza todo: "Deja que lo piense y lo escriba yo. Me toma 3 horas pero lo hago bien." Calibrado: "Claude Code, genera el endpoint. Reviso auth y lógica de negocio — bien. Los validations están incompletos, los ajusto. PR creado en 45 min."

Escenario 2: Bug en producción

Acepta todo: "Claude Code, fix this bug." → Acepta el fix sin verificar → Puede crear bug nuevo. Rechaza todo: Investiga manualmente por 2 horas. Debuggea sin AI. Encuentra el bug pero tarda mucho. Calibrado: "Claude Code, analiza este stack trace." → Lee la explicación, verifica la hipótesis → Implementa fix verificado.

Escenario 3: Refactoring de módulo

Acepta todo: "Claude Code, refactoriza este módulo." → Acepta 200 líneas nuevas sin revisión. Rechaza todo: Refactoriza manualmente línea por línea. 4 horas. Calibrado: "Claude Code, refactoriza este módulo." → Revisa que la API pública no cambió, que los tests pasan, que la lógica core es correcta. Ajusta 3 detalles. 1.5 horas.

El Espectro Real

Los extremos son los polos de un espectro:

Acepta Todo ←————————————————————→ Rechaza Todo
     |         |         |         |
     0%       25%       50%       75%      100%
   revisión  revisión  revisión  revisión  revisión

   ←— Peligro          Óptimo          Peligro —→
                      (varía por
                    tipo de tarea)

El punto óptimo no es fijo — varía por tipo de tarea:

Boilerplate:     10-20% revisión (confía más)
CRUD:            30-40% revisión
Business Logic:  60-80% revisión
Auth/Security:   80-100% revisión (confía menos)

Troubleshooting

Problema 1: "Me identifico con aceptar todo y no sé cómo cambiar"

Causa: Hábito de velocidad sobre calidad. Solución: Empieza con una regla simple: antes de aceptar, hazte 3 preguntas: (1) ¿Tiene lógica de negocio? Revísala. (2) ¿Toca seguridad? Revísala exhaustivamente. (3) ¿Es boilerplate? OK, acepta. Gradualmente añade más preguntas.

Problema 2: "Me identifico con rechazar todo y me siento lento"

Causa: Miedo a perder control o experiencia negativa previa. Solución: Prueba con tareas de bajo riesgo. Genera un README.md o un script de setup con Claude Code. Revísalo rápidamente. Si está bien, acéptalo. Construye confianza gradualmente, empezando por lo de menor riesgo.

Problema 3: "Oscilo entre ambos extremos según el día"

Causa: Falta de framework — tu decisión depende del humor, no del criterio. Solución: Eso es normal. El framework que construirás en la cápsula 05 elimina la variabilidad. Tendrás criterios claros que no dependen de cómo te sientas ese día.

Ejercicios

Ejercicio 1: Identificar el extremo (Fácil)

Para cada escenario, identifica si el developer está en el extremo de "aceptar todo" o "rechazar todo":

Escenario A: María le pide a Claude Code que genere tests para su API. Recibe 15 test cases. Los ejecuta, todos pasan, y hace commit.

Escenario B: Carlos le pide a Claude Code que genere un helper de validación de emails. Recibe una función de 20 líneas. La borra y escribe su propia versión de 18 líneas que hace exactamente lo mismo.

Escenario C: Ana le pide a Claude Code que genere un Dockerfile. Lo lee rápidamente, ve que usa la imagen correcta y los comandos estándar, y lo acepta.

Ver solución

A: Acepta todo. Que los tests pasen no significa que testan lo correcto. Tests AI-generated pueden tener assertions triviales o no cubrir edge cases. María debería verificar que los tests validan la lógica correcta, no solo que ejecutan sin error.

B: Rechaza todo. Carlos gastó tiempo reescribiendo algo que era prácticamente idéntico. Si el output era correcto, debería haberlo aceptado (quizá con ajustes menores).

C: Confianza calibrada. Ana revisó lo relevante (imagen, comandos) para un tipo de tarea de bajo riesgo (Dockerfile) y aceptó. Esto es calibración correcta — revisión proporcional al riesgo.

Ejercicio 2: Calcular el costo real (Medio)

Un equipo de 5 developers usa Claude Code. Cada developer genera código AI un promedio de 8 veces al día. Calcula el costo semanal en cada escenario:

  • Aceptar todo: 2 min por aceptación, pero 1 de cada 10 introduce un bug que toma 45 min arreglar
  • Rechazar todo: 30 min promedio reescribiendo cada output
  • Calibrado: 10 min promedio de revisión, 1 de cada 25 introduce un bug que toma 30 min arreglar
Ver solución

Por developer, por día (8 generaciones):

Aceptar todo:

  • Tiempo de aceptación: 8 × 2 min = 16 min
  • Bugs: 8/10 × 0.8 bugs/día × 45 min = 36 min de debugging
  • Total diario: 52 min
  • Semanal (×5 días): 260 min = 4.3 hrs

Rechazar todo:

  • Tiempo reescribiendo: 8 × 30 min = 240 min
  • Total diario: 240 min
  • Semanal: 1200 min = 20 hrs (¡medio tiempo laboral!)

Calibrado:

  • Tiempo de revisión: 8 × 10 min = 80 min
  • Bugs: 8/25 × 0.32 bugs/día × 30 min = 9.6 min de debugging
  • Total diario: ~90 min
  • Semanal: 450 min = 7.5 hrs

Para el equipo de 5 (semanal):

  • Aceptar todo: 21.5 hrs (pero con bugs acumulados)
  • Rechazar todo: 100 hrs (¡12.5 días laborales!)
  • Calibrado: 37.5 hrs

Conclusión: Calibrado es 2.7x más eficiente que rechazar todo, y 1.7x más que aceptar todo — sin contar el costo a largo plazo de bugs en producción.

Ejercicio 3: Tu plan de transición (Medio)

Si te identificas con uno de los extremos, escribe un plan de 3 pasos para moverte hacia el centro. Sé específico — no "revisar más" sino "antes de aceptar auth code, verificar que tokens expiren."

Ver solución

Si vienes de "aceptar todo":

  1. Esta semana: antes de aceptar cualquier código, verificar que no hay secrets hardcoded (buscar strings como "sk-", "password", API keys)
  2. Próxima semana: además del punto 1, para cualquier endpoint, verificar que tiene manejo de errores (try/except o HTTPException)
  3. Semana 3: además de 1 y 2, para lógica de negocio, leer la implementación completa y verificar contra los requisitos

Si vienes de "rechazar todo":

  1. Esta semana: aceptar sin modificar todo código que sea boilerplate (setup de proyecto, imports, configuración)
  2. Próxima semana: además del punto 1, aceptar CRUD endpoints si la estructura es correcta, solo modificar lógica específica
  3. Semana 3: para cada output, identificar qué porcentaje está bien antes de decidir reescribir. Si >70% está bien, edita en lugar de reescribir

La clave: Cambio gradual, no revolución. Mueve el dial 10-20% por semana.

Ejercicio 4: Debate interno (Difícil)

Un developer senior dice: "La única forma segura de usar AI code es revisarlo todo línea por línea. Si no lo revisas todo, es negligencia profesional." ¿Estás de acuerdo? Argumenta en contra con datos de esta cápsula.

Ver solución

Contraargumento:

  1. Revisar todo es económicamente inviable. Si un developer revisa cada línea de las 8 generaciones diarias de AI, gasta ~4 horas/día solo en revisión. Eso elimina el beneficio de productividad de AI tools.

  2. No toda línea tiene el mismo riesgo. Revisar import os línea por línea es desperdicio. Revisar token = jwt.encode(...) es esencial. La revisión debe ser proporcional al riesgo, no uniforme.

  3. El concepto de "negligencia" asume riesgo uniforme. Un doctor no hace un MRI para un resfriado. Un developer no debería hacer code review exhaustivo para boilerplate. La negligencia está en no revisar lo que importa, no en confiar en lo routine.

  4. Los datos muestran que calibración es más efectivo. El equipo calibrado (ejercicio 2) gasta 37.5 hrs/semana vs 100+ hrs si revisa todo, con calidad comparable. La eficiencia no es negligencia.

Nota: El senior tiene razón en UNA cosa — para código de alto riesgo (auth, security, business logic), la revisión exhaustiva es esencial. Pero generalizar eso a todo el código es impracticable.

Resumen

En esta cápsula aprendiste:

  • Extremo 1 (Aceptar todo) es peligroso: velocidad aparente que esconde bugs, security holes, y deuda técnica
  • Extremo 2 (Rechazar todo) es costoso: pierdes productividad y oportunidad sin ganar calidad significativa
  • Los dos extremos son reacciones naturales — no defectos. Lo que importa es reconocer dónde estás
  • El punto medio óptimo varía por tipo de tarea: más confianza para boilerplate, menos para auth/security
  • La productividad real incluye el costo de bugs y refactorizaciones — aceptar todo parece rápido pero no lo es
  • El cambio debe ser gradual: mueve el dial 10-20% por semana, no 100% de golpe

Próxima cápsula: Confianza Calibrada — el framework profesional para el punto medio.

Recursos Adicionales

  1. ACM Queue — The Cost of Code Review - Investigación sobre costos y beneficios de code review
  2. Microsoft Research — Developer Productivity with AI - Estudios sobre productividad con AI coding tools
  3. Google — Code Review Best Practices - Prácticas de code review de Google adaptables a AI code
  4. Anthropic — Claude Code Best Practices - Recomendaciones oficiales para verificar output
  5. The Pragmatic Programmer - Capítulo sobre herramientas y automatización con criterio

Debugging & Code Review with Claude Code — Módulo 1, Cápsula 03 Claude Code Agentic Development Path — Guía #6 de 11

← AnteriorLa Estadística del 3%Siguiente →Confianza Calibrada