Tokenomics: cuantificando dónde se usan los tokens en la ingeniería de software con agentes

 (arxiv.org)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Estudio que midió la estructura del consumo de tokens al mapear trazas de ejecución de sistemas de desarrollo de software multiagente basados en LLM a etapas del SDLC, mostrando que el consumo se concentra no en la generación inicial sino en la revisión de código y la verificación
  • En 30 tareas de desarrollo de software ejecutadas por ChatDev, se confirmó que la etapa de revisión de código usa en promedio 59.4% de los tokens, siendo el tramo de mayor consumo
  • La composición promedio de tokens en todas las tareas fue 53.9% de entrada, 24.4% de salida y 21.6% de razonamiento, lo que forma un fuerte communication tax por la transferencia repetitiva de contexto entre agentes
  • Mientras que la etapa de codificación tuvo una alta proporción de tokens de salida, con 58.0%, la etapa de documentación mostró una alta proporción de tokens de entrada, con 80.2%, diferenciando claramente los patrones de uso de tokens según la fase de desarrollo
  • Concluye que se necesitan protocolos de colaboración entre agentes más eficientes en tokens y un marco de evaluación estandarizado para predecir costos y optimizar flujos de trabajo

Resumen

  • Los sistemas multiagente basados en LLM (LLM-MA) se están aplicando cada vez más para automatizar tareas complejas de ingeniería de software como ingeniería de requisitos, generación de código y pruebas
  • Como su eficiencia operativa y consumo de recursos no se entienden lo suficiente, los costos impredecibles y el impacto ambiental dificultan su adopción en el mundo real
  • Se analizaron las trazas de ejecución de 30 tareas de desarrollo de software realizadas por el framework ChatDev con el GPT-5 reasoning model, mapeando sus etapas internas a diseño, codificación, completado de código, revisión de código, pruebas y documentación
  • Los resultados preliminares muestran que la etapa iterativa de revisión de código concentra en promedio 59.4% de los tokens, siendo el mayor foco de consumo
  • Los tokens de entrada representan consistentemente la mayor proporción, con un promedio de 53.9%, aportando evidencia empírica de una posible ineficiencia considerable en la colaboración entre agentes
  • El principal costo de la ingeniería de software con agentes no se concentra en la generación inicial de código, sino en los procesos automatizados de mejora y verificación
  • La metodología puede usarse para predicción de costos, optimización de flujos de trabajo e investigación sobre protocolos de colaboración entre agentes más eficientes en tokens

Introducción

  • La ingeniería de software a gran escala está explorando sistemas multiagente basados en LLM para automatizar tareas complejas a lo largo de todo el SDLC
  • Los frameworks LLM-MA simulan roles de equipos humanos como product manager, arquitecto, desarrollador y tester con agentes LLM especializados, que colaboran en tareas de diseño, codificación y verificación
  • En principio, los sistemas LLM-MA pueden distribuir tareas entre agentes para aumentar la autonomía y la robustez
  • Estudios previos señalan que los sistemas LLM-MA pueden fomentar el pensamiento divergente, reforzar el razonamiento y la factualidad, y escalar a problemas que superan la capacidad de un solo agente
  • En ingeniería de software, existe el potencial de automatizar de forma integrada flujos de trabajo end-to-end desde requisitos hasta pruebas
  • El framework AGENTTAXO ofrece una taxonomía para analizar la distribución de tokens en sistemas LLM-MA generales e introduce el concepto de “communication tax” para describir la sobrecarga de interacción entre agentes
  • La taxonomía de fallas MAST confirmó que muchos problemas en sistemas LLM-MA provienen de cuestiones de diseño y coordinación del sistema, como repetición de etapas y verificación incompleta, más que de limitaciones del LLM individual
  • La investigación existente analizó el comportamiento de agentes en contextos generales, pero sigue habiendo una brecha de conocimiento sobre la eficiencia de recursos en sistemas aplicados a flujos de trabajo de ingeniería de software de múltiples etapas
  • La pregunta clave para la adopción práctica, “¿a dónde van los tokens?”, aún no tiene una respuesta suficiente en el ámbito de la ingeniería de software
  • Tokenomics es el término usado para estudiar la eficiencia operativa y el consumo de recursos de los sistemas LLM-MA
  • El análisis observa la distribución del consumo de tokens al mapear las etapas internas de ChatDev a fases de desarrollo
  • ChatDev simula una empresa de software virtual, donde múltiples roles de agentes como programadores y testers completan el SDLC mediante conversaciones de múltiples turnos
  • Se ofrece un dataset curado de 30 trazas de ejecución y un paquete de replicación completo

