Crear una página de ofertas por pasos con Devin

A quién le sirve. Equipos de programación que quieren probar a repartir una tarea en pasos pequeños para un agente, sin que se gaste todo el presupuesto de golpe.

Qué hicieron

La ingeniera conectó a Devin los repositorios de la parte interna y de la parte visible mediante su integración con GitHub, y dejó que preparara su propio entorno. Le dio el esquema de datos de las ofertas, un diagrama de la base de datos y los números de las PR (propuestas de cambio de código) de trabajo relacionado aún sin aprobar. Devin dividió la tarea en sesiones separadas, abrió una PR con la primera parte y reintentó los arreglos que exigían las comprobaciones automáticas de estilo y de TypeScript. Cada parte posterior tuvo su propia sesión, con PR basadas en las anteriores.

Cómo salió

La primera PR se abrió en menos de 10 minutos pero no pasó las comprobaciones. Las siguientes fueron aceptables pero con cambios de más, y Devin afirmó por error que Joi no se usaba en ningún otro sitio. La última sesión, la de poner el proyecto en marcha en local, topó con los límites de uso.

Conviene saber

Las sesiones separadas no comparten contexto, así que la división no se puede ejecutar en paralelo. Gastó las 150 unidades de uso (ACU) en menos de una semana, y la documentación dice que el rendimiento baja pasadas 10 por sesión.

Qué necesitas

• Una cuenta de Devin con unidades de uso suficientes
• Los repositorios del proyecto en GitHub, que son las carpetas donde se guarda el código, conectados a Devin
• El esquema de datos y un diagrama de la base de datos de lo que vas a construir
• Una lista de pasos pequeños para la tarea
• Comprobaciones automáticas en el repositorio, que avisan si un cambio rompe algo

Cómo hacerlo tú, paso a paso

1. Conecta a Devin los repositorios de la parte visible y de la parte interna de tu proyecto mediante su integración con GitHub.
2. Déjale preparar su propio entorno de trabajo.
3. Dale el contexto: el esquema de datos, el diagrama de la base de datos y las PR, que son propuestas de cambio de código, relacionadas que aún no estén aprobadas.
4. Divide la tarea en pasos pequeños y pide una sesión para cada uno.
5. Pide que abra una PR por cada parte, que pasen las comprobaciones automáticas y que no haga cambios fuera de lo pedido.
6. Revisa cada PR tú o alguien del equipo. Mira sobre todo los cambios de más y lo que el agente afirma sobre el código.
7. Deja para el final lo de poner el proyecto en marcha en local y vigila el gasto de unidades.

En [nombre del repositorio], implementa [página o función, por ejemplo una página de ofertas] en pasos pequeños: [paso 1], luego [paso 2], luego [paso 3]. Abre una PR al terminar los pasos, asegúrate de que pasan las comprobaciones automáticas y no hagas cambios fuera de lo pedido. Si no estás seguro de cómo funciona una librería, mira su documentación y dime qué has comprobado y qué has supuesto. Habrás terminado cuando la PR esté abierta y las comprobaciones pasen.

Consejos

• Las sesiones no comparten contexto entre sí, así que no se pueden ejecutar en paralelo. Pasa a cada una lo que necesita.
• Vigila el gasto: en el caso se acabaron las unidades en menos de una semana, y la documentación dice que el rendimiento baja en sesiones largas.
• Pide que diga qué ha comprobado y qué ha supuesto. En el caso afirmó por error que una librería no se usaba en otro sitio.

Preguntas frecuentes

Fuentes

• qubika.com ↗

En el directorio desde el 12 de octubre de 2026.