Crear apps, depurar repositorios y montar CI/CD con Devin

A quién le sirve. Equipos técnicos que se plantean un agente para tareas repetitivas de código y publicación, teniendo en cuenta que la reseña se basa en demostraciones.

Qué hicieron

El autor de la reseña no ejecutó Devin: se apoyó en los vídeos de demostración de Cognition y en informes de usuarios con acceso anticipado. En ellos, Devin trabaja en una terminal de Linux con navegador y GitHub. Construyó una app de tareas con React y Express, depuró un repositorio público y envió una PR (propuesta de cambios para revisar), y preparó Docker, la publicación y las cadenas de CI/CD (pruebas y publicación automáticas).

Cómo salió

La reseña considera a Devin fuerte con el código repetitivo y las funciones bien especificadas, y más flojo con refactorizar código antiguo, la lógica compleja y las instrucciones vagas. Un probador de la versión beta dijo que Devin hizo el 90 % de la preparación de un servidor en Node.js y dejó solo limpieza.

Conviene saber

Estos resultados salen de demostraciones y de relatos de segunda mano, no de pruebas propias. Al publicarse, Devin estaba en beta cerrada y sin precio, y la reseña dice que su código sigue necesitando revisión.

Qué necesitas

• Acceso a Devin, el agente de programación de Cognition (cuando se escribió la reseña estaba en beta cerrada, así que mira su disponibilidad actual)
• Un repositorio en GitHub, la carpeta en línea donde vive tu código, y una rama de pruebas, que es una copia del código para probar sin tocar la principal
• Un destino de alojamiento donde publicar la app
• Conocimientos básicos de Docker y CI/CD, o alguien que revise lo que prepare el agente

Cómo hacerlo tú, paso a paso

1. Elige una tarea concreta y bien especificada. Las instrucciones vagas dan peores resultados.
2. Dale acceso a tu repositorio con los permisos mínimos y haz que trabaje en una rama de pruebas.
3. Pídele que configure Docker, para que la app se construya y se ejecute igual en cualquier ordenador.
4. Pídele una cadena de CI/CD, que son pasos automáticos que prueban y publican el código cada vez que cambias algo. Puede ser con GitHub Actions u otro sistema.
5. Pídele que lo compruebe en la rama de pruebas y que escriba un README, que es un texto con los pasos para ejecutarlo.
6. Revisa la PR (la propuesta de cambios) y la configuración de publicación antes de aceptar nada.
7. Sigue tú los pasos del README en otro ordenador para comprobar que funcionan.

En mi repositorio [enlace del repositorio], configura Docker para que la app se construya y se ejecute en local, y añade después una cadena de CI/CD con [GitHub Actions u otro sistema] que ejecute las pruebas y publique en [destino de alojamiento]. Habrás terminado cuando la cadena pase en una rama de pruebas y yo pueda seguir los pasos de tu README para ejecutarlo. Antes de publicar nada en producción, párate y enséñame la configuración de publicación.

Consejos

• La reseña recoge demostraciones y relatos de segunda mano, no pruebas propias. Haz tu propia prueba pequeña antes de fiarte.
• Con código antiguo, lógica compleja o instrucciones vagas rinde peor. Dale tareas claras y repetitivas.
• No le des acceso a producción, que es la versión que usan tus clientes. Haz que trabaje en una rama de pruebas y revisa tú el paso a producción.

Preguntas frecuentes

Fuentes

• fritz.ai ↗

En el directorio desde el 3 de octubre de 2026.