Diseño del estudio

  • Objetivo y objeto de análisis

    • El objetivo es investigar empíricamente cómo se distribuye el consumo de tokens cuando un sistema LLM-MA realiza tareas end-to-end de desarrollo de software
    • El objeto inicial de análisis es ChatDev
    • La arquitectura “chat chain” de ChatDev representa un modelo secuencial tipo cascada de diseño → codificación → pruebas, con etapas claramente separadas, lo que la hace adecuada para mapear fases de desarrollo de software
    • ChatDev es uno de los frameworks open source populares y más citados

  • Curación del dataset

    • Se ejecutó ChatDev en 30 tareas distintas de desarrollo de software
    • Los prompts se recopilaron del ProgramDev Dataset usado en la investigación MAST
    • Los prompts seleccionados incluyen desde algoritmos simples como generar números de Fibonacci hasta aplicaciones más complejas como un juego de ajedrez
    • La diversidad se verificó con base en investigaciones recientes que sugieren que el número de tokens de razonamiento puede servir como proxy de la complejidad de la tarea
    • El rango de consumo de tokens de razonamiento en las 30 tareas va de 17,280 a 40,000, lo que sugiere suficiente diversidad en la complejidad de las tareas para el estudio
    Publicidad

  • Selección del modelo

    • El modelo base para todos los agentes fue el GPT-5 reasoning model
    • Los criterios de selección fueron la popularidad y actualidad del modelo, su adecuación a casos de uso con agentes y su fuerte capacidad de razonamiento acorde con las expectativas sobre agentes autónomos
    • La versión del modelo usada en el experimento fue gpt-5-2025-08-07
    • El parámetro temperature no está soportado en este modelo, por lo que se usó el valor predeterminado 1.0
    • La ventana de contexto es de 400,000 tokens y el máximo de tokens de salida es de 128,000 tokens
    • El knowledge cutoff es el 30 de septiembre de 2024

  • Pipeline de análisis

    • En la etapa de recolección de trazas, se instrumentó ChatDev para registrar en logs la traza completa de ejecución de cada una de las 30 tareas
    • Se capturaron el prompt, la respuesta y la cantidad de tokens de entrada, salida y razonamiento de cada llamada al LLM
    • El mapeo de etapas es la metodología central que convierte las etapas internas del framework ChatDev en fases universales de desarrollo
    • Esta abstracción permite un análisis generalizable y puede extenderse a otros frameworks LLM-MA de ingeniería de software
    • La agregación de tokens se realizó con scripts en Python
    • Las trazas recolectadas se parsearon y se sumaron los tokens por fase de desarrollo a lo largo de las 30 ejecuciones
    • Se desglosaron en tokens de entrada, salida y razonamiento

  • Mapeo entre etapas internas de ChatDev y fases de desarrollo

    • La fase de diseño corresponde a DemandAnalysis y LanguageChoose, centradas en comprender requisitos y decidir tecnologías a alto nivel
    • La fase de codificación corresponde a Coding y participa directamente en la escritura inicial del código fuente
    • La fase de completado de código corresponde a CodeComplete y termina placeholders o archivos de código incompletos dejados por la fase de codificación
    • La fase de revisión de código corresponde a CodeReview y realiza revisión, corrección y mejora del código mediante diálogos iterativos entre el agente programador y el agente revisor
    • La fase de pruebas corresponde a Test y se enfoca en pruebas dinámicas del sistema para encontrar y corregir bugs de ejecución
    • La fase de documentación corresponde a EnvironmentDoc, Reflection y Manual, que generan manuales de usuario y documentación sobre dependencias de entorno necesarias

