Construiste la Mitad de una Red de Seguridad y Dijiste que Ya Estaba

Seamos honestos sobre cómo se ven realmente la mayoría de los pipelines de código con IA en este momento.

Generas código con Cursor o Claude Code. Ejecutas tsc --noEmit porque el modo estricto de TypeScript detecta errores de tipos. Ejecutas ESLint porque nadie quiere discutir sobre punto y coma en un pull request. Tal vez ejecutas dependency-cruiser porque las importaciones circulares son vergonzosas. Tus tests pasan. Lo despliegas.

Y crees que eso es un stack determinista.

No lo es. Es un stack de tipos y estilo. Has evitado estados inválidos y has aplicado el enforcement de los límites de importación, lo cual es genuinamente útil. Pero no has hecho absolutamente nada respecto al hecho de que el LLM acaba de generar una función de 180 líneas con una complejidad ciclomática que haría llorar a un teórico de grafos. No has detectado que tres módulos diferentes copiaron el mismo helper con nombres de variables ligeramente distintos. No has notado que el manejo de errores es un único catch (e) { console.log(e) } sentado al final de una cadena de promesas como un portero perezoso.

El código compila. La arquitectura es limpia. El código sigue siendo objetivamente terrible.

Esa es la brecha. Y importa porque el código generado por IA tiene un talento particular para producir exactamente este tipo de basura: estructuralmente válido, arquitectónicamente conforme, y pudriéndose en silencio por dentro.

Qué es Realmente la Capa que Falta

Piensa en la diferencia entre un edificio que pasa la inspección de un ingeniero estructural y un edificio que es agradable para vivir. La inspección estructural verifica si el edificio se cae. No verifica si la ducha desagua en el fregadero de la cocina. Ambas cosas importan. Son trabajos diferentes.

Tu stack determinista existente es el ingeniero estructural. Verifica:

  • Tipos: ¿Puede este valor existir en esta forma?
  • Linting: ¿La sintaxis sigue una higiene básica?
  • Reglas de arquitectura: ¿Los imports respetan los límites?
  • Tests: ¿El flujo principal se ejecuta sin fallar?

Lo que no verifica:

  • Complejidad: ¿Esta función tiene tantas ramas que ningún humano podrá razonar sobre ella correctamente?
  • Duplicación: ¿Generó el LLM la misma lógica en cuatro lugares con variaciones menores?
  • Nomenclatura: ¿Es data un nombre de variable significativo, o es el equivalente programático de un encogimiento de hombros?
  • Manejo de errores: ¿Los errores se manejan realmente, o solo se capturan y se ignoran?
  • Estructura: ¿La organización de archivos tiene sentido, o es un vertedero?
  • Comentarios: ¿Las partes complicadas están explicadas, o el siguiente desarrollador va a necesitar una sesión de espiritismo?
  • Tamaño: ¿Este archivo tiene 400 líneas porque necesita tenerlas, o porque nadie le dijo al modelo que parara?

Estas no son preferencias estéticas. La complejidad se correlaciona con la densidad de defectos. La duplicación garantiza que los cambios futuros serán inconsistentes. La mala nomenclatura aumenta la carga cognitiva para cada modificación posterior. El manejo de errores deficiente significa fallos en producción sin rastro diagnóstico.

La investigación es inequívoca aquí. Nuestro propio análisis multidimensional encontró que las arquitecturas de confiabilidad por capas solo funcionan cuando cada capa detecta defectos que las capas anteriores no encontraron. Si tu Capa 1 es el type checking y tu Capa 2 son los tests, pero nadie está verificando si el código es un desastre de mantenibilidad, tienes un agujero en tu stack. Y el código generado por IA adora caerse por ese agujero porque los modelos son muy buenos generando implementaciones plausibles que resultan ser pesadillas para convivir.

Entra la Herramienta con el Nombre Grosero

Existe una herramienta llamada fuck-u-code — sí, de verdad, ese es el comando — y hace exactamente una cosa que nada más en tu pipeline está haciendo. Ejecuta análisis de calidad de código determinista basado en AST en catorce lenguajes y te dice con precisión qué tan malo es tu código, usando métricas que realmente se correlacionan con problemas reales.

