--- title: Revisión de código description: "Revisa cambios de código con el subagente Reviewer integrado, revisión multimodelo y correcciones con un clic" --- Verdent incluye un subagente integrado llamado **Reviewer**, cuya única responsabilidad es revisar tu código. Cuando termines de escribir, solo menciona `@Reviewer` y analizará tus cambios desde múltiples ángulos y generará una lista estructurada de problemas ordenados por gravedad. Selecciona cualquier elemento que quieras corregir y aplicará los cambios automáticamente: sin necesidad de escribir comentarios ni buscar documentación manualmente. --- ## Cómo activar la revisión de código La forma más directa es escribir `@Reviewer` en el chat, igual que mencionar a un compañero de equipo en un grupo: ``` @Reviewer please review the authentication logic I just wrote ``` Reviewer lee automáticamente el contexto actual y comienza a revisar. También puedes simplemente invocar `@Reviewer` sin instrucciones: decidirá por sí mismo qué inspeccionar. Además de la activación manual, el agente puede invocar Reviewer automáticamente como paso final de **VERIFY** en el flujo de trabajo. Una vez escrito el código, no tienes que preocuparte por ello: el sistema incorpora a Reviewer para validar el resultado. --- ## Cómo se ve el resultado de la revisión Tras la revisión, verás una lista estructurada de **Findings**. Cada elemento incluye: - **Título**: una descripción del problema en una línea - **Explicación detallada**: por qué es un problema y su posible impacto - **Ruta del archivo + número de línea**: selecciona para saltar directamente al código - **Puntuación de confianza**: qué tan seguro está Reviewer (0–1) Los problemas se clasifican en tres niveles de gravedad: | Prioridad | Significado | Ejemplos típicos | |----------|---------|------------------| | **P0** | Crítico, debe corregirse | Errores de lógica, inyección SQL, escalada de privilegios | | **P1** | Importante, debería corregirse | Casos límite faltantes, posibles problemas de rendimiento | | **P2** | Sugerencia | Estilo de código, mejoras de legibilidad | En la parte superior, un resumen como `P0: 1 / P1: 3 / P2: 5` ofrece una vista instantánea de la distribución de gravedad. Al final, un `overall_explanation` proporciona una evaluación general de los cambios. --- ## Corrección con un clic No necesitas editar manualmente cada problema. Cada Finding incluye una casilla de verificación: 1. Selecciona los problemas que quieres corregir (admite seleccionar todo) 2. Selecciona **Fix** 3. Reviewer aplica los cambios automáticamente 4. El estado se actualiza a **Fix done** En algunos casos, si Reviewer determina que los cambios son de bajo riesgo, puede seleccionar automáticamente todos los problemas y aplicar la corrección sin requerir confirmación. --- ## Revisión colaborativa multimodelo Una de las funciones más potentes de Reviewer es la **revisión de código multimodelo**: varios modelos de IA revisan el mismo código en paralelo, como si tres ingenieros de distintos perfiles evaluaran tu implementación de forma independiente. **Cómo activarla** Ve a **Settings → Chat → Reviewer → activa "Multi-model review"**. **Modos de selección de modelos** | Modo | Descripción | |------|-------------| | **Default mode** | Verdent selecciona automáticamente la mejor combinación de modelos según la complejidad de la tarea | | **User mode** | Elige manualmente entre 1 y 3 modelos (Claude, GPT, Gemini se pueden combinar) | Puedes seleccionar hasta **3 modelos**. El primero es el revisor principal; los demás son revisores secundarios. Más modelos significan una cobertura más amplia, pero una ejecución más lenta. Para cambios sencillos, un solo modelo suele ser suficiente. --- ## Reglas de revisión (políticas de revisión personalizadas) Reviewer detecta muchos problemas comunes de forma predeterminada, pero cada equipo tiene sus propios estándares. Las **Review Rules** te permiten definir tus directrices de ingeniería directamente. **Dónde configurarlas** Settings → Chat → Reviewer → editor de Review Rules (editor Monaco con soporte para Markdown). **Qué puedes definir** - Todas las consultas SQL deben usar sentencias parametrizadas, sin concatenación de cadenas - Las operaciones asíncronas deben incluir un manejo de errores adecuado con try/catch - Los componentes React deberían usar `memo` cuando las props son estables - Todas las API públicas deben validar los permisos del usuario Estas reglas se inyectan automáticamente en el contexto de Reviewer y se verifican en cada revisión. Las actualizaciones surten efecto automáticamente tras unos 500 ms, sin necesidad de guardar manualmente. --- ## Flujo de trabajo en tiempo real Durante la revisión, puedes observar el **Working Tree Stream** de Reviewer en tiempo real, que muestra qué archivo está leyendo y qué lógica está analizando. Al expandirlo se revela un árbol de tareas completo. Puedes contraerlo si prefieres una vista más simple sin que ello afecte los resultados. --- ## Casos de uso ### Verificación de calidad final Después de implementar lógica compleja, ejecuta `@Reviewer` para detectar casos límite y errores sutiles que podrías haber pasado por alto por cansancio. ### Validación previa al PR Ejecuta una revisión antes de enviar un pull request. Corrige primero todos los problemas P0/P1 para reducir el intercambio de mensajes y aliviar la carga de revisión de tus compañeros. ### Auditoría de seguridad Agrega Review Rules orientadas a la seguridad (por ejemplo, "todas las entradas deben sanearse contra XSS") para asegurar que cada cambio se verifique automáticamente frente a las políticas de seguridad. ### Aplicación de estándares del equipo Codifica reglas de ESLint, convenciones de diseño de API y estándares de nomenclatura en las Review Rules para que incluso quienes recién se incorporan sigan las directrices del equipo automáticamente. ### Decisiones de arquitectura con múltiples perspectivas Para cambios importantes, activa la revisión multimodelo para obtener evaluaciones independientes y descubrir puntos ciegos. ### Herramienta de aprendizaje para principiantes Usa los comentarios de Reviewer como material de aprendizaje: entender por qué importan los problemas P0 enseña los principios básicos de ingeniería más rápido que leer documentación. --- ## Notas - **Modelo único frente a multimodelo**: el multimodelo ofrece una cobertura más amplia, pero es más lento y costoso. Para tareas sencillas o urgentes, un solo modelo suele bastar. - **Limitación del nivel gratuito**: los usuarios gratuitos en User mode solo pueden seleccionar modelos del grupo Eco Mode; los modelos premium requieren una suscripción. - **Retirada de modelos**: si un modelo seleccionado se retira, se deshabilitará y deberá reemplazarse. - **Las Review Rules son globales**: se aplican a todos los proyectos. Si una regla es específica de un proyecto, añade una nota o elimínala después de usarla. - **Estado de BYOK**: si usas tu propia clave de API, una clave expirada o sin saldo suficiente deshabilitará los modelos correspondientes y provocará fallos de revisión hasta que la actualices. --- ## Véase también Conoce los subagentes integrados Usa tus propias claves de API Planifica antes de implementar