Trabajo

Meta frenó su plan de recortar equipos un 60%: los agentes multiplicaron incidentes

|Autor: Equipo editorial de QUASA|5 lectura mínima| 3
Meta frenó su plan de recortar equipos un 60%: los agentes multiplicaron incidentes

Una investigación de Reuters publicada el 26 de agosto de 2026 reconstruyó cómo Meta estudió reducir algunos equipos hasta un 60%, ejecutó un recorte general del 10% en mayo y canceló la segunda reorganización prevista para noviembre; la respuesta de la compañía incorporada al reportaje aclaró que el escenario máximo combinaba despidos, traslados y cierre de vacantes, y nunca abarcó al 60% de toda la plantilla.

La retirada de esa segunda fase coincidió con una brecha difícil de ignorar: los agentes ayudaban a producir muchas más modificaciones de software, pero las funciones entregadas crecían mucho menos, mientras aumentaban los incidentes técnicos y de seguridad y el trabajo humano necesario para resolverlos. La investigación no estableció una causa única para la cancelación, por lo que los fallos operativos, la oposición interna y la presión financiera deben entenderse como factores concurrentes.

Project OT pretendía cambiar quién hacía el trabajo cotidiano

Project OT distribuye tareas de ingeniería, producto y diseño entre agentes de IA supervisados por equipos humanos más pequeños.

Project OT, abreviatura de Organization Transformation, no se limitaba a acelerar la programación. Su objetivo era reorganizar Meta como una empresa «nativa de IA», con agentes encargados de una parte del trabajo diario que realizaban empleados de ingeniería, producto, diseño y otras áreas.

El modelo contemplaba grupos humanos más pequeños para supervisar a esos trabajadores virtuales. También proponía reducir capas directivas, agrupar distintas especialidades bajo el título general de «builder» y emplear análisis asistido por agentes para ordenar prioridades.

La reducción máxima era un ejercicio de planificación para determinados equipos, no una decisión aprobada para toda la empresa. Además de posibles despidos, incluía mover empleados a nuevas unidades, eliminar puestos aún sin cubrir y concentrar recursos en áreas prioritarias, entre ellas la preparación de datos para modelos de IA.

Esta distinción cambia la respuesta a la pregunta de si Meta pretendía reemplazar empleados con agentes: la sustitución de trabajo humano formaba parte del diseño, pero su alcance máximo nunca llegó a convertirse en un recorte general autorizado. Algunas estructuras más pequeñas sí se implantaron, mientras la reorganización posterior quedó suspendida.

La cronología separa el recorte real del escenario cancelado

Meta mantiene la primera reducción de plantilla y cancela la segunda reorganización prevista para noviembre.

La transformación se había dividido en dos oleadas. La primera siguió adelante e incluyó despidos y el traslado de miles de trabajadores a áreas consideradas prioritarias; la segunda debía extender la reorganización a finales de año.

Mark Zuckerberg detuvo la planificación de esa segunda oleada horas antes de que se comunicara la primera reducción. En ese momento todavía no se había fijado cuántas personas perderían su empleo en la fase posterior, de modo que el escenario más severo no puede presentarse como una cifra de despidos aprobada.

Tampoco se canceló toda la estrategia de automatización. Meta mantuvo equipos reorganizados, unidades dedicadas a entrenar modelos y proyectos para desarrollar agentes capaces de escribir código o ejecutar tareas en sistemas internos. Lo que se frenó fue la ampliación de los cambios laborales más agresivos.

La resistencia de la plantilla se intensificó porque otra iniciativa interna registraba pulsaciones, clics y movimientos del ratón en equipos de empleados estadounidenses para enseñar a los modelos a utilizar ordenadores. Parte de los trabajadores interpretó que estaba ayudando a entrenar posibles sustitutos; el programa acabó pausado después de un problema de seguridad y de la primera oleada de recortes.

Más código no significó una capacidad equivalente de entrega

Los cambios automatizados de código crecen más rápido que las funciones entregadas mientras aumenta el trabajo de respuesta a incidentes.

El resumen de Engadget sobre las métricas internas cifra en un 220% interanual el crecimiento de los cambios en plataformas e infraestructura, frente a un 36% en las funciones nuevas o mejoradas que llegaron a los usuarios; en el mismo periodo, los incidentes técnicos y de seguridad aumentaron un 40% y el tiempo dedicado a atenderlos, un 70%.

Esos indicadores medían cosas diferentes. El volumen de modificaciones reflejaba actividad; las funciones publicadas mostraban solo la parte que atravesaba pruebas y llegaba al producto; los incidentes y el tiempo de recuperación registraban una carga operativa que continuaba recayendo en personas.

Los documentos vinculaban el auge del código asistido por IA y las acciones de agentes sin suficiente supervisión con advertencias de fiabilidad, interrupciones y posibles filtraciones. Sin embargo, no detallaban cada incidente ni permitían atribuir todos los fallos a un agente concreto.

La conclusión relevante para Project OT es más limitada pero sólida: producir código con mayor rapidez no demostró que los agentes pudieran asumir el trabajo completo de equipos enteros. Si la revisión, la contención de fallos y la reparación crecen a la vez, una plantilla menor puede terminar dedicando más capacidad a vigilar la automatización en lugar de entregar producto.

Meta redujo la reorganización, pero mantiene la apuesta por la IA

El retroceso laboral no equivale a abandonar los agentes. La compañía continúa invirtiendo en infraestructura, modelos y especialistas, y conserva parte de las estructuras creadas durante la transformación.

El análisis de Cinco Días añade otra limitación económica: el coste de los centros de datos y del talento especializado puede absorber parte del ahorro esperado por la reducción de plantilla, sobre todo mientras la fiabilidad del trabajo automatizado siga en duda.

Por ahora, la historia queda dividida en tres estados: hubo un escenario máximo para algunos equipos, una reducción que sí se ejecutó y una segunda reorganización que fue cancelada antes de fijar su alcance final. No se conoce qué factor pesó más en el cambio de rumbo ni qué componentes de Project OT se ampliarán después.

La prueba pendiente ya no es cuántos cambios pueden generar los agentes, sino cuántos llegan a convertirse en funciones estables sin elevar los fallos ni trasladar más tareas de supervisión y reparación a los empleados restantes. Project OT muestra una automatización laboral rebajada por sus resultados operativos, no una sustitución demostrada de equipos humanos completos.

Lee también:

Compartir:

Suscríbete a nuestro boletín

Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.

0