Un juego divertido. Eres CTO. Le has dado a tus ingenieros una tarjeta de crédito sin extracto, y ahora la compañía de la tarjeta quiere hablar contigo. El CTO de Uber le puso un número a esa conversación el mes pasado: el presupuesto entero de codificación con IA del año, agotado en abril. Lo interesante no era el tamaño de la factura. Era la segunda frase — «vuelvo al punto de partida porque el presupuesto que pensaba que iba a necesitar ya se ha esfumado». Que, traducido del lenguaje de ejecutivo educado, significa: pagamos la factura, sabemos exactamente lo que costó, no podemos decirte qué compró, y nos gustaría dejar de hacer eso.

Mira, la forma moderna de comprar software consiste en darles a los ingenieros una cosa que factura por token, decirles que la usen con prudencia y luego esperar. The Information informó el mes pasado que el CTO de Uber, Praveen Neppalli Naga, esperó y descubrió que su presupuesto de codificación con IA para todo 2026 ya se había agotado en abril, lo cual, en términos de plazos, es ambicioso. El uso de Claude Code en la empresa casi se duplicó en un trimestre; en marzo, el 84 % de los ingenieros de Uber estaban clasificados como usuarios de codificación agéntica, y bien por ellos. El gasto por ingeniero oscilaba entre unos $500 y $2,000 al mes, y el propio CTO se gastó $1,200 en una demo personal de dos horas — que es aproximadamente la tarifa por hora de un asociado junior de un bufete de abogados de Manhattan, que como mínimo entregaría un parte de horas. La línea total de I+D de Uber fue de $3,400 millones en 2025, así que no es que no tuvieran margen. Es que el modelo salió a buscar más margen del que tenían, encontró algo y lo facturó.

El post que esperarías de una empresa de seguridad y aislamiento a estas alturas es «usa un sandbox». Este no es ese post. Ese ya lo escribimos, porque por supuesto. Este es la otra mitad del mismo problema, la parte en la que llega la factura, puedes leerla y no puedes responder a la única pregunta que cualquiera quiere hacer, que es: muy bien, pero ¿para qué?

La factura está bien. La factura es el problema.

El precio por puesto era muy fácil de entender, y deberías apreciar la era del precio por puesto ahora que se ha ido. Comprabas 200 puestos de GitHub Copilot a $19 cada uno, te llegaba una partida de $3,800 al mes, y cuando alguien preguntaba «¿qué obtuvimos por eso?», la respuesta era un encogimiento de hombros con la forma del sector — «autocompletados, probablemente» — y todos volvían a sus reuniones. Lo bueno de un encogimiento de hombros es que escala. Un encogimiento de $3,800 está bien. Un encogimiento de $1.8 millones empieza a llamar la atención de la parte del edificio que tiene un deber fiduciario.

El tooling agéntico facturado por tokens tiene otra forma, y hay que pensarlo con cara. Dos ingenieros del mismo equipo, trabajando en el mismo tipo de feature, pueden diferir en gasto por un factor de cuarenta. (Cuarenta.) Uno abre una sesión nueva, pide una cosa, obtiene la cosa, cierra la sesión — $50, listo, se va a casa a hacer pasta. El otro deja que una manada paralela de agentes martillee un refactor durante seis horas, reintenta cuando el build se rompe, reintenta otra vez porque un modelo distinto pensó que el primer reintento estaba mal, reintenta una tercera vez porque a estas alturas ya es personal. Ambos ingenieros entregaron código. Uno entregó con $50 de tiempo de modelo. El otro entregó con $2,000. La factura no dice cuál es cuál. El IDE no dice cuál es cuál. Finanzas recibe un único número agregado, ingeniería recibe un hilo de Slack diciendo "Claude was *amazing* today", y ninguna de las dos cosas, con todo el respeto, es una medición.

Lo difícil no es el precio. Es que nada del gasto está asociado a algo que puedas auditar un trimestre después. Y entonces aterriza un PR. El PR tiene un diff. El diff tiene commits. Los commits tienen autores. El autor es un humano. El humano usó un agente en algún momento — quizá. ¿Qué agente? ¿Qué sesión? ¿Qué prompt? ¿Durante cuánto tiempo? ¿Haciendo qué? El rastro se enfría por algún sitio cerca del scrollback de la terminal, que ya está cerrado, porque nadie scrollea hacia atrás. Hay un nombre para esto en finanzas, y es «mermas», aunque en software aún no nos hemos molestado en ponerle nombre.

La caja del medio es todo lo que compraste. También es lo único que no puedes ver.

