Agentes de IA en producción: el espejismo del «ingeniero 100x» de Cloudflare

Cloudflare acaba de recortar el 20% de su plantilla alegando que la IA multiplicó la productividad «entre dos y cien veces». El discurso del «ingeniero 100x» —que confunde el efecto real de los agentes de IA— está a punto de provocar una ola de decisiones de plantilla mal planteadas desde su base.

Qué dijo realmente Cloudflare en el Q1 de 2026

La frase de la llamada con inversionistas que más ha circulado es la de Prince: la IA ha hecho que ciertos puestos produzcan «dos veces, diez veces e incluso cien veces» más que antes. TechCrunch la recogió. CNBC también. The Register hizo lo mismo. Todos dieron el planteamiento por válido y saltaron directamente al número de empleos eliminados.

El contexto completo es este: los 1,100 recortes de Cloudflare afectan a lo que Prince describió como puestos cuyo trabajo ahora asume la IA. La implicación es que las personas que antes lo realizaban eran el cuello de botella y que la IA lo eliminó. Los ingresos subieron un 34%. La plantilla bajó un 20%. El relato para inversionistas se escribe solo: la misma producción, menos personas y márgenes más amplios.

Lo que nadie preguntó en esas llamadas de resultados —y lo que ninguna cobertura puso en duda— es si la «productividad 100x» constituye siquiera una unidad de análisis coherente cuando un agente ejecuta un proceso de principio a fin. No es lo mismo un ingeniero humano que, con ayuda de la IA, es 100x más productivo que un proceso retirado por completo de la columna de trabajo humano. Son dos fenómenos distintos. Y la diferencia importa muchísimo cuando quien decide a quién conservar es el fundador.

Lo que estoy haciendo realmente esta semana

Estoy operando el sistema de publicación de este blog sobre Workers y Durable Objects. Son seis agentes: ManualIntake, Discovery, Editorial, Writer, Distribution y Maintenance. El mes pasado publicaron 24 artículos. Yo intervine directamente, quizá, en cuatro. La factura está a continuación.

Cuánto cuestan realmente 6 agentes de IA en producción con Workers

Esta es la factura real de Cloudflare de abril de 2026 para el sistema de publicación con seis agentes.

El cómputo de Workers costó $11.40. Las lecturas y escrituras de la base de datos D1 —la memoria de trabajo de los agentes, las colas de tareas, los borradores y los metadatos del contenido— sumaron $3.20. El almacenamiento de recursos multimedia y exportaciones de archivo en R2 costó $0.84. Vectorize, utilizado para la búsqueda semántica en todo el corpus de artículos, añadió $1.10. El Agents SDK y la capa de orquestación de Workflows completaron la cuenta con $2.60 por solicitudes y duración. Infraestructura total en Cloudflare: $19.14 durante el mes.

La inferencia se factura aparte, del lado del proveedor de modelos. En abril, los seis agentes usaron Claude Sonnet 4.5 o Haiku 3.5 según la complejidad de cada tarea, con un costo mensual de $214. Costo total del sistema de IA, sumando infraestructura e inferencia: $233.14.

El volumen de abril fue el siguiente: ManualIntake procesó 31 solicitudes de contenido. Discovery ejecutó 188 tareas de investigación y búsqueda de fuentes. Editorial produjo 47 briefs y ciclos de revisión. Writer generó 24 borradores que llegaron a publicarse. Distribution gestionó 96 tareas de sindicación y redes sociales. Maintenance realizó 240 comprobaciones programadas de estado, auditorías de enlaces y actualizaciones de índices. En total: 626 tareas de agentes en un mes, por unos $0.37 cada una con todos los costos incluidos.

El sistema funciona en una instancia Hetzner CX22 de €4.42 al mes para una pequeña capa de coordinación. No hay nada más.

¿Cuánto costaría contratar a una persona para completar 626 tareas mensuales con la calidad y el ritmo de estos agentes? En un mercado occidental, el costo total de un perfil intermedio de operaciones de contenido oscila entre $6,500 y $9,000 al mes. Los agentes realizan una parte significativa de ese trabajo por $233. Esa cuenta es real y no tiene sentido fingir lo contrario.

Pero hay un dato decisivo: todavía dedico unas 12 horas por semana a este sistema. No a ejecutar las tareas que hacen los agentes, sino a otro tipo de trabajo. Eso es precisamente lo que el marco del «100x» no alcanza a ver.

Por qué falla el concepto del ingeniero 100x

La idea del ingeniero 100x presupone que se parte de un ingeniero y que la IA lo vuelve 100 veces más productivo. La unidad de referencia sigue siendo el ingeniero; simplemente harían falta menos personas para obtener el mismo volumen de resultados.

Eso no es lo que ocurre en una implementación real de agentes. Lo que sucede es que un proceso completo sale de la columna de trabajo humano. El agente Discovery no vuelve 100x más productivo a un investigador: no hay ningún investigador. El proceso de investigación se ejecuta con una programación cron, llama a un conjunto de API y modelos, escribe resultados estructurados en D1 y activa el agente Editorial. El proceso sigue existiendo; el puesto humano que antes era su responsable, no.

