Devin CLI: mergea PRs y corre Supabase local

Si trabajas cerca del código y no quieres abrir otra sesión remota, el Devin CLI te deja usar agentes de IA directamente en tu terminal, dentro del repo y con tus herramientas. Está pensado para desarrolladores que ya están en el flujo de trabajo y necesitan velocidad sin salir del editor.

Lo interesante de esta herramienta es que reúne casi todos los modelos públicos conocidos en un solo lugar. Puedes trabajar con OpenAI, Anthropic, Google, Moonshot, DeepSeek, Groq y otros, algo que pocas CLIs de este estilo permiten.

Cómo instalo el Devin CLI en mi máquina

Para empezar, vas a devin.ai/cli, donde encuentras la documentación y el comando de instalación. Ahí mismo hay videos y recomendaciones según tu sistema operativo.

La herramienta funciona en macOS y Windows. En macOS tienes dos caminos:

• Instalación directa con el comando indicado en la web.
• Instalación vía Homebrew.

Una recomendación clave: si vas a trabajar con GitHub, instala también el CLI de GitHub. Esto le da acceso a Devin a tus repositorios para leer un PR, hacer pull requests o cerrar ramas directamente desde la terminal.

¿Para qué sirve el GitHub CLI con Devin? Le permite a Devin interactuar con tus repositorios sin salir de la terminal: leer PRs, mergearlos o cerrarlos. Todo mantiene tu usuario como autor de las acciones.

Cómo verifico que el CLI quedó instalado

Dentro de la terminal, ejecutas el comando devin en cualquier carpeta. Si responde con el logo, el título y el número de versión, ya está instalado y disponible [02:07].

Al abrirlo también ves el tipo de plan que tienes y el porcentaje de uso que te queda en la semana, con la fecha de renovación. Para salir usas el comando exit.

Cómo entiendo un repositorio nuevo con Devin

Después de clonar tu repositorio con git clone y entrar con cd, puedes abrir Devin dentro del directorio y pedirle que explique el proyecto. Esto es útil cuando llegas nuevo a un equipo o pruebas un repo desconocido.

Antes de lanzar el comando conviene elegir bien el modelo. La recomendación aquí son los modelos de Cognition, específicamente el SWE 1.7, que es gratuito: no consume tokens ni uso semanal [05:32]. Para usarlo necesitas una cuenta Pro en adelante.

Un detalle importante sobre las sesiones: si ejecutas algún comando, Devin genera un nombre aleatorio para identificar esa sesión. Puedes retomarla con devin -r seguido del nombre, o listar las sesiones recientes con el mismo comando.

Cómo mergeo varios pull requests sin generar conflictos

En el ejemplo, el proyecto shiplog tenía tres pull requests abiertos y solo dos archivos en la rama main. Al preguntarle a Devin si los PRs se podían mergear en orden, el modelo simuló los merge locales usando comandos del GitHub CLI.

El análisis fue detallado:

• El PR uno y el PR tres modifican ambos el README desde main, así que se solapan.
• Del PR uno al dos y del dos al tres no hay conflictos.
• Cualquier orden que incluya uno y tres genera conflicto.

La recomendación del modelo fue mergear el PR dos primero. Al autorizar con la instrucción "mergea en el orden que no genere conflictos", Devin mergeó el dos y el tres, y dejó el uno abierto por el conflicto en el README [09:15].

¿Qué es un conflicto de merge? Ocurre cuando dos ramas modifican la misma parte de un archivo y Git no sabe cuál versión conservar. En el ejemplo, dos PRs editaban el README y sus cambios se pisaban.

Luego le pedimos cerrar el PR uno. Devin ejecutó gh pr close 1, cerró el PR y borró la rama asociada. Cada PR genera una rama independiente que apunta a main.

Un punto valioso: al hacer estas acciones desde el CLI, mantiene tu usuario como autor, igual que si lo hicieras manualmente en GitHub.

Cómo corro el proyecto localmente desde Devin

Con los PRs mergeados en main, puedes pedirle a Devin que ejecute un servidor local. El proyecto no solo tenía frontend, también un backend basado en Supabase, así que necesitas dos cosas instaladas:

• El Supabase CLI.
• Docker Desktop.

Devin lee el package, revisa las variables de entorno y detecta que faltan dependencias. Antes de instalar cualquier cosa pide autorización, y aquí aparece la primera interacción real con el agente.

Las opciones al aprobar un comando son varias:

• Permitirlo solo esta vez.
• Permitir ese tipo de comando para la sesión.
• Permitirlo para el proyecto completo.
• Permitirlo para todos los proyectos.

Existe un modo /bypass que evita las preguntas, pero no se recomienda: siempre debes tener control de qué comandos ejecuta el agente.

Qué levanta Supabase en local con Docker

Devin abre Docker Desktop automáticamente y crea un proyecto que toma el nombre de la carpeta, en este caso Shipblock. Dentro se levantan las instancias del backend:

• La base de datos y las analíticas de Supabase.
• Los vectores con authorization, los buckets y el storage.
• El real time, el API rest y el edge runtime.
• El Studio local, para no depender de la nube de Supabase.

Con el Studio corriendo localmente puedes ver el editor de tablas, las entradas, el editor de SQL, authentication y storage, todo sin ir a supabase.com. En teoría puedes trabajar sin conexión, salvo cuando necesites instalar dependencias [16:40].

Devin agrega al archivo de variables de entorno la URL de Supabase y el publishable key generado. El frontend con Next.js corre en el localhost 3001 porque el 3000 estaba ocupado, y también levanta Mailpit para simular correos y probar los Magic Links.

Ese flujo del Magic Link solo aplica cuando Supabase usa ese método de acceso. Si tu proyecto tiene registro con usuario y contraseña, no necesitas la validación por email.

El CLI brilla mientras sigues cerca del código, pero si una tarea crece o necesitas desconectarte, puedes mandarla a la nube sin empezar desde cero. ¿Ya probaste el modelo SWE 1.7 gratuito en tus repos? Cuéntame cómo te fue en los comentarios.