Resultados y discusión

  • Pregunta de investigación

    • La pregunta central es cuál es el patrón de consumo de tokens de los sistemas LLM-MA en tareas de desarrollo de software
    • Entender la tokenomics de los sistemas de ingeniería de software con agentes es importante para una adopción práctica y sostenible
    • Un alto uso de tokens se conecta directamente con mayores costos financieros, consumo energético e impacto ambiental
    • Identificar dónde se consumen los tokens dentro del SDLC permite crear un “mapa de costos” útil para predicción de costos y optimización del flujo de trabajo
    • El análisis se realizó en dos ejes
    • Distribución de tokens totales por fase de desarrollo mapeada, como diseño o codificación
    • Proporción de tokens de entrada, salida y razonamiento dentro de cada fase
    Publicidad

  • Hallazgo 1: la revisión de código domina el consumo de tokens

    • El uso de tokens a lo largo del proceso de desarrollo muestra una distribución muy desigual
    • La etapa de revisión de código usa en promedio 59.4% de los tokens en el conjunto de 30 tareas, siendo el mayor tramo de consumo
    • La etapa de completado de código apareció en 6 de las 30 tareas y consumió en promedio 26.8% de los tokens en esas ejecuciones
    • La documentación consumió en promedio 20.1% y las pruebas 10.3%
    • La fase de pruebas apareció en 12 de las 30 tareas
    • La codificación inicial tuvo un costo relativamente bajo, con 8.6% en promedio, y el diseño 2.4%
    • El principal costo de la ingeniería de software con agentes se concentra no en la generación inicial del código sino en el proceso iterativo y conversacional de mejora y verificación
    • El valor n en la figura indica cuántas de las 30 tareas ejecutaron una etapa específica
    • No todas las etapas se ejecutan siempre, y los agentes dentro del sistema multiagente deciden de forma autónoma qué etapas ejecutar
    • Las barras de error representan ±1 desviación estándar e indican la variabilidad del consumo de tokens en cada etapa

  • Hallazgo 2: el consumo de tokens se centra en los tokens de entrada

    • En todas las etapas excepto codificación, los tokens de entrada superan ampliamente a los de salida y razonamiento
    • La composición promedio total del uso de tokens por tarea fue 53.9% entrada, 24.4% salida y 21.6% razonamiento
    • La proporción aproximada de 2:1 entre tokens de entrada y salida constituye una fuerte evidencia empírica del “communication tax” descrito en estudios previos
    • Los agentes consumen tokens al transferir repetidamente grandes contextos durante conversaciones colaborativas
    • En los protocolos actuales de colaboración entre agentes existe la ineficiencia de gastar la mayoría de los tokens en transmitir contexto más que en generar nueva salida
    • El communication tax puede ser una característica inherente de las arquitecturas multiagente conversacionales y requiere más investigación

  • Hallazgo 3: diferencias en el perfil tokenomic según la fase de desarrollo

    • La proporción de tokens por etapa forma patrones propios para cada actividad de ingeniería de software
    • La fase de codificación es una excepción orientada a salida, con 58.0% de salida y 6.9% de entrada
    • Esta estructura orientada a salida coincide con la naturaleza de generar código fuente extenso a partir de especificaciones de diseño concisas
    • Etapas como revisión de código y documentación, enfocadas en verificación y documentación, están orientadas a entrada
    • La proporción de entrada en revisión de código es 51.4%
    • La proporción de entrada en documentación es 80.2%
    • Estas etapas consumen código existente como gran contexto y generan salidas analíticas más pequeñas
    • Los perfiles de tokens por etapa pueden usarse como mapa de costos por actividad de ingeniería
    • Los profesionales pueden identificar mejor oportunidades para predecir costos y optimizar procesos

  • Proporción de tokens por etapa

    • La proporción promedio en diseño es 60.4% entrada, 3.6% salida y 36.0% razonamiento
    • La proporción promedio en codificación es 6.9% entrada, 58.0% salida y 35.1% razonamiento
    • La proporción promedio en completado de código es 47.7% entrada, 41.7% salida y 10.5% razonamiento
    • La proporción promedio en revisión de código es 51.4% entrada, 24.7% salida y 23.9% razonamiento
    • La proporción promedio en pruebas es 60.8% entrada, 20.7% salida y 18.4% razonamiento
    • La proporción promedio en documentación es 80.2% entrada, 8.3% salida y 11.5% razonamiento
    • La proporción promedio total por tarea es 53.9% entrada, 24.4% salida y 21.6% razonamiento
    Publicidad

  • Discusión

    • Los resultados preliminares ofrecen un mapa inicial de costos del desarrollo de software con agentes
    • El alto costo de tokens en la etapa de revisión de código puede interpretarse como un “costo conversacional”
    • Este costo surge directamente de la arquitectura conversacional de los sistemas LLM-MA, en la que los agentes intercambian repetidamente todo el contexto del código mientras lo mejoran
    • Los protocolos actuales de colaboración entre agentes para verificación pueden ser extremadamente ineficientes, al consumir enormes recursos incluso para tareas que requieren cambios pequeños
    • Esto también se alinea con los hallazgos de la clasificación MAST sobre fallas de verificación y repetición de etapas
    • El alto uso de tokens puede ser un síntoma de que los sistemas de agentes intentan superar problemas de coordinación inherentes mediante conversación forzada
    • Los profesionales pueden estimar el costo de proyectos basados en agentes según el tipo de trabajo requerido
    • Un proyecto greenfield con gran peso de codificación inicial y un proyecto centrado en refactorización o depuración de código existente tienen estructuras de costo distintas
    • En proyectos centrados en refactorización o depuración de código existente, los ciclos de revisión de código, costosos y orientados a entrada, dominan el costo
    • Integrar checkpoints de “human-in-the-loop” antes de la etapa de revisión de código puede evitar bucles iterativos costosos y servir como decisión de diseño para mejorar la eficiencia económica y computacional
    • Un reto de investigación es diseñar protocolos de colaboración más eficientes en tokens para verificación y mejora
    • Se necesitan enfoques que vayan más allá de transferir simplemente todo el contexto
    • También hace falta un marco de evaluación estandarizado y abarcador
    • Ese marco puede servir como base común para benchmarkear y comparar la eficiencia de arquitecturas LLM-MA distintas, como el flujo conversacional jerárquico de ChatDev y la línea de ensamblaje basada en SOP de MetaGPT
    • Puede funcionar como una “Rosetta Stone” que traduzca el comportamiento de cada framework a actividades universales de ingeniería de software

