← Volver al listado de tecnologías ← Índice de gstack

Cap 6: Skills de Implementación y Review

30 de marzo de 2026 Por: Artiko

gstackcode-reviewdebuggingreviewcodex

El problema del code review con IA

El código que genera IA tiende a ser sintetizable pero no necesariamente correcto en producción. pasa CI pero rompe con:

N+1 queries que no se ven en tests
Race conditions bajo carga real
Trust boundaries que el LLM no modela bien
Enum handlers que el código olvida cuando agregas un case nuevo

Los skills de implementación de gstack atacan exactamente estos puntos ciegos.

/review

Staff engineer en modo paranóico. El foco está en bugs que pasan tests pero rompen producción.

Categorías que inspecciona:

mindmap
  root[/review/]
    Correctness
      N+1 queries
      Race conditions
      Edge cases no cubiertos
    Seguridad
      Trust boundaries
      Input validation gaps
      Privilege escalation paths
    Arquitectura
      Acoplamiento incorrecto
      Violaciones de capas
      Enum handlers incompletos
    Datos
      Migraciones inseguras
      Schema changes destructivas
      Rollback imposible

Proceso:

Lee el diff o el código indicado
Auto-corrige issues mecánicos con commits atómicos
Escala issues ambiguos al desarrollador con contexto claro

Qué NO hace: No refactoriza por preferencia estética. Solo corrige bugs reales y problemas de seguridad.

Ejemplo de output:

❌ CRÍTICO: La query en UserRepository.findByEmail() no usa
   índice — carga completa de tabla con 50k+ registros.
   Fix: CREATE INDEX idx_users_email ON users(email);

⚠️  WARN: El rate limiter en /api/auth/login usa memoria
   local — no funciona con múltiples instancias del server.
   Fix recomendado: Redis con sliding window.

✅ AUTO-FIXED: 3 console.log de debug eliminados (commits
   a1b2c3d, e4f5g6h, i7j8k9l)

/investigate

Debugger sistemático que sigue la “Ley de Hierro”: sin fix sin investigación de causa raíz.

Principio central:

No implementes un fix hasta entender exactamente por qué falla. Si no entiendes la causa, el fix es una suposición.

Proceso de investigación:

flowchart TD
    BUG[Bug reportado] --> TRACE[Rastrear data flow]
    TRACE --> HYP[Formular hipótesis]
    HYP --> TEST[Probar hipótesis]
    TEST --> FOUND{¿Causa encontrada?}
    FOUND -->|Sí| FIX[Implementar fix]
    FOUND -->|No - 1er intento| HYP
    FOUND -->|No - 3er intento| ARCH[Cuestionar arquitectura]
    ARCH --> USER[Escalar al usuario]

Límite de 3 intentos fallidos:

Si después de 3 hipótesis testeadas no se encuentra la causa, el skill detiene la investigación y escala. El razonamiento: si 3 hipótesis sistemáticas fallan, probablemente hay un problema arquitectónico más profundo que requiere decisión humana.

Qué produce:

Timeline del data flow desde la entrada hasta el error
Lista de hipótesis testeadas con evidencia
Causa raíz documentada (o escalación con contexto completo)
Fix con explicación de por qué resuelve la causa raíz

/codex

Segunda opinión de OpenAI Codex sobre el mismo código.

Por qué dos modelos:

Claude y GPT tienen patrones de entrenamiento distintos
Los bugs que uno normaliza, el otro puede detectar
El overlap de findings indica alta confianza
Los findings únicos revelan perspectivas diferentes

3 modos de operación:

Modo	Descripción	Cuándo usarlo
Pass/Fail	Gate de calidad binario: ¿el código es apto para producción?	Antes de mergear PRs críticos
Adversarial	Intenta activamente encontrar vulnerabilidades y exploits	Código de autenticación, payments, datos sensibles
Consultation	Consulta abierta sobre arquitectura o decisiones de diseño	Cuando quieres explorar trade-offs

Cross-model analysis:

Cuando tanto /review (Claude) como /codex (OpenAI) han revisado el mismo branch, gstack genera un análisis cruzado:

Findings compartidos (alta confianza):
  - Race condition en processPayment() — ambos models coinciden

Findings solo en Claude:
  - N+1 en getUsers() — posiblemente aceptable según el contexto

Findings solo en Codex:
  - Missing CSRF token en form de settings — revisar

Los findings compartidos son prácticamente certeros. Los únicos requieren juicio.

Cuándo usar cada skill

flowchart LR
    DONE[Código listo] --> REV[/review/]
    REV --> BUG{¿Bug encontrado?}
    BUG -->|No reproducible| INV[/investigate/]
    BUG -->|Fix claro| FIX[Fix + commit]
    INV --> ROOT[Causa raíz]
    ROOT --> FIX
    FIX --> CODEX{¿Código crítico?}
    CODEX -->|Sí: auth/payments/data| CDX[/codex/ adversarial]
    CODEX -->|No| QA[/qa/]
    CDX --> QA

Integración con el flujo de PR

El workflow típico en un PR:

# 1. Review automático
/review

# 2. Segunda opinión para código crítico
/codex

# 3. Si hay bugs no reproducibles
/investigate "El test de integración falla en CI pero no local"

# 4. Cuando todo esté limpio
/qa
/ship