Tu dashboard de SonarQube muestra 0 issues críticos. Todo verde. A producción.
Mientras tanto, tu codebase tiene tres enfoques incompatibles de gestión de sesiones. Hay un ORM casero que traga silenciosamente errores de conexión. El flujo de autenticación técnicamente funciona, pero viola todos los principios de seguridad del OWASP top 10 – no por una vulnerabilidad específica que un scanner detectaría, sino porque la arquitectura general no tiene sentido. Los tokens de sesión se almacenan en localStorage en un módulo y en httpOnly cookies en otro. El flujo de reset de contraseña evita el rate limiter porque se construyó antes de que el rate limiter existiera.
Nada de esto aparece en tu dashboard. Todas las reglas están pasando. El codebase está en verde.
Las reglas detectan violaciones de reglas. No detectan mala arquitectura.
Las herramientas de análisis estático son excelentes en lo que hacen. Comparan patrones de código contra una base de datos de issues conocidos. ¿Variable sin usar? Detectada. ¿Null dereference sin verificar? Detectado. ¿Concatenación de strings SQL en vez de queries parametrizados? Detectada. Estas herramientas han prevenido miles de bugs reales de llegar a producción, y merecen toda la adopción que han ganado.
Pero los problemas más difíciles en codebases legacy no son violaciones de reglas. Son decisiones arquitectónicas que tenían sentido hace cinco años y ya no lo tienen. Son patrones que surgieron orgánicamente mientras diferentes equipos resolvieron el mismo problema de maneras distintas. Son el tipo de issues que un desarrollador senior notaría durante un code review exhaustivo pero que ninguna base de datos de reglas contiene, porque no son violaciones de ninguna regla específica – son violaciones de coherencia.
Considera lo que una herramienta basada en reglas no puede expresar:
- Tu proyecto usa tres frameworks de logging diferentes – Winston en la capa de API, Bunyan en los workers de background y
console.logdirecto en las utilidades. Ninguno está mal individualmente. Juntos, significan que tu historia de observabilidad está fragmentada, tus formatos de log son inconsistentes, y depurar una request que cruza límites de módulos requiere revisar tres outputs diferentes. - La mitad de tu código async usa callbacks y la otra mitad usa Promises. Alguien empezó una migración hace dos años y llegó a la mitad. El resultado es que el manejo de errores se comporta diferente dependiendo de en qué mitad del codebase estés, y la frontera entre las dos mitades es donde viven los bugs.
- Hay 47 feature flags en la configuración. Doce de ellas controlan funcionalidades que se lanzaron a todos los usuarios hace más de un año. Ocho de ellas referencian A/B tests que terminaron. Tres de ellas se verifican en el código pero nunca se setean en ninguna parte. Nadie tiene la confianza suficiente para eliminar ninguna porque nadie sabe qué hacen todas.
Un analizador estático no va a detectar nada de esto. No son violaciones de reglas. Son el tipo de complejidad acumulada que hace que los codebases sean difíciles de trabajar, lentos de cambiar y caros de mantener.
Lo que “review” realmente significa
Cuando un desarrollador experimentado revisa un codebase – no un diff, sino un codebase real – no verifica reglas. Construye un modelo mental. Lee archivo tras archivo, acumulando contexto. Empieza a notar patrones: cómo se manejan los errores aquí versus allá, qué convenciones se siguen consistentemente y cuáles no, dónde los límites entre módulos están limpios y dónde están enredados.
Nota cosas que no encajan. Una query de base de datos en un template de vista. Lógica de negocio en una función utilitaria. Un mecanismo de retry que se reimplimentó cuatro veces en cuatro archivos diferentes. Valores de configuración que están hardcodeados en algunos lugares y se leen de variables de entorno en otros.
Este tipo de review produce algo que ningún dashboard puede: una comprensión narrativa de qué está mal con el codebase y por qué. No una lista de issues a nivel de línea, sino una evaluación del sistema como un todo.
El problema es que este review toma días o semanas de tiempo humano caro. Así que casi nunca ocurre. El codebase crece, las inconsistencias se acumulan y el dashboard sigue en verde.
Este es el tipo de razonamiento que los modelos de lenguaje grandes ahora pueden hacer a escala. Un LLM puede leer archivos secuencialmente, acumular contexto a través de cientos de archivos y razonar sobre las relaciones entre ellos. No verifica si una línea viola una regla. Pregunta si el código, tomado como un todo, tiene sentido.
VibeRails llena el vacío
VibeRails es una aplicación de escritorio que orquesta Claude Code y Codex CLI para hacer code review de codebase completo. Lee cada archivo en tu proyecto, razona sobre el conjunto, y saca a la luz los issues que viven entre líneas – los que las herramientas basadas en reglas nunca fueron diseñadas para encontrar.
El análisis cubre 17 categorías de detección que van más allá de lo que la coincidencia de patrones puede expresar: vulnerabilidades de seguridad, cuellos de botella de rendimiento, riesgos de bugs, código muerto, hotspots de complejidad, brechas de type safety, debilidades de manejo de errores, problemas de diseño de API, problemas de accesibilidad, brechas de observabilidad, riesgos de concurrencia, problemas de integridad de datos, issues de internacionalización, problemas de dependencias, brechas de documentación, deficiencias de testing y smells de mantenibilidad.
El modo de triage te permite procesar hallazgos eficientemente – acepta, rechaza o difiere cada uno con atajos de teclado. Las sesiones de fix despachan IA para implementar los cambios directamente en tu repositorio local. Tú revisas el diff, testeas y haces commit.
VibeRails usa el modelo BYOK: orquesta tus suscripciones de IA existentes en lugar de hacer proxy de los requests a través de un servicio cloud de VibeRails. Tus API keys se quedan locales, y tu código no se sube a servidores de VibeRails. No estás pagándole a un intermediario para que te revenda acceso a una IA que ya tienes.
El análisis estático es necesario. Solo que no es suficiente. El dashboard verde te dice que tu código sigue las reglas. No te dice si las reglas son las correctas, ni si el código que las sigue tiene sentido como sistema.
Prueba VibeRails gratis – hasta 5 issues por sesión de review, sin registro.
Limits and tradeoffs
- It can miss context. Treat findings as prompts for investigation, not verdicts.
- False positives happen. Plan a quick triage pass before you schedule work.
- Privacy depends on your model setup. If you use a cloud model, relevant code is sent to that provider; local models can keep inference on your own hardware.