Reflexiones sobre el uso de Devin tras un mes de ejecución de más de 20 tareas con Devin

En marzo de 2024, una nueva empresa de IA entró en escena con un respaldo impresionante: una Serie A de 21 millones de dólares liderada por Founders Fund y respaldada por líderes del sector como los hermanos Collison, Elad Gil y otras luminarias de la tecnología. ¿El equipo que hay detrás? Medallistas de oro de la Olimpiada Internacional de Informática: son el tipo de personas capaces de resolver problemas de programación que la mayoría de nosotros ni siquiera podemos empezar a comprender. Su producto, Devin, promete ser un ingeniero de software totalmente autónomo que puede conversar con usted como un colega humano, capaz de hacer de todo, desde aprender nuevas tecnologías y depurar bases de código maduras hasta desplegar aplicaciones completas e incluso entrenar modelos de IA.

Las primeras demostraciones fueron convincentes. Muestra cómo Devin completó de forma independiente una tarea de recompensa en Upwork, instalando y ejecutando un proyecto PyTorch sin intervención humana. La empresa afirma que Devin fue capaz de resolver el problema GitHub del mundo real 13.86% de extremo a extremo en el benchmark SWE-bench, unas 3 veces mejor que el sistema anterior. En un principio, sólo era accesible para un pequeño grupo de usuarios, lo que dio lugar a emocionantes tuits sobre cómo revolucionaría el desarrollo de software.

actuar como Respuesta.AI Como formamos parte de un equipo que prueba a menudo herramientas de desarrollo de IA, sentimos que Devin tenía algo diferente. Si cumple la mitad de lo que promete, podría cambiar nuestra forma de trabajar. Pero a pesar de todo el entusiasmo en Twitter, no pudimos encontrar muchos relatos detallados de personas que lo utilizaran realmente. Así que decidimos probarlo a fondo, con una variedad de tareas del mundo real. Esta es nuestra historia: un intento minucioso y real de trabajar con uno de los productos de IA más publicitados de 2024.

¿Qué es Devin?

Lo que hace único a Devin es su infraestructura. A diferencia de los asistentes de IA típicos, Devin ejecuta y pone en marcha su propio entorno informático a través de Slack. Cuando hablas con Devin, estás hablando con una IA que tiene acceso a un entorno informático completo -con navegador web, editor de código y shell- que puede instalar dependencias, leer documentación e incluso previsualizar las aplicaciones web que crea. Aquí tienes una captura de pantalla de una forma de iniciar Devin para realizar una tarea:

Una forma de iniciar a Devin en una tarea a través de Slack

Esta experiencia está diseñada para que te sientas como si estuvieras charlando con un colega. Describes lo que quieres y Devin se pone manos a la obra. A través de Slack, puedes ver cómo resuelve los problemas, solicita credenciales cuando es necesario y comparte enlaces al trabajo realizado. Detrás de las escenas, se ejecuta en un contenedor Docker, que le da el aislamiento que necesita para experimentar de forma segura al tiempo que protege su sistema.Devin también proporciona una interfaz web, que también le permite acceder a su entorno y verlo trabajar en tiempo real utilizando un IDE, navegador web, y más. Abajo hay una captura de pantalla de la interfaz web:

Éxito temprano

Nuestra primera tarea era simple pero cierta: trasladar los datos del Notion La base de datos se extrajo en Google Sheets.Devin resolvió este problema con asombrosa competencia. Navegó hasta la documentación de la API de Notion, entendió lo que necesitaba y me guió a través del proceso de configuración de las credenciales necesarias en Google Cloud Console. En lugar de limitarse a lanzar comandos de API, me guió a través de cada menú y clic de botón, ahorrando tiempo que normalmente requeriría una tediosa búsqueda en la documentación. Todo el proceso duró aproximadamente una hora (pero sólo unos minutos de interacción humana). Al final, Devin compartió un enlace a una hoja de Google perfectamente formateada que contenía nuestros datos.

El código que genera es un poco largo, pero funciona. Parece un atisbo de futuro: una IA capaz de realizar las tareas de "código pegajoso" que tanto tiempo quitan a los desarrolladores. Johno tuvo un éxito similar con Devin al crear un rastreador de planetas para desmentir afirmaciones sobre la ubicación histórica de Júpiter y Saturno. Lo más impresionante es que lo hizo enteramente desde su teléfono móvil, mientras Devin se encargaba de todo el trabajo pesado de configurar el entorno y escribir el código.

Ampliar nuestras pruebas

Basándonos en nuestro éxito inicial, aprovechamos las capacidades asíncronas de Devin. Imaginábamos tener a Devin escribiendo documentación durante las reuniones, o depurando problemas mientras nosotros nos centrábamos en el trabajo de diseño. Pero a medida que ampliábamos nuestras pruebas, aparecieron grietas. Tareas aparentemente sencillas a menudo llevaban días en lugar de horas, y Devin llegaba a callejones sin salida técnicos o producía soluciones demasiado complejas para su uso.

