Cómo los Agentes de Código Están Transformando la Infraestructura de IA (y Qué Significa para Tu Próximo Deployment)
La Guerra de los Asistentes de Código con IA: ¿Está Tu Infraestructura Lista para el Futuro?
El Problema Que Nadie Vio Venir
Basta de discutir si Claude Code, Codex o Gemini CLI son mejores. Ya superamos esa fase. Ahora la verdadera pregunta es otra: ¿Puedes servir estas herramientas a escala sin que tu presupuesto se dispare o tu latencia haga que los desarrolladores estrellen el teclado contra la pared?
Un estudio reciente del laboratorio SyFI de la Universidad de Washington acaba de soltar números concretos sobre cómo funcionan realmente los agentes de código en producción. Y lo que encontraron debería hacer que reconsideres todo lo que creías saber sobre tu infraestructura de LLM serving.
Qué Es TraceLab y Por Qué Importa
Antes de entrar en datos, un poco de contexto. TraceLab es la iniciativa de investigación que recopiló información real sobre cómo los desarrolladores usan asistentes de código con IA. No benchmarks sintéticos ni pruebas controladas de laboratorio. Datos reales de miles de sesiones.
El equipo capturó más de 4,300 sesiones con aproximadamente 55 mil millones de tokens. Siete ceros. Así de grande es el dataset. Y los patrones que emergieron contradicen muchas suposiciones que tenemos sobre cómo funcionan estos agentes.
Lo Que Realmente Pasa Cuando Pides "Arregla Este Bug"
Aquí viene lo interesante. Cuando un desarrollador le pide a un agente que implemente una funcionalidad o resuelva un problema, no está iniciando un simple pregunta-respuesta. Está arrancando un proceso autónomo donde el modelo va a razonar, ejecutar comandos de terminal, leer y modificar archivos, correr tests, e iterar hasta quedar satisfecho (o hasta que tú lo interrumpas).
Los números lo confirman: cada solicitud de usuario genera un promedio de 8.8 ciclos de herramienta-LLM antes de completarse. Ocho ciclos. Casi nueve vueltas de generación seguida de ejecución de herramienta. El modelo no solo está hablando: está actuando. Y aquí está el detalle que cambia todo: el 88% de todas las rondas de inferencia no ocurren como respuesta al usuario, sino como respuesta a resultados de herramientas.
Esto tiene implicaciones enormes para planificar tu throughput. Los chatbots tradicionales son básicamente sistemas request-response con algún seguimiento ocasional. Los agentes de código son procesos autónomos de larga duración con cambios de contexto constantes entre fases de generación y ejecución. Tus políticas de autoscaling, tu cola de peticiones, tus estrategias de cacheo: todo necesita repensarse.
El Asimetría Que Está Saboteando Tu Cache
Prepárate para este número porque es impactante: las entradas superan a las salidas en una proporción de 294 a 1.
En los traces analizados, los modelos leyeron 52.56 mil millones de tokens de entrada en cache y prefillaron 2,340 millones de tokens nuevos. ¿Cuánto generaron? Solo 186.9 millones de tokens de salida. Una ronda típica tiene un prefijo de 32K a 256K tokens y añade apenas unos pocos cientos a unos pocos miles antes de decodificar un par de cientos.
Esto crea un perfil de rendimiento completamente diferente al que la mayoría de sistemas de LLM serving están optimizados. La inferencia tradicional de modelos de lenguaje se enfoca mucho en throughput de generación: ¿cuántos tokens por segundo podemos producir? Pero para agentes de código, el bottleneck frecuentemente no es la velocidad de decodificación; es el time-to-first-token (TTFT) después de que la ejecución de herramienta regresa.
El equipo encontró que el TTFT de Codex para cada paso ronda los 3.1 segundos, lo que representa aproximadamente el 25% del tiempo total de generación de cada ronda. Cuando estás haciendo nueve rondas por solicitud, esa sobrecarga se compounding rápido.
La historia del cacheo también es más matizada de lo que parece inicialmente. Sí, el cacheo de entrada ayuda con el contexto masivo que cargan los agentes de código. Pero la carga de prefill se divide entre tokens en cache y tokens nuevos que necesitan computación real. Los prefill cortos e incrementales después de ejecución de herramientas tienen características de rendimiento diferentes a la carga inicial de contexto largo. Los sistemas de serving necesitan manejar ambos eficientemente.
Los Comandos de Shell Dominan el Panorama
Si pensabas que los agentes de código estarían haciendo razonamiento sofisticado y refactoring complejo, no estabas equivocado, pero la realidad es más desordenada.
De los 433,000 llamados a herramientas capturados en los traces, el 76% fueron ejecuciones de shell o comandos. Correr builds, tests, operaciones de git, manipulaciones de archivos a través de herramientas CLI: el trabajo menos glamoroso que forma el día a día real del desarrollo de software.
Las ediciones de archivos representaron el 11%, las lecturas y búsquedas de archivos el 9%, con planificación, delegación a sub-agentes y búsquedas web ocupando el resto.
Esta concentración en comandos de shell importa por varias razones:
Primero, son operaciones de cola larga. Un simple ls es rápido, pero correr un suite completo de tests o compilar un codebase grande puede tomar minutos. La distribución de latencia abarca cuatro órdenes de magnitud, lo que convierte la planificación de capacidad en una pesadilla.
Segundo, el vocabulario de herramientas varía significativamente entre agentes. Claude Code usó 54 herramientas diferentes mientras Codex usó 31, pero ambos concentraron la vasta mayoría de su volumen en el mismo núcleo: shell, ediciones de archivos, lecturas de archivos. Esto sugiere que optimizar para estas herramientas de alta frecuencia podría generar mejoras desproporcionadas, incluso sin abordar todo el ecosistema de herramientas.
Cómo Afecta Esto Tu Infraestructura
Si estás construyendo u operando herramientas de desarrollo potenciadas por IA, esta investigación señala varias conclusiones concretas:
Piensa en workflows, no en requests. Tu infraestructura de serving necesita adaptarse a la naturaleza autónoma y de múltiples pasos de los agentes de código. Esto significa contextos de requests de mayor duración, gestión de estado más sofisticada, y oportunidades de batch scheduling que agrupen llamados a herramientas relacionados.
Optimiza para los gaps de inactividad. Los usuarios pasan un promedio de 46.7 minutos entre requests, a pesar de que el tiempo de pensamiento medio es de solo 1.4 minutos. La distribución es extremadamente de cola pesada: algunos desarrolladores iteran rápidamente mientras otros inician un request y vuelven horas después. Estrategias inteligentes de prefetching y re-prefill durante estos períodos de inactividad podrían reducir drásticamente la latencia percibida sin aumentar costos de computación.
Separa tus rutas de prefill y decode. La proporción de 294:1 significa que tu computación de prefill es probablemente tu costo dominante. Los prefill incrementales después de ejecución de herramientas necesitan optimización diferente a la carga inicial de contexto. Considera pools de recursos separados o políticas de scheduling para estos tipos de workload.
No olvides la infraestructura de ejecución de herramientas. Cuando el 76% de la actividad del agente son comandos de shell, tu orquestación de contenedores, patrones de acceso a filesystem y cacheo de herramientas de build se convierten en preocupaciones de primera clase para el serving de agentes de IA. La inferencia del modelo es solo parte del pipeline.
Hacia Dónde Vamos
El equipo de TraceLab ha liberado su pipeline de recolección y análisis de traces como código abierto, haciendo posible que equipos de infraestructura generen sus propios traces y optimicen para patrones de uso reales en lugar de benchmarks sintéticos. Este tipo de datos del mundo real es exactamente lo que el espacio de infraestructura de IA necesita mientras madura de "hazlo funcionar" a "hazlo funcionar a escala."
Para nuestra comunidad de NameOcean Vibe Hosting, estos insights destacan por qué estamos invirtiendo en infraestructura que va más allá de la simple asignación de GPU. Servir agentes de código con IA no se trata solo de computación bruta: se trata de entender las características únicas de workloads agentic y construir sistemas que puedan manejar la realidad autónoma, de múltiples pasos y pesada en herramientas de cómo los desarrolladores realmente usan estas herramientas.
La era del agente de código apenas está comenzando, y las decisiones de infraestructura que tomemos hoy van a dar forma a la eficiencia con la que estas herramientas sirven a los desarrolladores durante años. El que se prepare hoy, lidera mañana.