SWE-agent: Cómo el diseño de interfaces desbloquea la ingeniería de software automatizada

La semana pasada leí el artículo de SWE-bench y me quedé con una conclusión simple: GPT-4 puro apenas resuelve el 1.96% de los problemas reales de GitHub. Esta semana quería entender la pregunta siguiente: ¿qué es lo que realmente hace que ese número aumente? SWE-agent de Yang et al. (NeurIPS 2024) lo responde, y la respuesta es engañosamente aburrida: mejores interfaces.

El artículo

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan y Ofir Press; Princeton / Stanford) introduce el concepto de una Interfaz Agente-Computadora (ACI) —una capa de software construida a propósito que se sitúa entre un LLM y un entorno Linux, diseñada no para usuarios humanos, sino para la forma en que los modelos de lenguaje procesan realmente la información. La tesis es que el diseño de esta interfaz, y no el modelo subyacente, es el principal cuello de botella para los agentes autónomos de ingeniería de software.

El sistema opera sobre problemas de GitHub de SWE-bench: lee el problema, navega por el repositorio, localiza el código relevante, lo edita y ejecuta pruebas para verificar la solución. La contribución novedosa no es un nuevo modelo o procedimiento de entrenamiento, sino un conjunto de primitivas de comandos y formatos de retroalimentación cuidadosamente diseñados que reemplazan la shell de Linux por defecto.

Ideas clave

• La interfaz supera a la shell pura en 10.7 puntos porcentuales. En una ablación sobre 300 instancias de SWE-bench Lite, SWE-agent resuelve un 10.7% más de problemas que un agente idéntico lanzado a una shell de Linux básica. Esa es la palanca más importante del artículo.
• Visor de archivos con ventanas de 100 líneas. En lugar de usar cat para archivos enteros, la ACI muestra ~100 líneas por turno con comandos de desplazamiento. Muy poco contexto (30 líneas) cuesta 3.7pp; demasiado contexto (archivo entero) hace que el modelo pierda el foco. El punto óptimo es estrecho.
• Un linter en el bucle de edición. Cada comando de edición ejecuta un verificador de sintaxis antes de confirmar el cambio. Esto evita que el modelo se quede atrapado en estados de código roto que son difíciles de escapar solo mediante lenguaje natural.
• Búsqueda de directorios minimalista. En lugar de grep -r con contexto circundante (que abrumaba al modelo), la ACI devuelve solo una lista de nombres de archivos coincidentes. Menos es más cuando el modelo necesita decidir dónde mirar a continuación.
• Resultado completo del benchmark: 12.47% en SWE-bench con GPT-4 Turbo, frente a un sistema RAG no interactivo del 3.8% y un 1.96% para la línea base de recuperación simple del artículo original de SWE-bench. HumanEvalFix alcanzó el 87.7%.
• El diseño de ACI se generaliza. Una variante de ciberseguridad (SWE-agent EnIGMA) aplicó la misma filosofía de ACI a desafíos de CTF, logrando un 13.5% —tres veces más fuerte que los sistemas anteriores— utilizando herramientas de agentes interactivos que mantienen sesiones de shell concurrentes.

Lo que se mantiene — y lo que no

La idea central —que el diseño de interfaces para agentes es tan importante como la ingeniería de prompts— está bien respaldada y me parece genuinamente útil. La ablación es honesta: los autores aíslan los componentes y muestran lo que aporta cada uno. La ganancia de 10.7pp sobre la línea base de la shell pura es un resultado claro que no puede explicarse por diferencias de modelos.

Lo que me convence menos: el benchmark en sí mismo. El conjunto de pruebas de SWE-bench contiene problemas que varían enormemente en complejidad, ambigüedad y en qué tan bien especificado está el parche de referencia (ground-truth). La alta varianza en la calidad de los problemas significa que la cifra del 12.47% es en parte una declaración sobre qué problemas resultaron estar en el conjunto de evaluación. Los autores señalan esto implícitamente al informar resultados en SWE-bench Lite (300 problemas) para las ablaciones, pero la varianza dentro de ese subconjunto sigue siendo alta.

La limitación más grande es el alcance: SWE-bench mide la resolución de un solo problema de forma aislada. No hay memoria de sesión entre problemas, ni comprensión del historial de la base de código, ni seguimiento de dependencias entre múltiples problemas. SWE-Bench Pro (arXiv:2509.16941, 2025) mostró más tarde que incluso los modelos de frontera caen por debajo del 25% cuando los problemas requieren cambios coordinados en múltiples archivos; el rendimiento decae bruscamente a medida que aumenta el número de archivos. La ACI ayuda dentro de un solo problema, pero el problema difícil es el caso de largo horizonte y múltiples archivos que SWE-agent nunca fue diseñado para abordar.

También hay una cuestión de reproducibilidad a la que sigo volviendo: las elecciones de diseño de la interfaz (ventana de 100 líneas, salida de búsqueda minimalista) se encontraron mediante experimentación iterativa en la división de entrenamiento/desarrollo. Estas elecciones no son obviamente transferibles a nuevos dominios sin un esfuerzo de ajuste similar. Ese es un coste real.

Por qué esto importa para la IA en finanzas

El marco de la ACI se aplica directamente al problema de diseño de agentes para Beancount. Un libro de contabilidad de Beancount no es una línea de comandos, pero es un artefacto estructurado que un modelo necesita leer, navegar y escribir. Las lecciones se transfieren:

• Un visor de libros que muestre entre 20 y 50 transacciones a la vez —con comandos de desplazamiento y filtrado— superará a uno que vuelque 10 años de datos de golpe. El desbordamiento de la ventana de contexto es el mismo modo de fallo.
• Un validador de escritura que verifique el equilibrio de la partida doble y la existencia de las cuentas antes de confirmar una entrada es el equivalente contable del linter de SWE-agent. Sin él, un agente que produce una entrada sintácticamente errónea no tiene forma de recuperarse.
• La búsqueda minimalista importa: consultar "muéstrame todas las transacciones en la cuenta X entre las fechas Y y Z" debería devolver una lista compacta y escaneable, no un volcado verboso con contexto innecesario.

El artículo también establece un punto de referencia práctico sobre qué esperar de las primeras versiones de un agente de escritura para Beancount. Una tasa de resolución del 12.47% en problemas de GitHub bien definidos es el techo actual para un agente de un solo problema cuidadosamente diseñado. La escritura en libros contables implica una estructura de tareas similar —una intención del usuario, un archivo estructurado, una salida requerida, un verificador— y yo esperaría tasas comparables en tareas bien definidas, con una degradación aguda en flujos de trabajo de múltiples entradas y múltiples cuentas.

Qué leer a continuación

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — La gestión de contexto de SWE-agent es reactiva (truncar al desbordar); MemGPT propone una memoria por niveles proactiva, lo que parece necesario para agentes que necesitan razonar sobre libros de Beancount de varios años.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — Sigue directamente donde SWE-agent se queda corto; los datos de degradación en múltiples archivos son lectura esencial para diseñar la seguridad de escritura en libros contables complejos.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — Si la ACI trata sobre el diseño de interfaces, Gorilla trata sobre la recuperación de APIs; ambos se combinan en una imagen más completa de cómo los agentes deben seleccionar e invocar herramientas de manera confiable.