Prepara tu workspace y repositorios

Aprender a crear un repositorio con Devin y generar un plan de proyecto es el primer paso para que este agente de IA trabaje por ti dentro de tu código. Aquí vas a ver cómo Devin crea ramas, ejecuta comandos y abre pull requests, siempre según los permisos que tú le concedas.

Todo lo que construyas con Devin vive en un repositorio de código. Ese repositorio es su terreno de trabajo: ahí crea ramas, corre comandos, abre pull requests y se conecta con herramientas de terceros. Pero nada de eso pasa sin permisos, y esos permisos los gestionas directamente en Devin.

Cómo defino qué permisos necesita Devin en GitHub

El ejemplo que seguimos es una app llamada ShipLog, pensada para que developers registren sus avances semanales en cada proyecto. Antes de escribir código, conviene preguntar qué necesita Devin para funcionar.

En Devin Cloud puedes usar el modo pregunta, o ask, para lanzarle una consulta sin que ejecute nada. Al preguntarle qué permisos requiere para GitHub y para herramientas como Supabase, Devin activa su thinking process y revisa el historial de proyectos que ya creaste antes.

Lo interesante es cómo razona: yo solo le especifiqué Supabase, y él asumió un stack de Next.js más Supabase. Luego comparó esa combinación con cuatro proyectos previos para deducir qué necesitaría el nuevo.

Estas fueron sus recomendaciones concretas:

• Para GitHub, solo un permiso de escritura o write, suficiente salvo que quieras que ShipLog cree issues y comente PRs.
• Para Supabase, las variables de entorno estándar en un archivo local, nunca commiteadas.
• Como opcionales, un cron o scheduler con Vercel o Supabase, más Resend y un hosting.

¿Qué es el modo ask en Devin? Es un modo de solo lectura donde Devin responde preguntas y analiza tu código, pero no crea repositorios ni escribe archivos. Sirve para explorar antes de ejecutar.

Devin también entrega un resumen en una cajita reutilizable. Si tu proyecto es de equipo, puedes llevar ese texto a Confluence o a un canal de Slack para elaborar un plan más aterrizado.

Por qué usar el modo plan antes de escribir código

Con el resumen inicial listo, el siguiente paso es pedir un plan explícito. Para eso cambias del modo automático al modo plan dentro de la misma sesión.

En el prompt de plan conviene ser muy específico. Yo le indiqué que ShipLog sería una app sencilla para developers, le di el stack, y le pedí que por ahora no escribiera ni modificara nada en el repositorio. Su única tarea: ayudarme a armar el plan.

Le asigné cinco tareas concretas para estructurar ese plan:

1. Analizar la idea del proyecto.
2. Hacerme preguntas antes de construir cualquier cosa y esperar mis respuestas.
3. Proponer un MVP pequeño con esas respuestas.
4. Dividir el plan en tareas claras e implementables después.
5. Mantener un alcance simple, sin meter todas las features desde el inicio.

Dividir el trabajo en tareas separadas abre una puerta interesante: podrías implementarlas con multiagentes, asignando a cada tarea el modelo que dé mejor resultado. Y aquí viene lo importante que repetí varias veces: que no ejecute ninguna tarea ni escriba código hasta aprobar el plan explícitamente.

Devin respondió con un plan que incluía cinco preguntas directas: si ShipLog es multiusuario, cómo persisten los datos, si el registro de avances es manual o automático, cuál es el modelo de datos mínimo, y cuáles serían las vistas y el alcance del MVP.

Cómo Devin crea el repositorio y guarda el plan

Cada sesión de Devin en la nube corre en su propia máquina virtual independiente. Ese detalle explica varios comportamientos que vas a notar.

Cuando cambié al modo automático y le pedí crear un repositorio y guardar el plan como archivo markdown, la sesión en modo ask respondió que no podía: solo tenía herramientas de lectura sobre el código. Entonces inicié una nueva sesión de Devin desde ese mismo plan.

Esa nueva sesión sí creó el repositorio de ShipLog en 26 segundos, conectándose a GitHub desde su máquina virtual. Un detalle a corregir: nombró el archivo como README en lugar de plan, así que le pedí renombrarlo a plan.md y dejar un README mínimo solo con el título.

¿Por qué Devin no recuerda lo que hizo en otra sesión? Porque cada sesión usa una máquina virtual distinta y aislada. Al abrir una sesión nueva sobre un repositorio, primero clona el repo y revisa su estado actual para recuperar contexto.

Esto quedó claro al abrir una tercera sesión sobre el repositorio ya existente. Lo primero que hizo Devin fue clonar erasmo/shiplog y revisar el README, porque la sesión anterior era una máquina virtual completamente distinta sin ese contexto.

Qué revela el autor del commit en Devin

El commit inicial aparecía como hecho por mi cuenta, según la configuración que tengo marcada. Pero en las opciones de Devin puedes cambiar quién figura como autor.

Existen tres formas de firmar los commits:

• Como tu propia cuenta, que es como lo tenía configurado.
• Como Devin en colaboración contigo, un commit de coautoría.
• Como Devin en solitario.

Cuando amplié el README con la idea, el alcance del MVP, el stack y el roadmap, ese commit sí llegó como coautoría: el Devin AI Integration Bot junto con mi usuario, porque se hizo de forma integrada desde su nube.

Qué límites de permisos tiene Devin en los pull requests

Devin puede abrir pull requests, pero no todo está permitido por defecto. Aquí aparecen los muros de seguridad.

Cuando quise que revisara o mergeara el PR, no pudo. Con los permisos actuales solo podía crear repositorios, editarlos y modificar archivos. No tenía acceso para comentar ni mergear pull requests, una medida de seguridad deliberada.

Esa limitación se puede resolver por otra vía, como la CLI en paralelo. Lo esencial ya quedó demostrado: Devin puede crear un repositorio desde cero o trabajar sobre uno existente, generar un plan, guardarlo como markdown y sumar un README documentado para quien llegue por primera vez al proyecto.

Déjame saber en los comentarios si los permisos que le diste a tu GitHub te permitieron mergear el PR.