Revisar un PR generado por un agente de inteligencia artificial como Devin exige la misma rigurosidad que revisar el código de un compañero humano. Si trabajas con agentes de IA en proyectos reales, esta guía te muestra cómo escribir prompts específicos y cómo auditar cada cambio antes de aprobarlo.

Hay dos reglas que repito a cualquiera que trabaje con IA. La primera: no asumas que el modelo va a entender lo que quieres cambiar, sé específico [00:14]. La segunda: no aceptes los cambios a ciegas. Delegar la implementación no significa delegar la responsabilidad [00:30].

Por qué un prompt específico ahorra tokens y tiempo

La diferencia entre un prompt vago y uno detallado no es la cantidad de texto, sino el entendimiento claro del problema que le entregas al agente.

Mira el contraste. Si le dices "mejora el formulario de Chip Block", Devin puede interpretar diseño, funcionalidad o cualquier otra cosa, y acertar se vuelve casi imposible [01:03]. En cambio, un prompt como este marca la diferencia:

En Chip Block, el formulario permite enviar entradas vacías y no limita la descripción. Impide guardar si no hay contenido, agrega un máximo de 280 caracteres, muestra feedback debajo del campo y no borres lo escrito si existe un error. Mantén el estilo actual, agrega o actualiza test y verifica el flujo en el navegador [01:27].

Ese nivel de detalle reduce las iteraciones. Con el prompt vago, el agente pregunta más, genera cosas que no querías y te obliga a gastar más tokens y más uso del agente [02:03].

¿Por qué un prompt específico ahorra tokens en un agente de IA? Porque le das un entendimiento claro del problema y de los cambios a realizar, lo que reduce las iteraciones. Menos iteraciones significan menos consumo de tokens y mayor probabilidad de cerrar el problema.

Cómo revisar los cambios de archivos dentro de Devin

Todo el avance de la fase uno quedó registrado en el PR tres, que puedes ver desplegando el panel de la derecha [02:38].

El PR te muestra el título, la rama que propone mergear a main, la cantidad de archivos, las líneas escritas y las líneas borradas. Dice que está listo para mergear porque no tiene conflictos con main [03:05]. Pero aquí viene el detalle importante: dentro de Devin puedes ver el cambio de cada archivo sin salir a GitHub.

En un proyecto nuevo verás casi todo en verde. Si hubo modificaciones sobre un archivo existente, las líneas agregadas salen en verde y las eliminadas o modificadas en rojo [03:38].

Una función potente aquí es el Smart Diff, una comparativa más inteligente que revisar punto por punto cada archivo [04:04]. Al terminar el análisis, Devin categoriza los archivos según la parte del proyecto a la que corresponden:

• Base de datos: migraciones, fuente de datos primarios y generador de tipos.
• Authorization: login, registro y manejo de sesiones de Supabase con Client, Session Proxy, callback y login [05:00].

Esto te permite entender a qué pieza corresponde cada código, algo clave cuando haces un PR sobre un proyecto existente.

Qué hacer con los bugs y flags que detecta Devin

Después de los cambios, el apartado de bugs clasifica vulnerabilidades y errores por categorías, marcando cuáles son críticos, cuáles son avisos y cuáles quedan flagueados para investigación [05:45].

Al hacer clic en cualquiera, Devin te redirige a la pieza de código donde detecta el error de seguridad y te da una recomendación para corregirlo. Puedes pasarle ese fix al editor para que lo genere automáticamente [06:07].

En el ejemplo había dos flags marcados para investigación. Uno, dentro del archivo Agents, decía "investigar que el contrato del framework parece estar incompleto" [06:50]. Como quizá no sea un error real, puedes marcarlo como resuelto y el conteo baja.

Y aquí hay algo muy importante. La clasificación de errores como críticos, bug o warning se basa en el entrenamiento del modelo de Devin, no en tus reglas [07:20]. Si tu proyecto tiene customizaciones, puedes documentarlas en el archivo Agent para que la próxima vez Devin ignore esa funcionalidad y deje de marcarla como bug [07:35].

¿Cómo evito que Devin marque mi código custom como bug? Documenta tus reglas específicas en el archivo Agent. En el siguiente PR, Devin entenderá que esa funcionalidad es parte de tu proyecto y dejará de flaguearla como error.

Cómo leer la descripción, el resumen y las discusiones del PR

La descripción del PR trae dos paneles: el análisis que entrega Devin y el sumario de lo que hizo [07:56].

Ese análisis es nuevo frente a lo que ves en GitHub. Explica qué se está haciendo: uso de bases de datos, authorization, server actions, la interfaz y el agrupamiento del tema de la semana con el código ISO. Al final confirma que todo el código es nuevo, con 39 archivos agregados y sin modificaciones a lógica existente [08:28].

La sección de discusión guarda algo especial. Cuando corriste el end-to-end test, Devin decidió que el resultado era importante y lo dejó en el PR para cualquiera que fuese a revisarlo [08:56]. Allí quedaron registrados el login por Magic Link, un fix aplicado, el timeline por semana con su batch y los tags, y el row-level security que devuelve error 404 si un segundo usuario intenta usar el mismo Magic Link [09:27].

Devin Review encontró ocho errores potenciales y dejó dos para investigar, sumando diez en total [09:51].

Por qué los comentarios del PR también aparecen en GitHub

Todo esto no vive solo dentro de Devin. Si vas a GitHub, el mismo PR tres trae la descripción y todo el contenido en forma de comentarios [10:14].

Esto importa cuando no eres la única persona en el proyecto. Cualquiera que revise el PR tendrá la información de cada test ya realizado, lo que le ahorra tiempo: en lugar de repetir el test, solo revisa qué se hizo [10:35]. Hay un desplegable con el paso a paso de cómo se obtuvieron los tres screenshots.

Por cada uno de los ocho potential issues, Devin agregó un comentario con un título, una descripción y un prompt para agentes [11:21]. Ese prompt sirve si usas distintos agentes y quieres corregir el mismo issue. El color del comentario indica la criticidad de cada error, y puedes marcarlo como resuelto una vez aplicada la solución [11:50].

Con estas herramientas revisas el código mucho mejor, pero la decisión final antes de mergear debe tomarla un humano [12:12]. Identificas errores, los corriges y notificas cuando una conversación queda resuelta.

El siguiente paso es mover el trabajo a tu máquina local, donde Devin ofrece dos opciones: la terminal con su CLI y la aplicación de escritorio con interfaz visual [12:38].

¿Ya probaste escribir prompts específicos para tus propios PRs? Cuéntame en los comentarios cómo te fue.