Verification Discipline (Disciplina de Verificación del Código Generado)

1. Visión general del concepto y problema sistémico

Con el desarrollo de herramientas de autogeneración, ha surgido una brecha crítica entre la facilidad de creación de código y sus reales cualidades de confiabilidad. Un modelo puede generar 400 líneas de código perfectamente formateado con nombres de métodos plausibles, que se ve autoritativo, pero falla en el primer segundo de ejecución debido a la llamada a un método inexistente o a una discrepancia de tipos.

Verification Discipline (Disciplina de Verificación) es la principal barrera de demarcación entre un ingeniero de software profesional y un aficionado. Es una postura interna inquebrantable:

• Ninguna palabra del modelo de lenguaje se toma por fe.
• Cualquier código generado se considera potencialmente defectuoso hasta que se demuestre lo contrario mediante una herramienta determinista independiente (compilador, linter, runner de pruebas).
• El ingeniero asume la responsabilidad profesional personal por cada símbolo fusionado en el repositorio.

Sin la disciplina de verificación, un proyecto se desliza hacia un estado de "casa de naipes frágil", donde cada nueva función rompe dos anteriores, y el equipo gasta todas sus fuerzas apagando incendios repentinos en producción.

Enfoque aficionado (Confianza ciega):
[LLM: "¡He corregido todo, el código está listo!"] ---> [Clic "Accept All"] ---> [Commit & Push] ---> [502 Bad Gateway en producción]

Disciplina de verificación ingenieril (Evidence-First):
[LLM: "¡He corregido todo!"]
          |
          v
[Paso 1: tsc --noEmit] -----------------> [¡Error de tipo! Regreso al agente para revisión]
          | (Verde)
          v
[Paso 2: vitest run] -------------------> [¡Fallo en la prueba! Corrección de la lógica]
          | (Verde)
          v
[Paso 3: git diff --cached] ------------> [Se detectó un console.log extra y una biblioteca alucinada]
          | (Limpio)
          v
[Paso 4: Smoke Test en el navegador] -----> [Clic físico en el formulario]
          |
          v
[Commit consciente en producción]

2. Taxonomía arquitectónica y modelo mental

Niveles de barreras de verificación (El Modelo de Queso Suizo):

1. Nivel 1: Análisis sintáctico y semántico estático (Compile-time):
   • Compilador estricto (tsc --noEmit, rustc, cargo check).
   • Linters de estilo y seguridad (ESLint, Biome, ShellCheck).
   • Filtra el 70% de las alucinaciones sobre campos o métodos inexistentes.
2. Nivel 2: Pruebas dinámicas automatizadas (Dynamic Verification):
   • Pruebas unitarias: verificación de funciones puras y casos límite.
   • Pruebas de integración: verificación de la interacción con una base de datos real o caché.
   • Protege contra errores lógicos y regresiones.
3. Nivel 3: Auditoría de cambios (Diff Hygiene):
   • Lectura humana de la diferencia de líneas a través de git diff.
   • Objetivo: detectar "basura", comentarios eliminados accidentalmente, violaciones de límites arquitectónicos.
4. Nivel 4: Verificación en tiempo de ejecución (End-to-End & Observability):
   • Ejecución de un caso de uso real a través de Playwright o manualmente en el navegador/terminal.
   • Monitoreo de logs después del lanzamiento para detectar picos de errores 5xx.

3. Pipeline técnico y mecánica interna

Hook de verificación automático de Git Pre-Commit (Husky / Lefthook)

El ser humano puede olvidar verificar el código debido a la fatiga. Para proteger el sistema del factor humano, el contorno de verificación bloquea hardware el commit:

# lefthook.yml — validador confiable y rápido
pre-commit:
  parallel: false
  commands:
    typecheck:
      run: npx tsc --noEmit
    lint:
      run: npx @biomejs/biome check --staged --apply
    test:
      run: npx vitest run --passWithNoTests

Si al menos una prueba falla o el compilador detecta una discrepancia de tipos, el intento de hacer commit del código termina en un paro de emergencia.

Lista de verificación para auditoría manual de diff (Diff Inspection Protocol)

Antes de ejecutar el comando git push, el ingeniero verifica:

- [ ] ¿El agente ha eliminado código importante en partes no relacionadas del archivo?
- [ ] ¿Se han manejado los casos límite (null, undefined, array vacío, 404)?
- [ ] ¿No hay contraseñas, secretos y tokens de prueba hardcodeados?
- [ ] ¿No hay cambios de formato accidentales en 50 archivos ajenos en el diff?
- [ ] ¿Los nombres de las nuevas entidades cumplen con los estándares aceptados del proyecto?

4. Escenarios prácticos de ingeniería en producción

01. Detección de una alucinación engañosa en el módulo financiero

Un agente escribió una función para calcular la comisión bancaria y afirmó con confianza: "La lógica ha sido actualizada de acuerdo a las reglas". El ingeniero activó la disciplina de verificación y escribió una prueba para pasar una suma negativa (amount: -100). Resultó que la función devolvía una comisión negativa, lo que permitiría a los atacantes robar dinero de las cuentas de la empresa. El bug fue corregido antes del lanzamiento.

02. Protección contra la eliminación silenciosa de comentarios en un sistema legado

Durante la refactorización, el módulo contenía un comentario importante: // CRITICAL: no reordenar esta llamada debido al bug #19284 en Safari. El modelo decidió que el comentario era innecesario y lo eliminó, alterando la secuencia de llamadas. Gracias a la cuidadosa revisión de git diff, el arquitecto notó la eliminación, preservó el workaround protector y añadió una prueba E2E de regresión.

03. Reproducción completa de un bug antes de su corrección (Bug Repro First)

Al recibir un informe de fallo, el ingeniero disciplinado prohíbe al agente tocar el código de producción. Primero se escribe una prueba que reproduce exactamente el bug y falla con un error rojo (Red Phase). Solo después de que el bug se ha capturado garantizado por la prueba, el agente realiza cambios hasta que la prueba se vuelve verde (Green Phase).

5. Errores comunes, trampas y seguridad

1. "Diff Blindness" (Ceguera de diff): Cuando el diff contiene más de 800 líneas, los ojos se cansan, y después de 2 minutos de desplazamiento, el ingeniero simplemente hace clic en "Approve". Si el PR es demasiado grande, nunca lo apruebes en su totalidad. Exige dividir la tarea en partes atómicas de hasta 200 líneas cada una.
2. Mocks que siempre pasan (Tautological Tests): Los agentes a menudo generan pruebas que prueban sus propios mocks: mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true). Tal prueba siempre es verde, pero no prueba ninguna línea de código real. Siempre verifica la semántica de la afirmación en las pruebas generadas.
3. Ignorar advertencias del compilador (Compiler Warnings): La costumbre de ignorar advertencias amarillas del linter o de convertir tipos implícitamente a través de as unknown as Type destruye completamente el sistema de seguridad de TypeScript. Trabaja bajo la regla: cero advertencias en la consola.