# The Devil Is in the Interface: Evaluating How Tool Architecture Shapes Coding Agent Behavior
> Ficha editorial pública de Research IA. Estado: Lectura primaria completa. La interpretación editorial no sustituye la fuente primaria.

- Página canónica: https://luiseduardodemiguel.com/research-ia/papers/devil-interface
- Fuente primaria: https://arxiv.org/abs/2608.11386
- Versión leída: v1
- Fuente comprobada: 2026-08-20 · método, resultado y límites revisados; fuente primaria enlazada
- Autores: Xiangzhe Xu, Hamidreza Saghir, Qianhui Wu y colaboradores; Purdue, Microsoft Research y University of Chicago
- Fecha del corte: 11 AGO 2026
- Área: AGENTES · CODING · HARNESS

## Tesis y contexto

El estudio compara seis arquitecturas de herramientas sobre 11.700 trayectorias. Las interfaces estructuradas mejoran la consistencia hasta 4,7×; algunas configuraciones reducen pasos y tokens sin perder rendimiento.

- Problema: Solemos atribuir el resultado al modelo y olvidar que la API, la búsqueda, el formato de salida y el orden de las herramientas también forman parte de la inteligencia efectiva.
- Por qué importa: La unidad real de producto deja de ser modelo más prompt. Es modelo más herramientas más interfaz más memoria más políticas más recuperación. Esa composición se puede diseñar y medir.

## Evidencia reportada

- **reported-result**: Sobre 11.700 trayectorias, las interfaces low-level estructuradas mejoran la consistencia hasta 4,7×; la búsqueda en lenguaje natural aumenta más de 11% el acceso a archivos relevantes y la interfaz Python mantiene un rendimiento similar con 41,6% menos pasos y 56,3% menos tokens. [localizador](https://arxiv.org/html/2608.11386v1#S3.T2)

## Lectura y límite

- Método: Compara arquitecturas de herramientas para observar cuánto cambia la conducta de un agente cuando cambia la interfaz que le rodea, aunque el modelo de fondo permanezca igual.
- Límite: La arquitectura óptima depende del entorno, de las herramientas disponibles y de cómo se define una tarea completada. No hay una interfaz universal.
- Confianza editorial: Alta
- Limitación: La evaluación se concentra en SWE-bench Live, tres actores y un entorno de reparación de repositorios; no demuestra el mismo efecto en dominios con otras herramientas o consecuencias.
- Limitación: Menos pasos o tokens no equivalen por sí solos a más corrección: una interfaz puede ahorrar coste y ocultar errores si no se registra la recuperación y la trazabilidad.

## Localizadores de evidencia
- [Fuente primaria · canonical](https://arxiv.org/abs/2608.11386): tipo abstract
- [Resumen](https://arxiv.org/html/2608.11386v1): tipo abstract
- [Método · §2.2–2.3](https://arxiv.org/html/2608.11386v1#S2.SS2): tipo section
- [Tabla 2 · consistencia](https://arxiv.org/html/2608.11386v1#S3.T2): tipo table
- [Figuras 3–4 · exploración y eficiencia](https://arxiv.org/html/2608.11386v1#S3.F3): tipo figure
- [HTML · fuente navegable](https://arxiv.org/html/2608.11386): tipo abstract

## Próxima prueba

- ¿Una interfaz estructurada mejora la repetibilidad sin reducir la capacidad del agente para explicar y recuperar sus fallos?
- Métrica: Pass@1, pass^5, pasos, tokens, precisión de archivos explorados y tasa de recuperación tras un error.
- Regla de parada: Parar si Atomic no mejora al menos 10% relativo en pass^5 o aumenta más de 20% los tokens sin mejorar la resolución.

## Recursos reproducibles
- [Código y datos · GitHub](https://github.com/XZ-X/tool-arch-study)

## Enlaces relacionados

- [SKILLER](https://luiseduardodemiguel.com/research-ia/markdown/papers/skiller)
- [SkillSentry](https://luiseduardodemiguel.com/research-ia/markdown/papers/skillsentry)
- [Diagnosis Before Recovery](https://luiseduardodemiguel.com/research-ia/markdown/papers/diagnosis-before-recovery)