Esto es lo que verifica:

  • Complejidad: Puntuaciones de complejidad ciclomática y cognitiva. Si una función tiene diecisiete ramas, la marca.
  • Tamaño: Conteo de líneas de archivos y funciones. El LLM que generó una función de 250 líneas no recibe un pase porque los tipos sean correctos.
  • Comentarios: Densidad y calidad de comentarios. No porque los comentarios sean virtuosos, sino porque la lógica compleja sin explicación es una trampa de mantenimiento.
  • Manejo de errores: Si los errores se capturan, se relanzan, se registran o se tragan en silencio.
  • Nomenclatura: Calidad de los nombres de variables y funciones. data, temp, handler y process no pasan.
  • Duplicación: Bloques de código repetidos entre archivos. El truco favorito del LLM: copiar-pegar con un buscar-reemplazar.
  • Estructura: Organización de archivos y cohesión de módulos.

Genera una puntuación global de 0 a 100. Más alto es mejor. También genera un “shit-gas index” por archivo — más alto es peor — así sabes exactamente qué archivos necesitan atención primero. El análisis se ejecuta completamente offline mediante parsing AST con tree-sitter. Tu código nunca abandona tu máquina. Tarda menos de un segundo en la mayoría de los proyectos.

Y aquí está la parte que debería enfurecerte de que no la estuvieras usando ya: cuesta cero dólares.

La Herramienta Encarna la Filosofía

Lo que hace interesante a fuck-u-code no es solo lo que verifica. Es cómo está arquitectada internamente, porque la herramienta en sí es un microcosmos perfecto del pipeline al que pertenece.

La herramienta tiene dos comandos:

fuck-u-code analyze .          # Análisis determinista de AST. Offline. Rápido. Gratis.
fuck-u-code ai-review . -m gpt-4o   # Revisión con IA de los archivos con peor puntuación. Llamada a API. Cuesta tokens.

Observa el orden. Observa el valor por defecto. El análisis determinista se ejecuta primero, siempre, porque no requiere una API key, no cuesta dinero y no varía entre ejecuciones. La revisión con IA es un segundo paso opcional que solo mira los N peores archivos.

Esta es exactamente la arquitectura que tu pipeline debería tener.

No envías cada pull request a Greptile o Claude Code para una revisión semántica completa. Eso cuesta dinero, toma tiempo y — como hemos establecido en publicaciones anteriores — produce una salida probabilística que puede o no señalar los mismos problemas en ejecuciones consecutivas. Ejecutas la puerta determinista primero. Filtras los desastres estructurales de forma gratuita, en milisegundos, con reproducibilidad perfecta. Entonces, y solo entonces, envías a la revisión con IA los sobrevivientes para el análisis semántico, arquitectónico y de comportamiento que las herramientas deterministas no pueden hacer.

fuck-u-code literalmente implementa esto internamente. El comando analyze es tu filtro de calidad de Capa 1. El comando ai-review es tu inmersión profunda semántica de Capa 2. La herramienta es una demostración del principio que habilita.

El Argumento Económico Es Casi Ofensivo

Hablemos de dinero por un momento, porque aquí es donde el estado actual de la industria se vuelve genuinamente irritante.

Las plataformas de revisión de código con IA cobran por pull request o por línea de código revisada. El costo no es enorme — quizás un dólar o dos por PR — pero no es cero, y escala con la velocidad de tu equipo. Si estás generando código con IA, tu velocidad es mayor de lo que solía ser, lo que significa que tus costos de revisión también son mayores de lo que solían ser.

Mientras tanto, fuck-u-code analizará todo tu codebase, en catorce lenguajes, en menos de un segundo, y te cobrará exactamente cero. Marcará el 20% de los archivos que son genuinamente problemáticos. Producirá un reporte en JSON o Markdown que tu CI puede consumir. Hará fallar el build si el puntaje promedio cae por debajo de un umbral que configuraste.

Si ejecutas revisión con IA en cada PR sin una puerta de calidad determinista primero, estás pagando tokens de API para descubrir que una función es demasiado compleja. Eso es como contratar a un ingeniero estructural para que te diga que tu casa está sucia. El ingeniero está calificado para el trabajo, pero estás desperdiciando su tiempo y tu dinero.

El pipeline económicamente racional es:

  1. La IA genera código
  2. Type check, lint y reglas de arquitectura (tu stack existente)
  3. fuck-u-code analyze (la puerta de calidad que falta — $0, <1s)
  4. Revisión con IA (Greptile, etc. — pero solo en archivos que sobrevivieron el paso 3, o solo cuando el paso 3 marca patrones interesantes)