Lo que parece mayo de 2026 en la mayoría de las organizaciones de ingeniería: los dólares salen de la empresa por una sola tubería gorda, el trabajo sale por el otro lado por muchas tuberías finas, y la parte del medio — la parte por la que realmente pagaste — es niebla. El CFO ve la factura. El manager de ingeniería ve los PRs. Lo que conecta a los dos es una ventana de terminal cerrada y una vibra.

En cualquier caso, la forma de este problema es más vieja que la codificación agéntica, y si llevas en este sector el tiempo suficiente como para estar cansado, la reconocerás al instante. El gasto en la nube tuvo el mismo arco. Cinco años de «la factura de AWS es enorme y nadie sabe por qué», luego una generación de herramientas FinOps empezó a asociar dólares a equipos, a servicios y a peticiones individuales, y ahora la factura de AWS es enorme y la gente sabe por qué, lo cual, por modesto que suene, es todo el juego. La solución no fue usar menos AWS. Fue hacer el gasto legible.

La codificación agéntica está actualmente en la nube pre-FinOps. El gasto es real, las herramientas son buenas, la productividad está genuinamente ahí — nada de eso está en disputa. Lo que falta es el tejido conectivo entre «este ingeniero, en este repo, en esta sesión» y «estos tokens, estos comandos, estos archivos, este PR». Hasta que esa frase exista, cada dólar de la factura se paga por fe, y la conversación con tu CFO es una de esas conversaciones.

Lo que «visibilidad» tiene que significar, más allá del dashboard con el número grande.

Todo el mundo dice «observabilidad» y todo el mundo asiente, y casi nadie entiende lo mismo por ello. Los proveedores de agentes de codificación te enseñarán encantados un dashboard. El dashboard tiene medidores de tokens. Tiene porcentajes de adopción. Tiene un gráfico listo para diapositiva que sube hacia la derecha, que es la forma de gráfico de todo el software en 2026. Nada de esto es una respuesta. «Tus desarrolladores consumieron 2.300 millones de tokens de entrada esta semana» no es una respuesta; es una reformulación de la factura en una fuente más grande.

Lo que un CTO necesita realmente, para defender un presupuesto o ampliarlo, viene en cuatro partes.

Adopción que puedes enseñar en una diapositiva

Cuántos de tus ingenieros usaron de verdad un agente de codificación esta semana. Durante cuánto tiempo. En qué proyectos, en qué repos. No licencias por puesto emitidas, no titulares de claves API, no «gente inscrita en el programa» — sesiones iniciadas, por un humano, sobre algo a lo que la organización pueda poner nombre.

Cada archivo que el agente tocó

Por sesión, por repo, por ingeniero — el conjunto exacto de archivos que un agente de IA creó, modificó o borró, con diffs, asociado al ingeniero que lanzó la sesión y al modelo que usó. La unidad de trabajo es «una mutación de archivo», no «un token». Los tokens son cómo te factura el proveedor. Los archivos son lo que tienes que entregar.

Cada comando, cada origen

Cada comando shell que el agente ejecutó dentro de la sesión, cada archivo que leyó, cada herramienta que invocó, cada API que tocó. Capturado en vivo, retenido de forma centralizada, consultable por equipo, por repo, por modelo. «¿Qué instaló ayer el agente?» se convierte en una consulta, en vez de una excavación arqueológica con linterna y un SRE junior.

El diálogo completo, archivado

Prompts, respuestas del modelo, llamadas a herramientas — la transcripción entera. En algún sitio estable. Revisable por seguridad, muestreable por la dirección de ingeniería, exportable al mismo archivo de retención que ya alimentas para el correo y el chat. La sesión es ahora un registro, no el recuerdo de algo que alguien tecleó una vez.

Fíjate en lo que no está en esa lista. El recuento de tokens no está en la lista. Está en la factura. La gracia de la lista es poner la factura al lado de aquello que compró, para que un equipo de finanzas pueda hacer la división, un equipo de ingeniería pueda dejar de discutir por vibras, y todo el mundo pueda dedicar la reunión a la pregunta de verdad.

Cómo Bromure monta la fontanería.

La función de codificación agéntica en Bromure fue, para ser justos, originalmente construida para la mitad de seguridad de esta conversación. Cada agente de codificación se ejecuta dentro de una VM Linux desechable en tu Mac. La VM solo tiene acceso a las carpetas del proyecto que has montado; no tiene claves SSH, ni credenciales de AWS, ni token de GitHub en disco. Un broker de credenciales en el host intercambia tokens-stub por reales pero solo en el cable, solo para endpoints en lista blanca. Esa es la historia que ya contamos, en la que un paquete npm envenenado intenta largarse con tus secretos y se choca con una pared.

