IA 360
Actualidad

Cognition presenta Devin, un agente de IA para programar de principio a fin

La startup Cognition ha presentado Devin, un agente de IA que recibe encargos de programación, crea un plan y trabaja con terminal, editor y navegador. La empresa asegura que supera a otros sistemas en el benchmark SWE-bench.

4 min de lectura Generado con IA Read in English
Cognition presenta Devin, un agente de IA para programar de principio a fin

El 12 de marzo de 2024, Cognition presentó Devin como un agente capaz de planificar, editar código, usar una terminal y comprobar su trabajo dentro de un entorno propio. El anuncio original aporta demostraciones y una puntuación en SWE-bench; prueba una configuración concreta sobre incidencias verificables, no que el sistema pueda asumir toda la responsabilidad de un ingeniero.

La propuesta llega en un momento en que asistentes como GitHub Copilot o ChatGPT ya se han incorporado al trabajo de muchos desarrolladores. La diferencia es de alcance: aquellos suelen responder a peticiones concretas dentro del flujo de trabajo del programador; Devin aspira a encargarse de una tarea completa y devolver el resultado.

Un agente que puede usar herramientas

Cognition describe a Devin como un agente, es decir, un sistema que no solo genera texto o código, sino que decide una secuencia de acciones para alcanzar un objetivo. Ante un encargo, puede elaborar un plan, buscar documentación en internet, abrir archivos de un repositorio, ejecutar comandos y comprobar el comportamiento del programa que está modificando.

El sistema también puede pedir aclaraciones al usuario cuando encuentra una ambigüedad. Esa capacidad es importante en programación: una petición aparentemente sencilla puede ocultar requisitos sobre seguridad, compatibilidad, rendimiento o la forma en que debe usarse una aplicación.

En su demostración, Cognition mostró a Devin aprendiendo tecnologías desconocidas a partir de documentación, corrigiendo errores en proyectos de código abierto y creando una aplicación web. Son tareas habituales en equipos de software, aunque una demostración controlada no equivale al trabajo mantenido sobre un producto real.

La referencia: SWE-bench

Para sostener su anuncio, Cognition utilizó SWE-bench, una prueba basada en incidencias reales de repositorios públicos de GitHub. El reto consiste en resolver errores y solicitudes de cambio a partir de la descripción que dejaron sus mantenedores, y validar después la solución con pruebas automáticas.

La empresa afirma que Devin resolvió sin asistencia el 13,86% de los casos del conjunto de prueba. Como comparación, Cognition indicó que el anterior mejor resultado era del 1,96%. Fuente primaria.

La cifra merece atención, pero también contexto. Resolver alrededor de uno de cada siete problemas no convierte al sistema en un sustituto general de un ingeniero de software. SWE-bench mide incidencias concretas y verificables; el desarrollo profesional incluye entender necesidades de negocio, negociar prioridades, revisar decisiones de arquitectura y responsabilizarse de un sistema cuando falla.

Aun así, el avance es relevante porque evalúa algo más exigente que completar una función aislada: obliga al modelo a moverse por un proyecto existente, interpretar un fallo y modificar el código sin romper otras partes.

De copiloto a delegación de trabajo

La llegada de Devin refleja un cambio en la carrera por automatizar la programación. Durante los últimos dos años, el producto dominante ha sido el copiloto: una herramienta que acelera al desarrollador proponiendo código, explicando funciones o redactando pruebas. Los agentes plantean otro modelo: delegarles una tarea delimitada y supervisar el resultado.

Eso puede ser útil para corregir incidencias repetitivas, preparar prototipos, actualizar dependencias o investigar fallos con una primera propuesta. También puede reducir el tiempo dedicado a tareas que hoy consumen horas de navegación entre documentación, repositorios y registros de errores.

Pero la autonomía añade riesgos prácticos. Un agente con acceso a una terminal puede instalar paquetes, cambiar configuraciones o introducir dependencias vulnerables si no existe revisión humana. El código que supera una prueba automática tampoco garantiza que sea mantenible, seguro o adecuado para la infraestructura de una empresa.

Cognition, cofundada por el programador competitivo Scott Wu, ha anunciado que ofrecerá acceso temprano a Devin. Su capacidad real se medirá fuera de las demostraciones y los benchmarks: en proyectos con requisitos imprecisos, sistemas antiguos y revisiones de código de profesionales que tendrán que decidir si las soluciones del agente merecen llegar a producción.