Podría parecer una distinción semántica. No lo es. Cambia por completo el criterio para decidir qué puestos necesita una empresa.

Si el marco es el «ingeniero 100x», la pregunta frente a la plantilla de ingeniería es: ¿qué diez personas pueden quedarse para sustituir a las otras cien? La optimización consiste en retener a quienes más producen y recortar el resto.

Cuando el marco correcto es trasladar procesos a la automatización, las preguntas son otras. ¿Qué procesos de esta empresa pueden automatizarse por completo? ¿Cuáles exigen un juicio humano que los agentes no pueden replicar? ¿Qué puesto nuevo hace falta para gestionar, auditar y ampliar la flota de agentes? Las respuestas apuntan a perfiles diferentes.

El puesto que casi nadie está contratando todavía podría llamarse responsable de operaciones de agentes de IA. No es un prompt engineer ni un ML engineer. Es alguien que conoce el proceso de negocio lo bastante bien como para especificar qué debe hacer el agente; puede leer el registro de estado de un Durable Object para depurar un workflow bloqueado; detecta cuándo la calidad de los resultados empieza a desviarse; y sabe ampliar el sistema a medida que cambia el negocio. Las 12 horas semanales que dedico al sistema de publicación se parecen mucho a este puesto. No es trabajo de baja cualificación. Es un trabajo de gran impacto que exige a la vez conocimiento de procesos y suficiente soltura técnica para operar el sistema.

Es casi seguro que Cloudflare ya tiene este tipo de función internamente, aunque todavía no le haya puesto un nombre de puesto. Si una empresa recorta hasta quedarse con un equipo mínimo sin desarrollar esta capacidad, su flota de agentes se deteriorará en seis meses.

La automatización crea trabajo, pero no el mismo trabajo
Cada agente de producción que opero genera aproximadamente de 3 a 5 incidencias al mes que requieren intervención humana: corrupción de estado, resultados del modelo que no superan un control de calidad, una API downstream que cambia su esquema o una tarea que entra en deadlock porque dos agentes escribieron al mismo tiempo en la misma fila de D1. Ninguno de estos problemas es catastrófico. Todos necesitan a alguien que conozca el sistema. Recortar plantilla sin conservar la capacidad de operar los agentes hace que las incidencias se acumulen sin resolver.

Además, existe una categoría de trabajo que la automatización crea en vez de eliminar. El agente Editorial genera 47 briefs al mes, y ahora un editor humano los revisa y aprueba. Antes de que existiera el agente, quizá se redactaban 15. El agente no sustituyó al editor: amplió su alcance y elevó el nivel de exigencia de su trabajo. Algunos puestos cercanos a una flota de agentes se potencian, no desaparecen. Los fundadores que no tracen bien este mapa recortarán precisamente esos puestos y luego se preguntarán por qué cayó la producción.

Un marco para decidir la plantilla del H2 de 2026

Si el plan de plantilla para el H2 parte del relato de Cloudflare, este es el marco que yo usaría.

El primer paso es separar los procesos en dos columnas: procesos candidatos a la automatización y puestos candidatos a la sustitución.

Los procesos candidatos a la automatización son workflows en gran medida deterministas, que pueden especificarse por completo y cuya calidad de salida puede medirse automáticamente. Mantenimiento de pipelines de datos, producción de contenido a escala, clasificación inicial de soporte al cliente, generación de pruebas de QA, actualización de documentación y procesamiento de facturas. En estos casos, la pregunta no es «¿puede la IA ayudar a una persona a hacerlo más rápido?», sino «¿puedo sacar este proceso por completo de la columna de trabajo humano en los próximos 90 días?». Antes de tocar la plantilla, hay que probar un agente durante cuatro semanas.

Los puestos candidatos a la sustitución son distintos y mucho menos frecuentes. Se dan cuando una función humana consiste principalmente en ejecutar con destreza una tarea bien definida, esa tarea ya puede automatizarse y no existe alrededor ningún trabajo de decisión o de relación. Esos puestos sí corren un riesgo real. Sin embargo, representan una categoría menor de lo que sugiere el relato de Cloudflare, porque la mayoría de los puestos agrupan varias tareas en lugar de una sola. Un ingeniero que escribe código, revisa PR, define el alcance del trabajo, acompaña a perfiles junior y habla con clientes no puede sustituirse con un agente de programación. Quizá sí pueda automatizarse la parte de escribir código.

El cálculo de plantilla que se sostiene ante el consejo de una empresa entre una Serie A y una Serie C se plantea así: tomar el costo total actual del proceso, restarle el costo integral previsto de la flota de agentes que lo sustituiría —infraestructura, inferencia y carga operativa de los agentes— y presentar la diferencia. Con $233 al mes por 626 tareas, la rentabilidad es evidente para los procesos adecuados. En el caso de un puesto que realmente agrupa tareas y requiere juicio, las cifras empeoran con rapidez.