Aún más preocupante es la tendencia de Devin a insistir en tareas que son prácticamente imposibles. Cuando se le pidió que desplegara varias aplicaciones en un único despliegue de Railway (una función que Railway no admite), en lugar de reconocer esta limitación, Devin se pasó más de un día probando varios enfoques y amañando funciones que no existían.

Lo más frustrante no son los fracasos en sí -todas las herramientas tienen limitaciones-, sino la cantidad de tiempo que pasamos intentando salvar esos intentos.

Averiguar qué falló

En nuestro viaje, estábamos confundidos. Vimos que Devin era capaz de integrar API de forma competente y crear aplicaciones funcionales, pero tenía problemas con tareas aparentemente más sencillas. ¿Era mala suerte? ¿Lo estábamos utilizando mal?

A lo largo de un mes, registramos sistemáticamente nuestros intentos en las siguientes categorías:

1. Crear un nuevo proyecto desde cero
2. Cumplimiento del mandato de investigación
3. Análisis y modificación de proyectos existentes

Los resultados fueron desalentadores. De 20 tareas, tuvimos 14 fracasos, 3 éxitos (incluidos los 2 iniciales) y 3 resultados no concluyentes. Y lo que es más revelador, no fuimos capaces de discernir ningún patrón para predecir qué tareas tendrían éxito. Tareas similares a nuestros primeros éxitos fracasaban de forma inesperada.En el apéndice siguiente se ofrece información más detallada sobre estas tareas. A continuación resumimos nuestra experiencia en cada categoría durante el proceso:

1. Crear un nuevo proyecto desde cero

Esta categoría debería ser el fuerte de Devin. Al fin y al cabo, el vídeo de demostración de la empresa muestra cómo completa de forma autónoma tareas de recompensas en Upwork, y nuestros primeros éxitos sugieren que puede encargarse de nuevos desarrollos. Pero la realidad resultó ser más complicada.

Tomemos, por ejemplo, nuestro intento de integración con una plataforma de observabilidad Large Language Model (LLM) llamada Braintrust. La tarea estaba clara: generar datos sintéticos y cargarlos. En lugar de proporcionar una solución clara y centrada, Devin generó lo que sólo puede describirse como una sopa de código: múltiples capas de abstracción que complicaban innecesariamente operaciones sencillas. Al final abandonamos los intentos de Devin y utilizamos el Cursor Construir la integración paso a paso resultó ser más eficaz. Del mismo modo, cuando se le pidió que creara una integración entre nuestro anotador de IA y Spiral.computer, Devin produjo lo que un miembro del equipo describió como "código espagueti que era más difícil de leer que el código que había escrito desde cero". A pesar de tener acceso a la documentación de ambos sistemas, Devin parecía complicar en exceso todos los aspectos de la integración.

Quizá lo más revelador sea nuestro intento de rastreo web. Le pedimos a Devin que rastreara los enlaces de Google Scholar y los 25 artículos más recientes de los autores, una tarea sencilla para una herramienta como Playwright. Dada la habilidad de Devin para navegar por la web y escribir código, esto debería haber sido particularmente fácil de lograr. En lugar de eso, se quedó atascado en un bucle sin fin intentando analizar HTML y no pudo salir de su propio camino.

2. Mandato de investigación

Si Devin tiene dificultades con tareas específicas de codificación, ¿es probable que lo haga mejor en una tarea orientada a la investigación? En el mejor de los casos, los resultados son desiguales. Aunque puede realizar búsquedas básicas de documentos (como vimos en la primera integración Notion/Google Sheets), las tareas de investigación más complejas resultaron ser un reto.

Cuando pedimos a Devin que analizara los resúmenes de transcripción con marcas de tiempo precisas (un reto técnico específico al que nos enfrentábamos), se limitó a repetir información técnica superficialmente relevante en lugar de abordar el problema central. En lugar de explorar soluciones potenciales o identificar retos técnicos clave, proporcionó ejemplos genéricos de código que no abordaban el problema subyacente. Incluso cuando Devin parecía progresar, los resultados no solían ser lo que parecían. Por ejemplo, cuando se le pidió que creara un tema mínimo de DaisyUI como ejemplo, generó una solución que parecía funcionar. Tras una inspección más cercana, sin embargo, encontramos que el tema en realidad no hacía nada - los colores que veíamos eran del tema por defecto, no de nuestras personalizaciones.

3. Análisis y modificación del código existente