Esto no es teoría. Es aritmética. La puerta determinista atrapa la clase de problemas para los que las herramientas deterministas están diseñadas. La revisión con IA atrapa la clase de problemas que requieren comprensión semántica. Cada herramienta hace lo que sabe hacer. Nadie desperdicia tokens en higiene estructural.

Integración MCP: Construida para el Flujo de Trabajo, No Adaptada a Contrarreloj

Hay un detalle más que importa si hablas en serio sobre el desarrollo asistido por IA.

fuck-u-code incluye un servidor MCP. Si estás usando Claude Code, Cursor o cualquier otra herramienta compatible con MCP, puedes invocar fuck-u-code analyze directamente desde tu agent. El agent no necesita saber sobre parsing AST ni complejidad ciclomática. Llama a una herramienta. La herramienta devuelve un reporte estructurado. El agent actúa en consecuencia.

Esto importa porque cierra el ciclo. La misma IA que generó el código ahora puede recibir retroalimentación determinista sobre la calidad de ese código, en un formato que puede entender y actuar sobre él. El agent puede ver que el shit-gas index de src/auth/login.ts es 87 de 100 y decidir refactor antes de que un humano vea el pull request.

Hemos escrito antes sobre cómo CI es la capa de enforcement que hace real el desarrollo guiado por especificaciones. La integración MCP significa que fuck-u-code no es solo una puerta de CI. Es un oráculo de calidad accesible para agentes que el pipeline de generación puede consultar en tiempo real.

Cómo Se Ve Realmente Agregarlo

No necesitas un plan de migración. Necesitas cinco minutos.

npm install -g eff-u-code
fuck-u-code analyze .              # Ve tus puntuaciones actuales
fuck-u-code config init            # Genera .fuckucoderc.json

Configura tus umbrales. Elige una puntuación mínima global. Elige un shit-gas index máximo para cualquier archivo individual. Agrégalo a tus pre-commit hooks:

# .husky/pre-commit
fuck-u-code analyze . --format json --output quality-report.json

O agrégalo a CI:

# .github/workflows/quality.yml
- name: Code Quality Gate
  run: |
    npm install -g eff-u-code
    fuck-u-code analyze . --format markdown -o quality.md
    # Analiza el JSON y falla si el puntaje global < umbral

Los pesos son configurables. Si a tu equipo le importa más la complejidad que los comentarios, ajusta los pesos de las métricas en .fuckucoderc.json. Si quieres excluir archivos de test, usa --exclude. Si quieres ver los 20 peores archivos en lugar de los 10 por defecto, usa -t 20.

Entonces, cuando hayas filtrado los desastres estructurales, envía los archivos interesantes a la revisión con IA:

fuck-u-code ai-review . -m gpt-4o -t 5   # Revisa solo los 5 peores archivos

Ese es el pipeline. Generar. Type-check. Puerta de calidad. Revisión con IA de los sobrevivientes. Desplegar.

La Conclusión Honesta de Fondo

No voy a pretender que fuck-u-code va a resolver todos los problemas de tu codebase. No detectará una condición de carrera. No te dirá que tu lógica de autenticación tiene un timing attack sutil. No reemplazará property-based testing ni mutation testing ni verificación formal ni ninguna de las otras capas de las que hemos hablado en publicaciones anteriores.

Lo que hará es detectar los problemas aburridos, predecibles y costosos que nadie está detectando actualmente. Te dirá que tu manejador de API generado por IA tiene 300 líneas de largo y no tiene manejo de errores. Te dirá que tres servicios diferentes copiaron la misma lógica de validación. Te dirá que la mitad de tus variables se llaman data o result y deberías sentirte mal por ello.

Estos no son casos borde. Son los resultados por defecto de un pipeline de generación de código rápido que no tiene un bucle de retroalimentación de calidad. El LLM no se cansa, pero tampoco se avergüenza. Generará código malo con la misma confianza con la que genera código bueno, y tu stack determinista actual lo dejará pasar porque tu stack no fue diseñado para verificar calidad. Fue diseñado para verificar validez.

La validez y la calidad son cosas diferentes. Necesitas ambas.

fuck-u-code no es la respuesta completa. Es la respuesta a la pregunta específica: “¿Cuál es la forma más barata, rápida y determinista de evitar que la basura estructural generada por IA llegue a la revisión de código?”

La respuesta es: parsear el AST, puntuar las métricas, hacer fallar el build, y hacer que el modelo lo intente de nuevo.

No cuesta nada. Tarda menos de un segundo. Y cierra un agujero en tu stack de seguridad que probablemente no sabías que tenías.