La historia de observabilidad usa la misma fontanería, por una razón distinta. El hipervisor está entre el agente y todo lo que toca. El agente no abre un archivo; lo abre la VM. El agente no ejecuta un comando shell; lo ejecuta la VM. El agente no hace una llamada a una API; el proxy del host lo hace. Cada una de esas operaciones es — tiene que serlo, porque la mitad de seguridad del trabajo lo exige — un evento nombrado, con timestamp, ID de sesión, identidad del ingeniero y un payload. Bromure ya graba todo esto localmente. Se llama Session Tracer y se entrega hoy con Agentic Coding.

La pieza que cierra el bucle para los CTO (y los CFO, y los CISO, y la persona de compras a quien le gustaría saber qué compró) es la parte de la nube. Cuando el cliente de Bromure en el Mac de un desarrollador está enrolado en tu organización, esas trazas locales dejan de ser una ayuda de depuración local y empiezan a ser un registro estructurado transmitido en streaming a tu servidor enterprise de Bromure. Por ingeniero. Por sesión. Por proyecto. Por modelo. Filtrable, exportable, retenible. La copy del producto en la página de codificación agéntica lo llama «monitorización de uso de IA» y actualmente lo etiqueta como próximamente, lo cual, para que conste, este post es en parte la razón.

La misma foto una vez que has puesto un hipervisor en el medio. Cada sesión de agente corre dentro de una VM por desarrollador. El hipervisor y el proxy de credenciales ya ven cada comando shell, cada archivo, cada petición saliente — tienen que verlo, para hacer la mitad de seguridad de su trabajo — y el servidor enterprise es donde esos eventos aterrizan en una tabla por la que por fin puedes dividir la factura. Claude Code sigue siendo Claude Code, Cursor sigue siendo Cursor, Codex sigue siendo Codex; los agentes no cambian. La caja del medio, la que antes era niebla, ahora es una base de datos.

La razón por la que los eventos son fiables no es un sidecar dentro del agente, ni un wrapper alrededor de la API del modelo, dos cosas que en principio el agente podría sortear si le diera la gana. Los eventos son fiables porque el agente se ejecuta dentro de una VM cuyo hipervisor tiene que conocer cada comando y cada archivo independientemente de que alguien se lo pida. La observabilidad es, en cierto sentido, gratis. Ya la pagaste. La factura decía «aislamiento». Lo que también obtuviste es un log. Y por eso obtienes el mismo registro tanto si el ingeniero usó Claude Code, o Cursor en modo CLI, o Codex, o Aider, o algún agente interno del que jamás hemos oído hablar — porque la unidad de grabación es «cosa que hizo la VM», no «cosa que el proveedor decidió exponer este trimestre».

A qué suena la conversación dentro de un trimestre, en su lugar.

El número de Uber es útil para pensar, porque nada de él es un fracaso. 84 % de adopción. Código entregado. Un CTO que se arremangó de verdad y usó la cosa, lo cual, por cierto, más CTO deberían hacer, incluso a $1,200 la demo. Lo que se rompió fue la conversación un trimestre después. «¿Doblamos la apuesta? ¿Retrocedemos? ¿Escalonamos los puestos? ¿Empujamos a la gente hacia modelos más baratos para ciertas clases de trabajo?» Ninguna de esas decisiones se puede tomar a partir de una factura de tokens agregada. Todas ellas se pueden tomar perfectamente desde una tabla por ingeniero, por sesión, por repo. Las decisiones no se volvieron más difíciles. La tabla desapareció.

Un puñado de preguntas que se vuelven respondibles, más o menos en el orden en el que las oímos de gente que intenta defender una partida:

¿Qué ingenieros están obteniendo un valor desmesurado, y qué están haciendo distinto? Mira a los ingenieros cuya proporción de gasto-a-archivos-cambiados cae en la esquina buena de la distribución. Lee unas cuantas de sus trazas de sesión. Parte de lo que hacen bien es estilo, parte es técnica, parte es simplemente qué modelo usan. Nada de eso es visible sin el registro. («¿Cómo entrega Alice tanto código por tan poco dinero?» es el tipo de pregunta que produce un lunch-and-learn interno útil, pero solo si las sesiones de Alice no son una terminal cerrada en algún sitio.)
¿Está el gasto concentrado en un equipo, un repo, un tipo de trabajo? Si el 60 % de tu factura de IA viene de un único servicio legacy y el agente está mayoritariamente martilleando en tests flaky, eso es un hallazgo. También no es un hallazgo sobre IA.
¿Qué proyectos son productivos con qué modelo? «Claude es mejor que Cursor» es un tuit. «Claude entregó 3x más cambios de archivo por dólar que Cursor en nuestro repo de front-end el mes pasado, y al revés en nuestro servicio Go» es una conversación de compras.
¿Qué instaló el agente, y dónde? Esa es la pregunta del equipo de seguridad, y es la misma consulta contra la misma tabla. Cada npm install, cada pip install, cada apt-get que ejecutó el agente, por sesión, por repo, filtrable por nombre de paquete. El día que aparezca un paquete envenenado en un registro — lo cual, gesto vago hacia la mayoría de las semanas del calendario — la pregunta «¿alguno de nuestros agentes tocó esto?» es una cláusula WHERE en vez de un simulacro de incendio.

