Devin Review

​

Funcionalidades

​

Primeros pasos

• Aplicación web de Devin — Ve a app.devin.ai/review para ver tus PRs abiertos organizados por categoría (asignados a ti, creados por ti, revisión solicitada). Cuando Devin cree PRs, verás un botón naranja “Review” en el chat.
• Comentario de PR — Comenta /devin review en cualquier PR de GitHub de un repositorio que tu organización haya conectado, y Devin lo revisará al instante. Consulta Activar una revisión desde un comentario de PR.
• Atajo de URL — Para cualquier enlace de PR de GitHub.com, reemplaza github.com por devinreview.com en la URL. Para PRs privados, inicia sesión en Devin primero.
• GitHub Enterprise — Pega la URL completa del PR en la página de Devin Review en app.devin.ai/review. Todas las ofertas de GitHub (GitHub.com, Enterprise Server, Enterprise Cloud) tienen las mismas capacidades.
• Azure DevOps — Pega la URL completa del PR (por ejemplo https://dev.azure.com/.../pullrequest/..., o el host de tu Azure DevOps Server) en app.devin.ai/review después de conectar el repositorio a Devin.

​

Proveedores de Git compatibles

​

Lectura de una revisión

​

Permisos

​

Gobernanza

​

Control de costos

​

Panel de consumo

• Desglose por usuario — Vea cuántos ACU de revisión consumió cada usuario en el ciclo de facturación actual y en el anterior.
• Desglose por repositorio — Vea el consumo de ACU de revisión, la cantidad de revisiones y la cantidad de bugs detectados por repositorio en el ciclo de facturación actual y en el anterior, lo que ayuda a identificar qué repos generan el mayor costo de revisión y dónde las revisiones detectan más problemas.

​

Indicador del tamaño de la revisión

​

Límite de gasto de revisión automática por PR

• Las revisiones manuales siguen funcionando — el límite solo pausa las revisiones automáticas. Siempre puedes activar una revisión manualmente desde la página de revisión de la PR.
• Volver a habilitar por PR — Si vuelves a activar la revisión automática para la PR desde el menú de acciones (tres puntos en el encabezado), se reanudan las revisiones automáticas y esa PR queda exenta del límite.

​

Acciones del flujo de trabajo del PR

• Merge — Fusiona la PR con la estrategia de fusión configurada en el repositorio (merge commit, squash o rebase). El botón de fusión refleja el estado actual de fusionabilidad de la PR y las verificaciones obligatorias.
• Close — Cierra la PR sin fusionarla. Está disponible en el menú desplegable junto al botón de fusión.
• Convert to draft — Convierte una PR abierta en borrador. Está disponible en el menú desplegable cuando la PR está abierta y aún no es un borrador.
• Mark ready for review — Marca una PR en borrador como lista para revisión. En las PR en borrador, aparece un botón “Ready for review” en la barra de fusión.
• Auto-merge — Activa o desactiva la fusión automática de GitHub desde el menú desplegable del botón de fusión. Cuando está activada, la PR se fusionará automáticamente una vez que se completen todas las verificaciones obligatorias. La barra de fusión muestra el estado actual de la fusión automática, incluida la persona que la activó.

​

PR apiladas

• Panel de pila — El encabezado de la PR muestra la pila con todos sus integrantes ordenados de abajo arriba, hasta la rama base en la que se fusionan. Cada integrante enlaza a su propia página de revisión, por lo que puede revisar la pila capa por capa.
• Estado por capa — Cada integrante muestra un punto de estado que refleja si realmente se puede fusionar: verde cuando puede fusionarse (teniendo en cuenta la CI, las revisiones obligatorias y la protección de ramas), rojo si hay comprobaciones fallidas o conflictos, y naranja para cualquier otro impedimento para la fusión, incluso cuando una capa está lista por sí sola, pero está bloqueada por una PR no fusionable situada debajo. Un indicador agregado resume el estado de toda la pila.
• Diffs específicos — Cada PR de una pila se compara con la capa inferior, de modo que cada revisión, incluida la revisión automática y el capturador de errores, solo ve el cambio de esa capa.
• Fusión de pila — Las PR apiladas se fusionan mediante la fusión atómica de pilas de GitHub: al fusionar una PR, también se fusionan todas las PR abiertas situadas debajo de ella en la pila, de abajo arriba, en una sola operación. El botón de fusión muestra exactamente cuántas PR incluirá la acción, y GitHub redirige las PR restantes a la rama base después.

​

Revisión automática

​

¿Cuándo se ejecuta la revisión automática?

• Se abre un PR (que no sea borrador)
• Se envían nuevos commits a un PR
• Un PR en borrador se marca como listo para revisión

​

Modos de activación

• Revisión automática (predeterminado) — Las revisiones se activan en todos los eventos: apertura de la PR, nuevos commits enviados y borrador marcado como listo.
• Al crear la PR — Las revisiones solo se activan cuando una PR se abre por primera vez o cuando una PR en borrador se marca como lista para revisión. Los commits posteriores en la PR no activan una nueva revisión.
• Manual — No se ejecuta ninguna revisión automáticamente. Tú mismo activas una revisión desde la página de revisión de PR cuando quieras. Este es el nivel base para la inscripción personal.

​

Autoinscripción (Todos los usuarios)

1. Ve a Settings > Preferences
2. En Devin Review, configura tu disparador de revisión como Al crear la PR o revisión automática (déjalo en Manual si solo quieres activar las revisiones tú mismo)

​

Idioma de los comentarios de revisión

• Usar tu idioma de la interfaz (predeterminado) — Los comentarios de revisión seguirán la configuración de idioma de tu interfaz.
• Idioma específico — Elige entre inglés, español, portugués, japonés, chino, coreano, francés, alemán, ruso, árabe, hebreo o indonesio.

​

Configuración de administrador

• Repositories — Agregar repositorios para revisar automáticamente TODOS los PR en ese repositorio. Usa el botón Add repo para buscar y seleccionar entre los repositorios conectados, y establece el modo de activación de cada repositorio desde la lista.
• Users — Ver todos los usuarios inscritos en la organización junto con el modo de activación de cada usuario. Los usuarios se inscriben por sí mismos mediante la autoinscripción; los Admin no pueden inscribir directamente a otros usuarios.
• Add “Devin Review” link in PR description — Cuando está habilitado (de forma predeterminada), Devin agrega un enlace a la revisión en la descripción del PR.

​

Publicar en GitHub

• Post GitHub CI checks — Cuando está habilitado (de forma predeterminada), Devin crea una comprobación del estado del commit en el PR para cada revisión. Esto te permite ver los resultados de la revisión directamente en la lista de checks de tu PR.
• Bugs — Publica bugs (errores probables o comportamiento incorrecto) como comentarios del PR.
• Seguridad — Publica vulnerabilidades de seguridad y sugerencias de fortalecimiento como comentarios del PR.
• Flags (investigate) — Publica flags de investigación (posibles problemas que vale la pena revisar más de cerca) como comentarios del PR.
• Flags (note) — Publica flags informativos (observaciones que pueden no requerir acción) como comentarios del PR.

​

Capturador de errores

​

Bugs

• Grave — Problemas de alta confianza que requieren atención inmediata
• Menos grave — Problemas de menor gravedad que aun así deben revisarse

​

Flags

• Investigar — Flags que merecen una investigación más profunda. Debes revisar tú mismo el código marcado y verificar si realmente hay un error o problema.
• Informativo — Bug Catcher ha concluido que algo es correcto o está explicando cómo funciona. Estos flags te ayudan a entender los cambios en el código sin requerir acción.

​

Seguridad

• Inyección (SQL, XSS, comandos, plantillas)
• Fallos de autenticación (control de acceso ausente o defectuoso, escalada de privilegios, bypass de autenticación)
• Exposición de secretos (claves codificadas, tokens en logs, credenciales en el código fuente)
• SSRF y path traversal
• Deserialización insegura, prototype pollution
• Falta de validación de datos de entrada no confiables
• Criptografía débil (algoritmos, gestión de claves)
• Seguridad del transporte/de las cookies (falta de aplicación de HTTPS, CORS permisivo, atributos de cookies inseguros)
• Valores predeterminados inseguros o configuraciones incorrectas introducidas por la PR

• Crítico — Vulnerabilidades detectadas con alta confianza que deben corregirse antes de fusionar
• Advertencia — Posibles debilidades de seguridad que vale la pena investigar

​

Resolución de hallazgos

​

Acciones de revisión

​

Activar una revisión desde un comentario de PR

• Comenta exactamente /devin review al inicio del comentario. El comando no distingue entre mayúsculas y minúsculas y funciona tanto en los comentarios de conversación de la PR como en los comentarios de revisión en línea.
• Se requiere acceso de escritura: quien comenta necesita permisos write o admin en el repositorio, y su cuenta de GitHub debe estar vinculada a su cuenta de Devin. Los colaboradores externos no pueden activar revisiones.
• Solo PR abiertas: se ignoran los comentarios en PR cerradas o fusionadas.
• Solo GitHub: incluye GitHub Enterprise Server y Enterprise Cloud. GitLab admite la revisión automática, pero no el activador mediante comentarios.

​

Iniciar una revisión

​

Resolver comentarios

​

Indicadores de propietario de código

​

Corrección automática

​

Cómo activarlo

1. Desde la barra lateral de revisión — En cualquier PR creada por Devin, la barra lateral de análisis muestra una sección de corrección automática con un botón Enable auto-fix. Al hacer clic, se habilita corrección automática para todas las PR de Devin en tu organización. Esto requiere permisos de admin de la organización.
2. Desde la configuración global de Devin — Ve a Settings > Devin > Pull requests > Responding to bots, luego:
   • Establece el modo en Selected only y añade devin-ai-integration[bot] a la lista de permitidos, o
   • Establece el modo en All bots.

​

Hallazgos en los PR del propio Devin

1. El PR muestra el estado Devin is addressing Devin Review findings.
2. Si Auto-fix review findings está activado, la sesión corrige lo que puede. Si está desactivado, la sesión solo recibe una notificación e informa del resultado.
3. Solo se publican como comentarios de revisión los hallazgos que Devin no pudo corregir, y el estado enumera lo que se corrigió.

​

Permisos y restricciones

• Solo los Admin de la organización pueden cambiar esta configuración.
• Si el modo del bot está configurado en Todos los bots, corrección automática aparece activado y no se puede cambiar desde la barra lateral de revisión. Usa la configuración de Customization para modificar el modo del bot.
• Los comentarios de resumen No Issues Found de Devin Review siempre se ignoran. Solo los comentarios con hallazgos reales activan corrección automática.

​

Atribución de commits y comentarios

• Las detecciones de errores, marcas y anotaciones automatizadas siempre se muestran como Devin bot.
• Cuando un usuario escribe un comentario o una revisión a través de Devin Review, aparece bajo la identidad de GitHub del usuario.
• Cuando un usuario le pide al agente de chat que haga un cambio de código, el commit resultante se realiza como Devin bot.
• GitHub Suggested Changes sigue el comportamiento estándar de GitHub: cualquier revisor (incluido Devin) puede dejar una edición sugerida en un comentario de revisión. Cuando un usuario hace clic en «Apply suggestion», el commit es creado por ese usuario, de la misma manera que en GitHub.
• Devin nunca creará commits ni comentarios en nombre de un usuario sin que el usuario inicie explícitamente la acción.

​

AGENTS.md / Archivos de instrucciones

• **/REVIEW.md
• **/AGENTS.md
• **/CLAUDE.md (sin distinguir entre mayúsculas y minúsculas)
• **/CONTRIBUTING.md (sin distinguir entre mayúsculas y minúsculas)
• .cursorrules
• .windsurfrules
• .cursor/rules
• *.rules
• *.mdc
• .coderabbit.yaml / .coderabbit.yml
• greptile.json

​

Reglas de revisión personalizadas

1. Ve a Settings > Review
2. En Review Rules, escribe un patrón de glob de archivos (por ejemplo, docs/**/*.md)
3. Haz clic en Add

​

REVIEW.md

• Áreas de la base de código que requieren una revisión más exhaustiva
• Errores comunes o anti-patrones a tener en cuenta
• Convenciones específicas del proyecto que quienes revisan deben hacer cumplir
• Archivos o directorios que se pueden omitir de forma segura durante la revisión
• Consideraciones de seguridad o rendimiento exclusivas de tu proyecto

# Review Guidelines

## Critical Areas
- All changes to `src/auth/` must be reviewed for security implications.
- Database migration files should be checked for backward compatibility.

## Conventions
- API endpoints must include input validation and proper error handling.
- All public functions require TypeScript return types — do not use `any`.
- React components should use functional components with hooks, not class components.

## Ignore
- Auto-generated files in `src/generated/` do not need review.
- Lock files (package-lock.json, yarn.lock) can be skipped unless dependencies changed.

## Performance
- Flag any database queries inside loops.
- Watch for N+1 query patterns in API resolvers.