El costo del software no termina cuando se genera el código

En mi trabajo actual todavía no tenemos un presupuesto semanal de tokens. No hay una cantidad que cada equipo deba administrar ni un tablero que convierta cada conversación con un agente en una decisión financiera.

Sin embargo, ya hemos tenido talleres internos sobre cómo utilizar modelos más sencillos, optimizar las habilidades que les damos a los agentes y declarar reglas estrictas sobre lo que no deben hacer. El objetivo inmediato es reducir operaciones innecesarias. La señal de fondo es más interesante: el consumo está dejando de ser un detalle del proveedor y empieza a convertirse en una decisión de arquitectura.

También puedo ver el siguiente paso. Si los agentes van a participar en más partes del desarrollo, no será suficiente pedirles que contesten más barato. Tendremos que permitir que ejecuten más trabajo sin intervención humana. De otro modo, el costo de supervisar cada paso crecerá junto con la automatización que pretendía reducirlo.

Ahí aparece una tensión. Dar autonomía puede ahorrar atención, pero también permite que una decisión incorrecta consuma más herramientas, modifique más estado o avance más lejos antes de ser detectada.

Por eso ya no creo que el costo de un agente pueda resumirse en el precio de sus tokens.

El costo real de un agente es el costo total de permitirle actuar.

La factura visible es sólo una parte

Cuando comparamos modelos solemos empezar por una cifra cómoda: cuánto cuesta un millón de tokens. Esa cifra sirve para comprar inferencia. No dice cuánto cuesta terminar correctamente un trabajo.

Una instrucción como “actualiza esta dependencia” puede activar planeación, búsqueda en el repositorio, lectura de documentación, llamadas a herramientas, cambios de archivos, pruebas, correcciones y nuevos intentos. Stripe explica esta diferencia desde la perspectiva de medición: una sola acción de usuario puede expandirse en decenas o cientos de llamadas, herramientas y pasos de recuperación de información. El costo de la misma instrucción puede variar entre ejecuciones.

Eso vuelve incompleta la unidad que solemos observar. Un token mide consumo del modelo. No mide si el resultado fue aceptado, si una persona tuvo que reconstruirlo, si una prueba detectó una regresión o si fue necesario revertir una acción.

Gartner publicó en junio de 2026 un pronóstico que recomienda modelar el retorno de la IA con costos cuatro veces mayores a los actuales, en parte por flujos de agentes más complejos y por el fin de subsidios comerciales. No tomo ese multiplicador como una verdad aplicable a todos los equipos. Es un pronóstico, no un resultado observado. Lo útil es la advertencia: una iniciativa rentable bajo el precio actual de una respuesta puede dejar de serlo cuando medimos el flujo completo.

Yo llamaría a esa unidad más amplia costo total de delegación:

No propongo esta tabla como una fórmula financiera estándar. La propongo como una forma de evitar una ilusión: que reducir el costo de la primera fila reduce automáticamente el costo de la tarea.

El modelo más barato puede producir el resultado más caro

Usar modelos más sencillos es una buena herramienta. Una clasificación estable, una transformación acotada o una búsqueda con criterios explícitos no siempre necesita el modelo más capaz. Enviar todo al modelo más costoso también es una forma de desperdicio.

El sesgo aparece cuando confundimos precio por llamada con eficiencia del sistema.

Un modelo barato que necesita cinco intentos, cambia archivos fuera de alcance y deja una explicación que alguien debe reconstruir puede costar más que un modelo caro que llega a un resultado verificable en un intento. La relación también puede invertirse: un modelo avanzado aplicado a una tarea determinista puede consumir mucho más sin mejorar la decisión.

No existe una jerarquía universal. La pregunta es qué combinación produce el resultado aceptado con el menor costo total y un nivel de riesgo tolerable.

Un benchmark reciente de Microsoft Research ayuda a explicar por qué conviene medir el final del flujo. DELEGATE-52 simuló tareas largas de edición en 52 dominios con 19 modelos. Al terminar esos recorridos, incluso los modelos de frontera habían alterado incorrectamente, en promedio, 25% del contenido evaluado.