Amenazas a la validez y trabajo futuro

  • Amenazas a la validez

    • El análisis se basa en un solo sistema LLM-MA, ChatDev, y en un solo LLM, el GPT-5 Reasoning Model
    • Los patrones observados de consumo de tokens podrían variar en otras arquitecturas LLM-MA o en LLM con distinta eficiencia de tokens
    • Aunque las 30 tareas de desarrollo de software son diversas, podrían no representar todos los escenarios y complejidades posibles del desarrollo de software
    • El tamaño del dataset curado se debe directamente a la falta de benchmarks públicos de gran escala sobre trazas de agentes especializados en ingeniería de software
    • La curación de datos es un proceso costoso en tiempo y dinero
    • Algunas fases de desarrollo solo se ejecutaron en subconjuntos pequeños de las 30 tareas
    • El completado de código se activó rara vez, con n=6, y las pruebas con n=12
    • Por basarse en muestras pequeñas, las conclusiones sobre el perfil tokenomic de estas etapas específicas podrían tener baja representatividad y limitada generalización
    • El mapeo de etapas internas de ChatDev a fases de desarrollo de software es una abstracción
    • Aunque es un mapeo lógico y útil para construir un marco de evaluación estandarizado, es solo una de varias formas posibles de mapear la actividad de los agentes

  • Conclusión y trabajo futuro

    • En la ingeniería de software con agentes, el costo en tokens no se distribuye de forma uniforme, sino que se concentra abrumadoramente en la etapa iterativa y conversacional de revisión de código
    • Los tokens de entrada que conforman el “communication tax” representan la mayor parte del uso total de tokens y son el área clave para optimización futura
    • La primera tarea futura es ampliar el dataset con más tareas para mejorar la generalización
    • La segunda tarea es extender el análisis a otros LLM para identificar efectos según el modelo
    • La tercera tarea es extender el análisis a otros sistemas LLM-MA para comparar cómo las diferencias de arquitectura afectan la tokenomics
    • La cuarta tarea es investigar la relación entre los patrones de consumo de tokens y los modos de falla
    • La quinta tarea es seguir desarrollando y validando un marco robusto y universal de mapeo de fases de desarrollo para benchmarkear la eficiencia de agentes de ingeniería de software

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News

  • Para uso personal, armé un sistema multiagente
    Le das un problema y primero un modelo rápido y barato hace preguntas; con esas respuestas, refina el prompt de entrada
    Después divide el problema por secciones y elige una estrategia: un juez final saca la conclusión, o varios agentes debaten y luego el juez resume
    La mejor forma es lo que llamo all angles: correr varias estrategias en paralelo y que un metajuez final sintetice la respuesta
    La parte más útil de lo que agregué recientemente es una pantalla donde puedes ver la variación entre estrategias
    Lo uso para temas de vida diaria como buscar vivienda, escuelas y asuntos familiares

    • Aquí hay un demo en video de lo que hice: https://streamable.com/e49cgt
    • Mencionaste el costo; me da curiosidad si podrías explicar un poco más la estructura aproximada de costos según el tipo de problema
      También me interesa saber qué estrategias usas y cómo cambia el costo entre ellas
    • Me da curiosidad qué harness de ejecución usas y qué LLM estás usando
    • Yo también construí un sistema parecido, pero me enfoqué más en los bucles de retroalimentación que en la mejora exploratoria de prompts
      En un estilo más cibernético, hago crecer continuamente una biblioteca de validaciones deterministas y autocorrecciones para mantener estable la salida del prompt
      Los “problemas” que esa biblioteca no puede resolver se hacen visibles para la persona que está operando el proceso

  • Usé GitHub Copilot de forma continua durante un mes entero, pero después del cambio de precio al mes siguiente me acabé todos los tokens en solo dos días
    Un cambio tan brusco parece una señal de que el precio de los tokens es arbitrario y de que a los negocios de IA se les está acabando el dinero muy rápido

    • Más bien me parece que es resultado de empujar la valuación máxima o el IPO
      Incluso se rumora que el margen en inferencia supera el 70%
      Si tomas a SpaceX como ejemplo, subieron en general los precios de productos de consumo en los últimos 6 meses, pero Alphabet y Anthropic juntos están pagando más de 2 mil millones de dólares al mes, así que no es que falte dinero
      Microsoft/GitHub estaba en la posición de reempaquetar el producto de otros, así que aquí terminó perdiendo
    • El caso de GitHub es más bien una excepción que se ve especialmente brusca porque hubo un cambio reciente en la política de precios
      En general, los precios se fijan según varios factores subyacentes, y eso no significa por sí mismo que sean arbitrarios
      Por ejemplo, si los ejecutivos de GitHub hubieran decidido el precio de los tokens con un generador de números aleatorios, eso sí sería una fijación arbitraria de precios

  • Hay una parte que dice: “los tokens de entrada representan en promedio el 53.9% del consumo, la proporción más grande”, pero en mi uso la proporción es más o menos 10:1
    La abrumadora mayoría de los tokens consumidos son de entrada, y es común que un agente lea un millón de tokens para arreglar una sola línea de código
    Si está más cerca de 1:1 o la salida es mayor, diría que hay un problema con el agente o que el codebase es nuevo o está vacío

    • Me pregunto si has probado darles mejores herramientas como AST o servidores de lenguaje para que el agente pueda explorar y documentar el codebase con más facilidad
      Un millón de tokens sin caché suena bastante alto
    • Si los tokens de entrada dominan tanto el costo, eso significa que solo con aprovechar mejor el caché ya se puede lograr una mejora grande
      Podrías hacer que el modelo ejecute una etapa única de “compresión” volcando las partes relevantes del código, y usar ese resultado como prefijo cacheado para muchas llamadas de subagentes

  • Cuando usas agentes para programar, pareciera que quieren escribir miles de pruebas unitarias, pero tienen poca inclinación a probar dinámicamente

    • También les encanta quemar montones de tokens escribiendo y depurando pruebas semánticamente rotas
    • Las pruebas unitarias también son un tipo de prueba dinámica
      Las pruebas estáticas son cosas como lint o verificación de tipos
      Si quieres otros tipos de pruebas dinámicas además de unit tests, me pregunto si has intentado especificarlo como requisito desde la etapa de planeación o del PRD
    • AWS también empuja con fuerza soluciones complejas de Lambda que conectan la mayor cantidad posible de servicios facturables de AWS para requisitos simples
      Sus intereses no siempre coinciden con los tuyos
      En este caso, quieren que gastes dinero innecesariamente en trabajo inútil
      Ya estaría bueno dejar de usar el eufemismo de “tokens”
    • Solo hay que indicarles que hagan más pruebas dinámicas
      Creo que parte de la razón por la que evitan las pruebas dinámicas es que ralentizan el proceso y pueden detener el software en lugares inesperados

  • Esto me recordó un paper del año pasado que daba información de presupuesto para optimizar la eficiencia en el uso de tokens
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • Esto se parece a las millas de recompensa de las aerolíneas y, desde la perspectiva de una empresa, no tiene ninguna ventaja frente a alquilar tiempo de GPU bare-metal

    • Ojalá esta etapa horrible termine pronto, a medida que más empresas de hardware saquen NPU baratas y el tamaño de los modelos se optimice mejor
      Una vez que la mayor parte de la demanda de IA pueda cubrirse con hardware y modelos on-premise o on-device, me pregunto para qué servirán esas megagranjas de cómputo y modelos con costos operativos tan altos
      Probablemente los únicos clientes que queden sean los grandes gobiernos, y al final los contribuyentes terminarán pagando los miles de millones que invirtió el cártel de la IA

  • En diciembre escribí un post en Substack sobre este tema: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

  • Antes, empresas como Google contrataban ingenieros viendo qué tan bien podían optimizar la infraestructura
    Pronto puede que las empresas empiecen a fijarse en la capacidad de un ingeniero para optimizar la eficiencia de tokens de IA

    • Eso requiere asumir que los tokens seguirán siendo un costo relevante
      No es fácil estar seguro de que los desarrolladores encontrarán nuevos usos para gastar más tokens tan rápido como bajen los precios
    • Sé cómo bajar a 0 el costo de tokens de una empresa
      Solo trátalos como un servicio público tipo internet y haz que los ingenieros los paguen de su bolsillo

  • Como rama curiosa del tema, estuve en una reunión para revisar un posible producto nuevo; iba bastante bien hasta que apareció una pantalla diciendo que le habían agregado IA al producto
    Obviamente traía IA y se notaba muchísimo que estaba metida con calzador
    Una de las cosas que lo delataba era que había una columna mostrando cuántos tokens costaba cada consulta
    Pregunté quién pagaba el costo de los tokens y me dijeron que estaba incluido en la licencia; luego pregunté si había un límite de presupuesto o si era ilimitado, y me respondieron que era una buena pregunta y que lo iban a revisar
    La razón por la que pregunté es que una sola consulta simple sobre un dispositivo, de las que acababan de mostrar, había quemado 250 mil tokens
    En ese momento se escuchó a uno de los ejecutivos del otro lado decir en voz alta: “¿Por qué le estamos mostrando esto al cliente?” y nos reímos bastante
    La lección aquí es que el costo de agregar IA a cualquier cosa no se está calculando bien, y menos aún se refleja el costo real de operar IA
    Todo lo que traiga IA, quieras o no, va a ser más caro

    • AIshittification

  • Tokenomics ya es una palabra que describe la economía de las criptomonedas; aunque los tokens usados en IA sean de otro tipo, no entiendo por qué querrían redefinirla

    • Tokenomics también era una palabra usada desde hace mucho entre aficionados al cannabis
    • Es la nueva moda
      Olvida las modas anteriores; esta también va a envejecer pronto, así que más vale subirse antes de que sea tarde
    • cryptocurrency economics = cryptonomics
    • “Crypto” también existía desde antes de que las criptomonedas se apropiaran del término
      “Web 3.0” también existía antes de que la gente cripto convirtiera Web3 en algo centrado en criptomonedas
      Así que no veo cuál sea el problema
      Los términos se reutilizan todo el tiempo en contextos distintos
      Además, la mayoría ya se salió de cripto, así que tampoco parece muy probable que haya mucha confusión