Lo que probaría antes de despedir a nadie es lo siguiente: ejecutar el agente en paralelo con la persona durante 60 días. Medir la calidad de ambos con la misma rúbrica. Medir la tasa de fallos y la frecuencia de las intervenciones. Calcular cuánto cuesta realmente la carga operativa de los agentes en tiempo de una persona. Si el agente supera el umbral de calidad al 30% del costo humano, incluida esa carga operativa, existe un caso sólido. Si la tasa de fallos exige más horas de intervención de las que se ahorran, no lo existe.

La prueba en condiciones reales no es complicada. La mayoría de los fundadores se la salta porque el relato de Cloudflare hace que parezca innecesaria. La promesa del 100x seduce. Pero esta es la conclusión desde dentro de un despliegue en producción sobre la misma plataforma: el dato importante no es el multiplicador de productividad, sino el costo por tarea con una calidad aceptable, incluida la carga operativa. Hay que hacer la prueba antes de llevar la cifra al consejo.

P: ¿El costo mensual de $233 aumenta de forma lineal al añadir más agentes?

En el caso de la inferencia, aproximadamente sí. Los costos de infraestructura de Cloudflare crecen despacio porque Workers y Durable Objects mantienen su eficiencia a escala. En este sistema, la inferencia es la principal variable. Si se duplica el volumen de tareas de los agentes, cabe esperar que su costo también se duplique aproximadamente. La infraestructura quizá aumente un 20-30%. La carga operativa crece más despacio que de forma lineal, porque se gestionan sistemas, no tareas individuales.

P: ¿Qué productos de Cloudflare son realmente imprescindibles en una flota de agentes en producción?

Durable Objects soporta la mayor parte del sistema. Sus máquinas de estado persistentes coordinan tareas de agentes de larga duración entre distintas invocaciones de Workers, sin necesitar una base de datos externa para la coordinación. D1 es el almacén relacional para los datos del negocio. R2 aporta almacenamiento de objetos. Vectorize almacena los embeddings. El Agents SDK es una capa de orquestación relativamente ligera sobre Durable Objects. Para quien esté evaluando esta plataforma, Durable Objects es la pieza central de la arquitectura.

P: ¿Cómo es en la práctica el trabajo diario de operaciones de agentes?

En mi caso, son 30 minutos cada mañana para revisar los registros de tareas en busca de fallos o desviaciones de calidad; unas dos horas por semana para depurar o ampliar los workflows de los agentes; y una revisión fija cada lunes de la calidad de los resultados de la semana anterior. El resto es reactivo: algo se rompe y lo arreglo. En una flota mayor que atienda a un equipo de 20+, probablemente sería un puesto de media jornada y no una actividad para ratos libres.

Qué conviene observar en los próximos 30 días

El enfoque presentado en los resultados de Cloudflare se va a extender. Cabe esperar que al menos entre tres y cinco empresas tecnológicas cotizadas más invoquen las «mejoras de productividad por IA» para justificar recortes de plantilla antes de que cierre la temporada de resultados del Q2. Los fundadores a los que vale la pena observar son quienes anuncien recortes junto con detalles concretos de sus despliegues de agentes, no quienes se limiten a afirmaciones vagas de productividad. Eso sí sería una señal real. Las afirmaciones genéricas sin plataforma, volumen de tareas ni costo por tarea son teatro para el consejo.

En cuanto a la plataforma de Cloudflare, el Agents SDK está madurando rápido. El precio de la hibernación de Durable Objects cambió a principios de este año y ahora resulta considerablemente más favorable para agentes siempre activos. Para quien llevaba tiempo evaluando esta arquitectura sin dar el paso, la curva de costos se movió a su favor. La complejidad operativa no desapareció, pero es manejable a la escala que realmente necesita la mayoría de las empresas entre una Serie A y una Serie C.

El mercado laboral de operaciones de agentes surgirá en los próximos 12 meses como una categoría profesional diferenciada. Conviene adelantarse y definir cómo sería ese puesto dentro de la empresa antes de que el título aparezca en LinkedIn.

Para hacer la auditoría de procesos antes de cerrar el plan del H2, la lista de comprobación de workflows que utilizo en DVNC.dev encaja directamente con este marco.

Resumen

• Los resultados de Cloudflare del Q1 de 2026 combinaron $639.8M en ingresos, 1,100 despidos y una afirmación de productividad por IA de «2x a 100x».
• Operar 6 agentes en producción con Cloudflare Workers, Durable Objects, D1 y el Agents SDK cuesta $233 al mes por 626 tareas, con todos los costos incluidos: unos $0.37 por tarea, incluida la inferencia.
• El marco del ingeniero 100x es erróneo. El cambio real consiste en sacar procesos completos de la columna de trabajo humano, no en multiplicar la producción de una persona.
• El puesto que nadie está contratando todavía es Agent Operations: la persona que gestiona, audita y amplía la flota de agentes. Si los recortes dejan un equipo mínimo sin esta capacidad, la flota se deteriorará.
• Antes de incluirlo en la presentación del consejo, hay que ejecutar una prueba paralela de 60 días: agente y persona, la misma rúbrica de calidad y una medición real de la carga operativa. Las cifras suelen ser atractivas, pero no siempre dicen lo que sugiere el relato.
• La variable decisiva es el costo por tarea con una calidad aceptable, incluida la carga operativa, no un multiplicador de productividad.