Revisa, prueba y corrige con Devin

Aprender a revisar un pull request con Devin antes de hacer merge es la diferencia entre delegar la implementación y delegar la responsabilidad. Esta guía es para quien trabaja con inteligencia artificial en proyectos de código y quiere entender qué revisar, cómo escribir prompts claros y por qué la decisión final siempre es humana.

La idea central es simple: puedes apoyarte en un agente para escribir código, pero tienes que verificar lo que genera igual que revisarías el PR de otra persona. Aquí veremos cómo hacerlo con las herramientas que ofrece Devin.

¿Por qué debo ser específico al escribir un prompt para un agente?

Hay dos consejos que suelen repetirse a todo el que trabaja con IA. El primero: no des por hecho que el modelo o el agente va a entender qué quieres cambiar. El segundo: no aceptes cambios a ciegas sin verificar lo que genera.

Mira este contraste. Si le dices a Devin "mejora el formulario del Chip Block", puede interpretar cosas distintas. ¿Te refieres al diseño? ¿A una funcionalidad? El resultado es difícil de acertar porque no tiene detalles para avanzar.

En cambio, un prompt específico marca la diferencia:

• Describe el problema: el formulario permite enviar entradas vacías y no limita la descripción.
• Indica el cambio: impide guardar si no hay contenido, agrega un máximo de 280 caracteres.
• Define el feedback: muestra un aviso bajo el campo y no borres lo escrito si hay error.
• Pide verificación: mantén el estilo actual, actualiza el test y revisa el flujo en el navegador.

Lo valioso no es que tenga más texto, sino que aporta una comprensión clara del problema. Eso reduce iteraciones, evita preguntas innecesarias y ahorra tokens.

¿Por qué un prompt vago gasta más tokens? Porque obliga al agente a hacer más preguntas o a generar cosas que no querías, lo que te lleva a usarlo más veces y a repetir el trabajo hasta acertar.

¿Cómo analizo los cambios de un PR dentro de Devin?

Al abrir el panel derecho y buscar el PR tres, Devin muestra el título, la rama que intenta integrar en main, cuántos archivos toca, cuántas líneas escribió y cuántas eliminó [01:57]. También indica si está listo para fusionar porque no presenta conflictos con main.

La diferencia frente a GitHub es que aquí ves el cambio de cada archivo. En un archivo nuevo casi todo aparece en verde. Si es un archivo existente, las líneas que agrega salen en verde y las que elimina o modifica salen en rojo.

Dentro del PR puedes ejecutar un análisis llamado Smart diff, una comparación más inteligente que revisar punto por punto [03:12]. Al terminar, agrupa los archivos por categorías: los de base de datos como migraciones, fuente de datos y generador de tipos; los de autorización como login, registro y gestión de sesiones con Supabase.

Esto da mucho poder. En un proyecto existente entiendes más rápido a qué pieza corresponde cada bloque de código que el PR está generando.

¿Qué revela la sección de bugs y cómo entreno a Devin con mis reglas?

Después de ver los cambios, la sección de bugs presenta las vulnerabilidades por categorías: algunas críticas, otras marcadas como avisos y otras como errores [04:38]. En el ejemplo, de diez problemas potenciales, dos quedaron señalados para investigar.

Al hacer clic en un error crítico de seguridad, Devin te lleva a la parte del código donde lo detecta y te da una recomendación para evitarlo. Puedes enviarlo al editor y generar la corrección directamente, algo más simple que ir a GitHub.

Y aquí viene un punto clave. La clasificación de un error como crítico, bug o aviso se basa en el entrenamiento del modelo de Devin y su histórico. ¿Qué pasa si tienes personalizaciones propias?

¿Cómo evito que Devin marque mis reglas como bugs? Guarda esa regla en el archivo del agente indicando "esto lo hago así en mi proyecto". En el próximo PR, Devin ignorará esa funcionalidad porque ya entiende que forma parte de tu proyecto.

Por ejemplo, uno de los flags dentro del archivo agents decía "investigar si el contrato del framework parece estar incompleto". Puede no ser un error, así que lo marcas como resuelto y el contador baja de diez a nueve.

¿Qué información aporta la descripción y la discusión del PR?

En la descripción hay dos paneles: el análisis que presenta Devin y el resumen de lo hecho. Ese resumen suele ser casi idéntico a la descripción del PR en GitHub, pero el análisis directo es lo realmente nuevo [06:14].

En el ejemplo indica que se usan base de datos, autorización, acciones del servidor y la interfaz, que agrupa el tema de la semana con el código ISO, y que todo el código es nuevo: 39 archivos agregados sin cambios a la lógica existente.

La sección de discusión tiene algo especial. Cuando se hizo el test de punta a punta, Devin decidió que ese resultado era importante y lo incluyó en el PR para que cualquiera que lo revise tenga acceso a esos resultados.

Entre los comentarios agregó detalles concretos:

• El login por Magic Link, con una corrección implementada.
• La cronología semanal con su lote y sus etiquetas.
• La seguridad a nivel de función: un segundo usuario que intente usar el mismo Magic Link recibe un error 404.

Esto no se queda solo en Devin. Si abres el PR número tres en GitHub, encuentras la misma descripción y todos estos comentarios [08:20]. Para un equipo, eso ahorra tiempo: en lugar de repetir cada test, cualquiera puede verificar lo que ya se hizo, con capturas de pantalla y el detalle paso a paso.

Por cada uno de los ocho problemas potenciales, Devin añade un comentario con título, descripción y un prompt para agentes, coloreado según la gravedad. Así puedes corregirlos con el agente que prefieras y marcarlos como resueltos al implementar la solución.

Con estas herramientas revisas el código mucho mejor, pero en la etapa previa a la fusión la decisión la toma un ser humano. Identificas errores, los corriges y notificas cuando ya quedaron resueltos. El siguiente paso es llevar el espacio de trabajo a tu máquina local, donde Devin ofrece dos opciones: trabajar desde el terminal con su CLI o desde su aplicación de escritorio.

¿Cómo estructuras tú tus prompts para que un agente entienda el problema a la primera? Cuéntamelo en los comentarios.