Para construir cualquier proyecto con Devin necesitas un repositorio de código, y ese es justamente el lugar donde Devin crea ramas, ejecuta comandos, abre pull requests y se conecta a herramientas de terceros. Pero nada de esto ocurre sin permisos, y aquí aprenderás cómo gestionarlos para que un agente de IA trabaje sobre tu GitHub sin bloquearse.
Esto es clave si eres developer y quieres que Devin automatice la creación de un repositorio, genere un plan de proyecto y lo documente, todo desde Devin Cloud.
Qué permisos necesita Devin para GitHub y herramientas de terceros
Todo arranca en Devin Cloud con una idea concreta: crear una app llamada Shiplog para loguear los avances semanales de todos tus proyectos. Antes de construir, conviene preguntar en modo ask qué permisos requiere el agente.
En ese modo pregunta, Devin interactúa con el modelo automático y revisa el historial de proyectos que ya creaste. En este caso asume un stack de Next.js más Supabase y lo compara con cuatro proyectos previos para deducir qué necesita el nuevo.
Los permisos que identifica son sencillos:
- Para GitHub, solo un permiso de escritura (write), salvo que quieras que Shiplog cree issues y comente PRs con el resumen semanal.
- Para Supabase, las variables de entorno estándar que nunca se commitean y van en un archivo local.
- Opcionales como un cron o scheduler con Vercel o Supabase, más recomendaciones de Resend y hosting.
¿Qué permiso de GitHub necesita Devin para crear un proyecto básico? Solo necesita permiso de escritura (write). Ese permiso basta para crear ramas, abrir pull requests y editar archivos. Si quieres que además comente PRs o cree issues, debes dar acceso adicional a pull requests.
Devin entrega un resumen en una cajita reutilizable. Si tu proyecto es de equipo, puedes llevarla a Confluence o a un chat en Slack para elaborar un plan más cercano.
Cómo pedirle a Devin un plan sin que escriba código todavía
Aquí viene lo interesante: en la misma sesión cambias del modo automático al modo plan. El prompt es explícito sobre qué es Shiplog, cuál es el stack y, sobre todo, deja claro que por ahora no quiere que escriba ni modifique nada dentro del repositorio.
La instrucción incluye cinco tareas específicas para el agente:
- Analizar la idea.
- Hacer preguntas antes de construir cualquier cosa y esperar respuestas.
- Proponer un MVP pequeño con esas respuestas.
- Dividir el plan en tareas claras para implementar después.
- Mantener el alcance simple, sin incluir todas las features desde el inicio.
Dividir el plan en tareas separadas abre la puerta a usar multiagentes, donde cada tarea corre con el modelo más enfocado para ese trabajo. Lo esencial es repetir la restricción: no ejecutar nada ni escribir código hasta aprobar el plan explícitamente.
¿Para qué sirve el modo plan en Devin? El modo plan hace que Devin analice la idea y proponga una estructura de tareas sin tocar el código. Es útil para definir el MVP y validar preguntas antes de que el agente empiece a construir.
Devin responde con un plan de cinco preguntas directas: si Shiplog es multiusuario, cómo persisten los datos, si el registro de avance es manual o automático, el modelo de datos mínimo, el periodo del registro, las vistas de interfaz mínima y el alcance explícito del MVP.
Por qué el modo ask no puede crear repositorios en Devin
Un detalle importante sobre los modos: al pedir que cree un repositorio y guarde el plan como markdown estando en modo ask, Devin responde que no puede crear repositorios ni escribir archivos directamente, porque en ese modo solo tiene herramientas de lectura sobre código.
La solución es simple. Devin deja el plan listo para que otro agente lo ejecute en una nueva sesión. Al iniciar esa sesión, crea Shiplog como un único archivo markdown en apenas 26 segundos, conectándose a GitHub desde su máquina virtual.
El repositorio queda público, pero con un matiz: el nombre del archivo quedó como README en lugar de plan. Con una instrucción más, Devin renombra el archivo a plan.md y deja un README mínimo solo con el título.
Quién aparece como autor del commit en Devin
En el commit inicial, el autor puede aparecer como tú, como Devin solo o como Devin en colaboración contigo. Esto se ajusta desde las configuraciones de Devin. En este ejemplo estaba marcado para que saliera con la cuenta personal desde el inicio.
Y aquí hay un contraste útil: cuando Devin trabaja de manera integrada desde la nube, el commit sí llega con coautoría, mostrando la cocreación entre tu cuenta y el agente.
Cómo trabajar sobre un repositorio que ya existe en Devin
Una vez tienes el repositorio, puedes abrir una sesión nueva en modo agente y pegar el link del repositorio para trabajar sobre él. Tambien puedes integrarlo dando acceso directo desde la configuración de repositorios.
Aquí aparece un punto que conviene recordar siempre: cada sesión de Devin en la nube se trabaja en una máquina virtual independiente. Por eso, al pedirle trabajar en el repositorio, lo primero que hace es clonar erasmo/shipblog y revisar el README actual, porque no tiene el contexto de la sesión anterior.
Devin amplía el README con idea, alcance del MVP, stack y roadmap, y entrega un pull request. Ese PR documenta el proyecto para quien llega por primera vez y enlaza al plan que se va a ejecutar.
¿Cada sesión de Devin comparte el mismo entorno? No. Cada sesión corre en una máquina virtual distinta y aislada. Por eso Devin vuelve a clonar el repositorio en cada sesión nueva y no conserva el contexto de trabajos anteriores.
Para cerrar el flujo le pides mergear el PR a main. Hay acciones extra como review with Devin, pero requieren autorización adicional: hasta ese momento Devin solo puede crear y editar repositorios, abrir pull requests, pero no comentarlos ni revisarlos. Esos permisos de pull requests se trabajan aparte, por ejemplo con la CLI.
Déjame saber en los comentarios si los permisos que le diste a tu GitHub te permitieron mergear el PR.