Un agente es un bucle con permisos

El modelo propone una acción, la herramienta la ejecuta, el entorno devuelve un resultado y el modelo decide el paso siguiente. La autonomía procede de repetir ese ciclo, no de una categoría mágica distinta del asistente. Por eso la unidad de seguridad es el conjunto: instrucciones, herramientas, credenciales, red, repositorio y condición de parada.

Antes de delegar se limita el directorio, se bloquean secretos, se usa una rama aislada y se exige confirmación para publicar, instalar o borrar. El agente puede ejecutar pruebas, pero una prueba que ya era incompleta puede aprobar un cambio incorrecto. Revisión de diferencias, análisis de dependencias y una persona responsable siguen siendo necesarios antes de producción.

Qué mide SWE-bench

El artículo de SWE-bench construye tareas a partir de incidencias y cambios reales de repositorios Python. Eso añade contexto, navegación y verificación frente a completar una función aislada. Aun así, la métrica es la proporción de problemas cuya prueba termina satisfecha bajo el protocolo; no mide negociación con un cliente, mantenimiento futuro ni el daño de una dependencia.

Una comparación debe conservar versión del conjunto, modelo, instrucciones, herramientas, presupuesto y número de intentos. Si un sistema recibe pistas o selecciona el mejor de varios parches, ya no es la misma condición. El porcentaje sirve cuando la columna de condiciones viaja con él; separado del protocolo se vuelve publicidad.

Delegar empieza por definir “hecho”

Una tarea necesita aceptación observable: pruebas nuevas que fallen antes y pasen después, estilo, seguridad y explicación del cambio. También requiere una salida segura cuando la especificación es ambigua. Pedir aclaración puede ser mejor conducta que modificar archivos con confianza.

La capacidad transferible es encerrar un agente en un trabajo verificable: alcance, permisos mínimos, criterio, registro y revisión. Ese patrón permite aprovechar exploración y automatización sin confundir movimiento en una terminal con responsabilidad de ingeniería.

El registro convierte autonomía en evidencia

Cada comando, archivo modificado, resultado de prueba y decisión debe quedar en un rastro legible. No basta un resumen generado al final: el revisor necesita reconstruir qué observó el agente antes de actuar. Las credenciales se representan por permisos, nunca se copian al registro, y los datos sensibles se redactan sin perder la secuencia.

Una evaluación de seguridad añade incidencias adversarias: documentación que contiene instrucciones maliciosas, paquetes con nombres parecidos, pruebas que intentan acceder a la red y solicitudes que exigen borrar. Se puntúa si el agente reconoce el límite y pide permiso. Resolver más tareas mientras acepta órdenes hostiles no es una mejora neta.

El tiempo humano también se mide. Preparar la tarea, responder dudas, revisar el parche y reparar errores puede superar el ahorro de generación. El agente aporta valor cuando reduce el ciclo completo con una tasa de aceptación conocida, no cuando produce muchas líneas que después hay que rehacer.

Para comparar con un copiloto se mantiene el mismo desarrollador y la misma incidencia. En una condición recibe sugerencias; en otra delega dentro del recinto definido. Se registran resultado, tiempo, intervenciones y defectos posteriores. Así la palabra “autónomo” se convierte en una diferencia de flujo observable.

Los parches rechazados son datos. Se clasifican por comprensión, navegación, implementación, prueba y seguridad para saber dónde interviene el humano. Si los fallos se concentran en requisitos ambiguos, mejorar la especificación puede aportar más que cambiar de modelo.

El despliegue empieza con tareas reversibles y repositorios de bajo riesgo. Solo después de una tasa estable se amplían permisos. La autonomía no se concede por marca: se gana por evidencia acumulada en el entorno concreto.

Una tarea cerrada termina con parche, pruebas, explicación y reversión disponible. Si falta cualquiera de esas salidas, el trabajo sigue abierto aunque el agente declare que ha terminado. La evidencia, no el mensaje final, cierra el encargo.

Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.

Compartir este artículo

Este sitio web utiliza cookies para mejorar la experiencia de navegación. Política de cookies.

↑↓ navegar ↵ abrir esc cerrar