No es una tasa de fallas de producción ni prueba que una cuarta parte de todo trabajo delegado será incorrecto. Es una prueba de estrés diseñada para recorridos largos. Su valor está en mostrar un mecanismo: errores pequeños pueden acumularse silenciosamente cuando una tarea contiene muchos pasos y archivos. Si sólo medimos la respuesta final o el precio de cada llamada, el costo de esa degradación permanece oculto hasta la validación o la reparación.

Un prompt no es un plano de control

Las reglas estrictas dentro de una habilidad son útiles. Pueden evitar búsquedas irrelevantes, elegir primero herramientas deterministas y recordarle al agente que no modifique archivos fuera del alcance. Pero una regla escrita para un modelo sigue siendo una instrucción probabilística.

No debería tener la misma responsabilidad que un límite ejecutado por el sistema.

OWASP recomienda no usar el prompt del sistema para imponer controles críticos. La separación de privilegios y los límites de autorización deben existir fuera del modelo de forma determinista y auditable. Esta distinción cambia cómo entiendo la optimización:

• Una habilidad o prompt guía el comportamiento.
• Un permiso de herramienta limita la capacidad.
• Un validador aporta una señal de corrección.
• Un presupuesto limita tiempo, llamadas, dinero y reintentos.
• Un checkpoint o rollback crea una ruta de recuperación.
• Una regla de escalación devuelve ambigüedad y responsabilidad a una persona.

Decirle a un agente “no uses más de diez llamadas” no equivale a detener la número once. Pedirle “no accedas a secretos” no equivale a mantenerlos fuera de su entorno. Una instrucción puede mejorar la conducta; una frontera reduce lo que un error puede alcanzar.

Los productos actuales ofrecen ejemplos concretos de esa arquitectura. El sandbox de Codex mantiene la red deshabilitada por defecto y restringe las escrituras al espacio de trabajo. Anthropic describe un patrón parecido: después de encontrar fatiga de aprobación, introdujo un sandbox de sistema operativo que redujo 84% las solicitudes de permiso mientras conservaba límites sobre archivos y red.

Son reportes de proveedores sobre sus propios productos, no comparaciones independientes. Aun así, ilustran una decisión sólida: automatizar dentro de una frontera confiable puede ser más seguro y menos costoso que pedirle a una persona que confirme cada paso.

La autonomía debe ganarse

Si cada acción necesita aprobación, el humano sigue dentro de cada iteración y la capacidad del sistema queda limitada por su atención. Si eliminamos todas las aprobaciones de una vez, convertimos el ahorro de atención en una expansión del riesgo.

La alternativa que me convence es tratar la autonomía como algo que un flujo de trabajo debe ganar.

1. 01AsistenciaEl agente lee, analiza y propone. No cambia estado.
2. 02SandboxEjecuta dentro de un entorno aislado y desechable.
3. 03ReversibleModifica estado sólo cuando la recuperación está probada.
4. 04AcotadaCompleta el flujo dentro de presupuestos y permisos explícitos.
5. 05Por excepciónUna persona interviene cuando una señal rebasa el contrato.

Esta escalera no mide qué tan inteligente parece el modelo. Mide qué tan preparado está el sistema para absorber sus errores.

Para avanzar un nivel yo pediría resultados aceptables y repetibles, errores observables, recuperación probada, costo predecible dentro de un rango, permisos mínimos, condiciones de salida y una persona responsable del flujo. La promoción pertenece al caso de uso, no al modelo completo. El mismo agente podría operar por excepción al actualizar documentación y permanecer en asistencia al modificar autorizaciones o mover dinero.

NIST plantea que las configuraciones humano-IA pueden ir de completamente manuales a completamente autónomas y que la necesidad de supervisión depende del contexto. Me parece una corrección útil para ambos extremos: ni toda tarea necesita una persona en cada paso ni toda capacidad técnica merece autonomía.

La pregunta decisiva deja de ser cuánto trabajo puede hacer el agente solo. Pasa a ser:

¿Cuánto error puede contener y revertir el sistema antes de necesitar a una persona?

