# Revisión de código (/es/docs/verdent-manager/advanced-features/code-review) > 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 [#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 [#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 [#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 [#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) [#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 [#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 [#casos-de-uso] ### Verificación de calidad final [#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 [#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 [#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 [#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 [#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 [#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 [#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 [#véase-también] Conoce los subagentes integrados Usa tus propias claves de API Planifica antes de implementar