El Devin CLI te permite trabajar con agentes de IA directamente desde tu terminal, cerca del código, sin abrir otra sesión remota. Es útil para desarrolladores que ya están en su repositorio y quieren revisar pull requests, mergear ramas o levantar servidores locales sin cambiar de contexto.

Lo interesante es que, a diferencia de otras herramientas similares, el Devin CLI deja acceder a casi todos los modelos públicos conocidos: OpenAI, Anthropic, Google, Moonshot, DeepSeek y Groq, entre otros. Eso te da libertad para elegir el modelo que mejor encaje con cada tarea.

Cómo instalo el Devin CLI en mi sistema operativo

Para empezar, entra a devin.ai/cli. Ahí encuentras la documentación, el comando de instalación, videos y recomendaciones. La herramienta funciona en macOS y Windows, cada uno con sus propios comandos [00:34].

En macOS tienes dos caminos: instalación directa o instalación vía Homebrew. Elige el que prefieras según tu flujo de trabajo.

Una recomendación clave: si vas a trabajar con GitHub, instala también el CLI de GitHub en tu máquina. Esto permite que cada comando que interactúe con GitHub (leer un PR, hacer pull request) tenga acceso a tus repositorios sin fricción [01:01].

¿Qué necesito para que Devin interactúe con mis repos de GitHub? Debes tener instalado el CLI de GitHub (gh). Así Devin puede leer PRs, mergear ramas y cerrar pull requests desde la terminal usando tu usuario.

Cómo valido que Devin CLI quedó instalado

Para confirmar la instalación, ejecuta el comando devin en cualquier carpeta. Si responde con el logo, el título Devin CLI y el número de versión, ya está disponible en tu sistema [01:48].

Además, la terminal te muestra tu tipo de plan y el porcentaje de uso que te queda en la semana. En el ejemplo, el plan se renueva en tres días y 13 horas [02:17].

Si no es el directorio donde quieres trabajar, escribe exit para cerrar Devin CLI y seguir navegando con normalidad.

Cómo clono un repositorio y retomo sesiones previas

Para clonar tu repo usas git clone con el link, directamente con Git y no con Devin. Luego entras con cd shiplog y ya estás dentro del directorio [02:48].

Un detalle importante sobre las sesiones: cuando ejecutas un comando dentro de Devin, te entrega una línea para retomar esa sesión con devin -r seguido de un nombre aleatorio que identifica la conversación. También puedes ver sesiones recientes con ese mismo comando [03:28].

¿Cómo retomo una sesión anterior en Devin CLI? Usa el comando devin -r con el nombre que Devin asignó a la sesión. Ese nombre se genera de forma aleatoria y aparece al final de cada interacción.

Por qué conviene usar el modelo SWE 1.7 de Cognition

Antes de pedirle que explique el proyecto, vale la pena cambiar de modelo. Uno recomendado para este tipo de trabajo es el de Cognition, específicamente el SWE 1.7, que es gratuito [05:16].

Si lo seleccionas, cualquier comando que uses no te cuesta tokens ni consumo. Eso sí: para usarlo necesitas una cuenta Pro en adelante.

Con una instrucción como "explica qué hace este proyecto", el modelo entrega respuestas muy detalladas. Es ideal cuando pruebas repositorios nuevos o acabas de entrar a un equipo de trabajo.

Cómo mergeo pull requests sin generar conflictos

Aquí viene una de las partes más potentes. Al pedirle "tenemos varios PRs abiertos, dime si se pueden mergear en orden", Devin no solo revisa el código descargado, sino que va al historial usando el comando gh del CLI de GitHub [06:50].

En el ejemplo, Devin simuló los merges locales y detectó la tensión: el PR uno y el PR tres modifican ambos el README desde main, así que los cambios se solapan y generan conflicto. Su recomendación fue clara: mergear el PR dos primero [08:00].

Al darle la orden "mergea en el orden que no genere conflictos", Devin ejecutó estos pasos:

• Mergeó el PR dos sin conflictos.
• Mergeó el PR tres sin conflictos.
• Dejó abierto el PR uno porque el README generaba conflicto.

Después de analizarlo, le pedimos cerrar el PR uno. Devin ejecutó gh pr close 1, cerró el pull request y borró la rama asociada [09:42].

Un punto valioso: todas las interacciones con GitHub aparecen bajo tu usuario, porque el CLI mantiene la configuración que ya tienes en la nube [10:48].

Cómo levanto un servidor local con front-end y Supabase

Una vez mergeados los PRs, puedes pedirle a Devin que ejecute un servidor local para ver el proyecto. El reto es que este incluye front-end y un back-end basado en Supabase [11:40].

Para levantar el back-end localmente necesitas dos cosas:

• Tener el Supabase CLI instalado.
• Tener Docker Desktop instalado.

Con eso, Devin lee el package, revisa el archivo de variables de entorno y detecta que faltan dependencias. Antes de instalarlas, te pide autorización, que es la primera interacción real con el agente en el proyecto [12:50].

Las opciones de permiso van desde "probarlo una vez" hasta permitir el comando para toda la sesión, el proyecto completo o todos los proyectos. Existe un modo bypass con /bypass, pero no se recomienda: siempre conviene mantener control de qué comandos ejecuta el agente [13:40].

Qué levanta Supabase cuando corre de forma local

Como Devin ejecuta comandos de Docker, primero abre Docker Desktop y luego inicializa Supabase con npx supabase start. Toma el nombre del proyecto desde la carpeta donde estás ubicado [15:50].

Docker despliega varias instancias:

• La base de datos y las analíticas de Supabase.
• Los vectores, buckets, real time y el API rest.
• El storage, el edge runtime y el estudio local.

El estudio local es especialmente útil porque te deja trabajar sin ir a supabase.com. En teoría puedes trabajar sin conexión a Internet, aunque siempre necesitarás red para instalar dependencias [17:30].

¿Puedo trabajar con Supabase sin conexión a Internet? Sí, si ya tienes instaladas todas las dependencias y el entorno de Supabase local levantado. Solo necesitas Internet para instalar nuevas dependencias.

Cómo pruebo el login con Magic Links usando Mailpit

Una vez corriendo, Devin levanta el Next.js dev server en el localhost 3001 porque el 3000 ya estaba ocupado, y abre un preview del proyecto [18:40].

Para probar la autenticación por Magic Link, Devin incluye Mailpit, que simula un servidor de correo electrónico. Escribes un correo, lo envías y abres Mailpit desde el enlace que entrega la terminal [19:30].

Ahí aparece el sign in link. Al hacer clic, obtienes acceso. Este proceso solo aplica cuando usas Magic Links; si tu proyecto maneja usuario y contraseña, no pasas por la validación de email [20:30].

Todo esto ocurre cerca del código, sin salir de la terminal. Y cuando una tarea crece o necesitas desconectarte, puedes enviarla a la nube sin empezar desde cero. ¿Ya probaste el Devin CLI en tu propio repo? Cuéntame qué modelo elegiste.