Algo de lo que hay que tener cuidado: ninguna de estas preguntas es respondible desde dentro del dashboard del proveedor del modelo, ni puede serlo. El proveedor ve tokens. El proveedor ve, a veces, prompts y completions durante el tiempo de una petición. El proveedor no ve tu repo, tus mutaciones de archivo, tus comandos shell, ni qué ingeniero de tu organización tecleó qué cosa. El proveedor no puede. El proveedor está al lado equivocado del cable. La capa de visibilidad tiene que vivir en tu lado — en la máquina del desarrollador, en la VM, en tu servidor enterprise — porque ahí es donde el trabajo está ocurriendo de verdad. Los medidores de tokens son una postal desde el campo.

Disclaimers, cómo no.

Unos cuantos honestos, porque la peor versión de un post como este es la que promete un informe financiero del fin de la historia y luego entrega un dashboard.

El registro de Bromure te dice lo que el agente hizo. No te dice si lo que el agente hizo fue bueno. Una sesión que escribió 40 archivos y entregó un PR puede haber entregado igualmente 40 archivos malos. El registro hace que sea más fácil encontrarlos, más fácil hablar de ellos y más fácil revertirlos. No los revisa por sí solo. La revisión del diff sigue siendo cosa tuya, y del humano en el bucle, y del muy cansado ingeniero senior a las 17:00.

El registro de Bromure cubre lo que el agente hace dentro de la VM. No cubre lo que el ingeniero hace en su cabeza antes de abrir el agente. La conversación de cinco minutos que un ingeniero tiene con Claude en su IDE antes de que arranque la sesión propiamente dicha no está en esta cinta. Eso es una laguna real. No es una que finjamos rellenar, porque no podemos rellenarla sin un producto mucho más raro.

El registro de Bromure está en tu lado del cable, que es justo el quid — pero también significa que tu lado del cable es donde tienen que vivir la política de retención, los controles de acceso y los contratos de tratamiento de datos. Los prompts incluyen código. El código incluye secretos que tus desarrolladores no deberían haber pegado pero absolutamente pegaron. El registro es tan sensible como el trabajo, y deberías tratarlo así. El almacenamiento es tuyo; la responsabilidad es tuya. («Hay un nombre para esto en finanzas, y es "mermas", salvo que ahora las mermas son una tabla SQL y puedes auditarla.»)

Y por último, esto es una pieza de una historia más grande. La otra pieza es la que ya cubrimos — que ejecutar agentes de codificación dentro de una VM con un broker de credenciales es cómo evitas que el próximo paquete npm envenenado se largue con tus claves SSH. La historia de seguridad y la historia de observabilidad son la misma fontanería. Solo presentan informes de gastos en días distintos.

Paga la factura. Pero págala sabiendo qué compró.

La frase de Uber — vuelvo al punto de partida porque el presupuesto que pensaba que iba a necesitar ya se ha esfumado — va a ser la frase de muchos CTO este año. Siempre iba a serlo. El precio por token sobre herramientas cuyo apetito está acotado solo por lo ambicioso que se sienta el modelo a las 14:00 va a producir esa frase en cada empresa que las adopte sin instrumentarlas. Los agentes no son el problema. La fontanería sí.

Bromure Agentic Coding, a regañadientes, es a lo que se parece la fontanería cuando hace su trabajo. Cada agente corre en su propia VM, cada sesión es un registro estructurado, cada registro se transmite en streaming a un sitio que tu equipo de finanzas y tu CISO pueden consultar, y los agentes que ya adoras siguen siendo exactamente lo que eran. Seguirás pagando la factura. Solo que, por fin, sabrás qué compró — que, la última vez que alguien lo comprobó, era el mínimo que una compañía de tarjeta de crédito pide a sus clientes.