Un agente necesita un contrato de ejecución

Un prompt describe qué intentar. Un contrato de ejecución describe bajo qué condiciones vale la pena seguir intentándolo.

Pienso en un ejemplo ficticio: un agente encargado de actualizar dependencias y abrir un pull request. En lugar de darle acceso general y esperar un buen resultado, definiría antes:

• Resultado: actualizar sólo versiones menores o parches dentro de un paquete específico y explicar los cambios del archivo de bloqueo.
• Presupuesto: una ventana máxima de ejecución, un número acotado de herramientas y un solo reintento después de una falla conocida.
• Permisos: escribir únicamente en una rama aislada; acceder sólo al registro y documentación permitidos; no desplegar ni leer credenciales.
• Validación: revisar el diff, ejecutar las pruebas relevantes y registrar cualquier cambio en scripts de instalación.
• Salida: detenerse ante una versión mayor, un archivo inesperado, una nueva fuente de red o una prueba que sigue fallando después del intento permitido.
• Recuperación: descartar la rama sin afectar el espacio de trabajo principal.
• Escalación y dueño: presentar la evidencia y la incertidumbre; una persona decide si el pull request merece ser aceptado.

Los números concretos dependerían del repositorio y de cuánto vale el resultado. Lo importante es que existan antes de la ejecución. Stripe llega a una conclusión parecida desde el control de consumo: los límites, reservas y circuit breakers deben actuar mientras se genera el uso, no cuando la factura ya lo registró.

El contrato convierte una intención amplia en un sistema que puede detenerse. También hace visible una decisión que normalmente queda escondida: cuánto estamos dispuestos a gastar para demostrar que un resultado merece confianza.

Medir resultados aceptados, no actividad

Una gráfica de tokens puede ser útil para detectar una anomalía. No puede decir por sí sola si un agente está creando valor.

Yo empezaría por relacionar el consumo con el desenlace:

• costo total por resultado aceptado;
• costo de validación por resultado aceptado;
• reintentos que no cambiaron la conclusión;
• tiempo humano dedicado a excepciones y reparación;
• ejecuciones detenidas por límites correctos;
• trabajos cuyo costo de demostración superó el valor de completarlos.

No todas estas señales necesitan convertirse en dinero. El tiempo de una persona, el radio de impacto y la reversibilidad pueden conservar sus propias unidades. Forzarlas demasiado pronto a una cifra única produciría otra precisión falsa.

Lo importante es conservar el vínculo entre consumo y resultado. Si un modelo más sencillo reduce la factura y mantiene aceptación, validación y reparación dentro de los mismos límites, la optimización funcionó. Si reduce tokens pero duplica reintentos o atención humana, sólo trasladó el costo.

La misma lógica sirve para decidir dónde automatizar más. Un flujo estable, reversible y observable puede liberar a la persona de confirmaciones rutinarias. Uno ambiguo, irreversible o difícil de evaluar debería gastar más en evidencia y escalar antes.

La persona sale del loop después de diseñarlo

Creo que permitir más trabajo sin intervención humana será necesario. No porque la autonomía sea siempre superior, sino porque supervisar manualmente cada operación también tiene un costo y puede degradarse en una ceremonia de aprobaciones.

Pero sacar a la persona del ciclo de ejecución no significa eliminar sus decisiones. Significa moverlas hacia antes:

• decidir qué resultado vale la pena perseguir;
• delimitar qué puede tocar el agente;
• establecer cuánto puede gastar e insistir;
• definir qué evidencia cuenta;
• preparar cómo se revierte;
• y señalar cuándo debe detenerse y pedir ayuda.

Después, la persona vuelve cuando el sistema encuentra una excepción real, no en cada paso predecible.

Ésa es la diferencia entre autonomía y abandono. La autonomía contiene decisiones humanas en la arquitectura. El abandono espera que una instrucción bien escrita sustituya presupuesto, permisos, validación y recuperación.

El software no se vuelve barato cuando cuesta menos producirlo. Se vuelve sostenible cuando sabemos cuánto cuesta confiarle una decisión.