Ingeniería de contención: ¿Por qué los costos de los agentes de IA están en aumento?

Durante dos años, los titulares decían lo mismo: los ingenieros cuestan mucho, los agentes de IA cuestan poco, y un trabajador digital que nunca duerme ni se queja por una fracción del salario haría inevitable su reemplazo. Recientemente, en las reuniones de planificación de algunas empresas muy avanzadas tecnológicamente, las hojas de cálculo han comenzado a contradecir esa narrativa.

Dos empresas, dos llamados a la reflexión

Microsoft puso a disposición de sus equipos de ingeniería internos Claude Code a finales de 2025. Estaba profundamente integrado en los flujos de trabajo diarios y a los desarrolladores les gustó. Para mediados de 2026, la empresa comenzó a retirar esas licencias y a orientar a los empleados hacia opciones internas más económicas como GitHub Copilot CLI.

El caso de Uber fue aún más grave. En abril de 2026, su director de tecnología admitió que todo el presupuesto de 2026 destinado a herramientas de programación con IA se había agotado en solo cuatro meses. La adopción había alcanzado el 84 % de los ingenieros, el uso se había convertido en una competencia a nivel de toda la empresa, y un líder técnico gastó 1,200 dólares en tokens durante una sola demostración de dos horas.

La IA nunca dejó de funcionar. Simplemente se volvió excesivamente costosa. Para quienes desarrollan sistemas agentes, esta situación refleja un límite fácil de alcanzar: la factura de procesamiento de un trabajador digital autónomo puede superar el salario de la persona a quien se supone que debe reemplazar.

La solución es una disciplina que pronto será obligatoria y se denomina Ingeniería de Contención.

Por qué los agentes cuestan mucho más que las chatbots

Un prompt de chat y un agente autónomo son cosas diferentes. Cuando haces una pregunta a un modelo de lenguaje estándar, solo se registra un paso: tú preguntas, él responde y la transacción termina.

Un agente, en cambio, tiene como objetivo una tarea abierta. Si se le pide que corrija un error, lee archivos, elabora un plan, escribe las modificaciones necesarias, ejecuta pruebas y evalúa sus propios resultados. Si una prueba falla, se reinicia el ciclo, por lo que el agente vuelve a pensar, reescribe y vuelve a probar. Cada paso se cobra como servicio.

El trabajo real de desarrollo de software convierte esto en una exposición financiera significativa. SWE-bench es una prueba estándar del sector compuesta por errores presentes en código en producción real, y los mejores agentes disponibles actualmente logran resolver menos de la mitad de sus tareas. Por lo tanto, en más de la mitad de los casos, el agente intenta, falla, vuelve a intentarlo, falla nuevamente y finalmente se rinde.

Imagínese a un plomero que cobra la tarifa horaria completa cada vez que deja caer su llave inglesa, factura por cada caminata hasta la furgoneta y se va con la tubería aún goteando. A escala empresarial, una tarea del agente que falla es como ese plomero: se paga por completo por el error cometido.

El consumo de tokens no se duplica simplemente frente a una ventana de chat. En promedio, un agente utiliza de 5 a 30 veces más, y un agente descontrolado en un escenario de depuración complejo puede llegar a consumir más de 1,000 veces el costo de una solicitud normal.

Dos curvas de costos que divergen

La economía humana y la economía de la IA siguen curvas diferentes. A medida que un desarrollador junior mejora, su productividad aumenta mientras su salario se mantiene más o menos estable durante ese período. Simplemente se vuelven más rápidos y eficientes.

Un agente que se enfrenta a un problema complejo necesita muchos más pasos de razonamiento, intentos repetidos y uso del espacio de contexto, por lo que el costo en tokens aumenta drásticamente. Cuanto más difícil sea el problema, mayor será el costo.

Las mejoras en el hardware no resuelven la situación, ya que la demanda de software supera los ahorros obtenidos. Los chips Maia 200 de Microsoft, que ahora operan en sus centros de datos, ofrecen claramente más tokens por dólar que el hardware anterior. Sin embargo, las cargas de trabajo de los agentes absorben todos esos ahorros de inmediato. Los tokens más económicos simplemente significan que los agentes solicitan una cantidad exponencialmente mayor de ellos.

Por lo tanto, la idea de lanzar un agente en todo un código base empresarial y dejarlo actuar por sí solo ya no es viable, ya que las matemáticas no lo permiten. Aun así, los agentes no son inútiles. La arquitectura que los rodea debe cambiar, y rápidamente.

Ingeniería de contención

Para quienes desarrollan aplicaciones de IA, la ingeniería de prompts ya no es la única tarea. La tarea real es la ingeniería de contención: límites estrictos, restricciones de estado y mecanismos de seguridad financiera alrededor de los modelos, para que la máquina demuestre su valor antes de generar costos elevados.