Quizá los fallos más preocupantes de Devin se producen al trabajar con bases de código existentes. Estas tareas requieren comprender el contexto y mantener la coherencia con los patrones establecidos, habilidades que deberían estar en el núcleo de las capacidades de un ingeniero de software de IA.

Nuestros intentos de conseguir que Devin manejara proyectos nbdev fueron especialmente esclarecedores. Cuando se le pidió que migrara un proyecto Python a nbdev, Devin fue incapaz de comprender la configuración básica de nbdev incluso cuando le proporcionamos una documentación exhaustiva. Aún más desconcertante fue la forma en que manejaba los cuadernos: en lugar de editarlos directamente, creaba scripts de Python para modificarlos, añadiendo una complejidad innecesaria a una tarea sencilla. Aunque ocasionalmente proporciona comentarios o ideas útiles, el código real que genera es sistemáticamente problemático.

La revisión de seguridad reveló problemas similares. Cuando le pedimos a Devin que evaluara un repositorio de GitHub (menos de 700 líneas de código) en busca de vulnerabilidades de seguridad, se pasó de la raya, marcando muchos falsos positivos y falseando problemas que no existían. Este tipo de análisis es probablemente mejor manejado por un Large Language Model (LLM) en lugar del enfoque más sofisticado de Devin.

Este patrón continuó durante las tareas de depuración. Al investigar por qué el reenvío de claves SSH no funcionaba en el script de instalación, Devin se centró en el propio script y nunca consideró que el problema pudiera estar en otra parte. Este efecto peek-a-boo significó que no nos ayudó a descubrir la causa raíz real. Del mismo modo, cuando se le pidió que añadiera una comprobación de conflicto entre la entrada del usuario y los valores de la base de datos, un miembro del equipo pasó horas estudiando los intentos de Devin antes de darse por vencido y escribir él mismo la función en unos 90 minutos.

Reflexiones en equipo

Tras un mes de pruebas intensivas, nuestro equipo se reunió para poner en común nuestra experiencia. Estas citas son las que mejor expresan nuestros sentimientos:

Las tareas que puede realizar son tan pequeñas y bien definidas que es mejor que las haga a mi manera más rápido. Creo que probablemente fracasará en tareas más grandes y que me ahorren tiempo. Como resultado, no hay casos reales en los que realmente quiera utilizarlo.- Johno Whitaker

Al principio estaba muy emocionada porque estaba muy cerca y me parecía que podía modificar cosas. Luego, poco a poco, me fui frustrando al tener que cambiar cada vez más y, al final, llegué al punto de que era mejor hacerlo poco a poco desde cero.- Isaac Flath

Devin tenía dificultades para utilizar las herramientas internas de AnswerAI, lo que entre otras cuestiones dificultaba su uso. A pesar de la extensa documentación y ejemplos que proporcionamos a Devin, esto sigue siendo un problema. He encontrado que esto no es un problema con herramientas como Cursor, donde hay más oportunidades para dirigir las cosas en la dirección correcta de una manera más incremental.- Hamel Husain

En comparación con Devin, descubrimos que los procesos más impulsados por los desarrolladores (como Cursor) evitaban la mayoría de los problemas que encontrábamos en Devin.

llegar a un veredicto

La colaboración con Devin demuestra la visión del desarrollo autónomo de IA. La experiencia de usuario es excepcional: chatear a través de Slack, verlo trabajar de forma asíncrona, ver cómo configura entornos y gestiona dependencias. Cuando funciona, es impresionante.

Pero ahí radica el problema: rara vez funciona. De las 20 tareas que intentamos, vimos 14 fracasos, 3 resultados inciertos y sólo 3 éxitos. Aún más preocupante fue nuestra incapacidad para predecir qué tareas tendrían éxito. Incluso tareas similares a nuestros primeros éxitos fracasaron de forma compleja y lenta. Lo que parecía una autonomía prometedora se convirtió en una carga: Devin se pasaba días buscando soluciones imposibles en lugar de identificar los obstáculos subyacentes.

Esto refleja un patrón que hemos observado repetidamente en las herramientas de IA. El entusiasmo de las redes sociales y las valoraciones de las empresas tienen poco que ver con la utilidad en el mundo real. Las señales más fiables que hemos encontrado proceden de historias detalladas de usuarios que ofrecen productos y servicios. Por ahora, nos quedamos con las herramientas que nos permiten dirigir el proceso de desarrollo a la vez que proporcionan asistencia de IA.

Apéndice: Intento de misión de Devin

La siguiente tabla enumera los proyectos que le dimos a Devin, clasificados por los siguientes temas: (1) creación de nuevos proyectos, (2) investigación, (3) análisis de bases de código existentes y (4) modificación de bases de código.

1. Creación de nuevos proyectos

2. Estudios de aplicación

3. Análisis del código existente

4. Modificación de proyectos existentes