La preocupación es concreta. Imagine un sistema de gestión de inventarios en Next.js 16, TypeScript y Azure OpenAI. Allí, la latencia y las alucinaciones apenas importan en comparación con el miedo a que un agente autónomo quede atrapado en un bucle de razonamiento y agote los créditos en la nube durante la noche. Una preocupación similar existe en tareas de procesamiento genómico en la plataforma Modal, donde se evalúan miles de secuencias de referencia de ClinVar y se alcanza un tiempo de ejecución máximo exactamente después de dos horas. Eso era un cálculo normal por segundo. Un agente recursivo facturado por token en la misma situación habría generado una suma enorme.

Cuatro prácticas hacen que la contención sea viable.

1. Dirigir las solicitudes según su dificultad

El error más común es intentar realizar cada llamada a la API con un modelo de vanguardia como GPT-5 o Claude 4.5 Opus. Eso es un enfoque de fuerza bruta que agota rápidamente los recursos. En su lugar, debería haber una capa de enrutamiento en la parte más inicial de la estructura. Un router es un modelo ligero y extremadamente económico que examina cada tarea recibida y decide qué LLM está realmente capacitado para manejarla.

[ Incoming User Request ]
           |
      [ Router ]
      /        \
[ Simple ]  [ Complex ]
      |          |
[ Llama 3 ] [ Flagship LLM ]

La extracción simple de datos o el formateo básico se puede realizar con un modelo de código abierto de 8 mil millones de parámetros o con un mini-modelo ajustado. Las tareas que requieren lógica compleja deben realizarse con el modelo más potente y costoso. Ese único cambio puede reducir los gastos en API en hasta un 80% sin que disminuya perceptiblemente la calidad de la aplicación.

2. Nunca permita un bucle de intentos ilimitado

Un agente que puede escribir código, probarlo y volver a intentarlo en caso de fallo necesita un límite máximo de intentos definido de antemano. Sin embargo, un simple número entero no es suficiente, ya que el contexto aumenta con cada intento. El tercer intento cuesta notablemente más que el primero, puesto que la instrucción ahora incluye la información de los dos fallos anteriores.

Agregue un límite presupuestario. Antes de que el agente inicie el siguiente paso recursivo, una función de middleware calcula el costo en tokens de la solicitud recibida. Si la suma total acumulada durante la sesión supera un límite predefinido e estricto, el proceso se detiene de inmediato y se marca para que un desarrollador humano lo revise.

3. Recortar el contexto

Tras un intento fallido, un agente suele añadir el registro de errores en bruto a su solicitud anterior e intentarlo de nuevo. De ahí proviene la curva de costos exponencial. El recorte de contexto contrarresta esto. En lugar de pasar toda la detallada historia del fallo al modelo principal, el modelo más económico condensa el estado del fallo.

Se envía el enorme registro de errores al modelo económico con una instrucción como “Extrae la razón técnica exacta de este fallo en dos oraciones cortas”. Solo esas dos oraciones vuelven al agente principal para su siguiente intento. La ventana de contexto se recorta intencionadamente, de modo que el recuento de tokens crece de forma lineal y no exponencial.

4. Mantener a un humano como interruptor de emergencia

Durante mucho tiempo, contar con la intervención humana se consideró una medida de seguridad temporal. Ahora es un requisito financiero estricto. La función del desarrollador consiste en supervisar al agente y detectar de inmediato cuando este entra en un estado de fallo costoso: verificar los resultados, confirmar la dirección técnica y detener un proceso descontrolado antes de que agote el presupuesto del sprint.

Qué implica este cambio

Duolingo suavizó recientemente su postura pública respecto a la sustitución de trabajadores por inteligencia artificial. Junto con Microsoft y Uber, se enfrentó a un hecho básico: los seres humanos son los motores de pensamiento más económicos disponibles. La mente flexible de un desarrollador funciona con un sándwich y un buen descanso nocturno, y nunca cobra a la empresa miles de veces más solo para detenerse y pensar.

La burbuja de agentes infinitos y económicos estalló por culpa de una simple hoja de cálculo. Para los desarrolladores que acaban de entrar en la industria, eso es alentador, ya que los puestos de trabajo siguen estando seguros mientras las responsabilidades diarias cambian. El trabajo pasa de escribir cada línea a mano a diseñar y gestionar los sistemas que las generan.

El consejo práctico es breve: implemente routers estrictos en las capas de IA, aplique medidas de contención rigurosas a los agentes y trate el presupuesto de tokens con el mismo respeto que al heap de memoria. El futuro de la ingeniería de software pertenece a quienes pueden controlar la máquina, controlar sus costos y desconectarla cuando deja de funcionar correctamente.

Leer más

• Un agente de IA local con Ollama: herramientas especializadas, validación y límites estrictos en los pasos — Reconstrucción de un agente para el seguimiento de facturas con Ollama y Python: listas de herramientas permitidas, bucles con límite, salida en Pydantic, estado explícito, reglas de seguridad y un conjunto de pruebas para casos de fallo.
• Por qué los agentes de programación siguen teniendo dificultades con el código de empresas privadas — Real-SWE prueba ocho agentes de programación en bases de código privadas con licencia. El mejor resuelve el 38.8 por ciento de los casos, y las cinco categorías de fallo muestran dónde cometen errores los agentes.