Meta estaría probando robots dentro de sus centros de datos para tareas físicas concretas: cambiar cables de red y, según los testimonios recogidos, evaluar si un brazo Kinova Gen3 puede encender, apagar o cortar el suministro eléctrico de servidores. Lo publicó Wired a partir de empleados actuales y antiguos que pidieron anonimato, y La Nación Tecno lo reportó en español, con pilotos ubicados en instalaciones de Iowa y Virginia y hardware de Watney Robotics, Kinova y ABB. El vocero de la compañía, Francis Brennan, empujó la lectura opuesta a la del recorte: dice que hay escasez de trabajadores calificados y que necesitan más gente, no menos.
Por qué importa
La discusión pública se va a ir enseguida al reemplazo de puestos, y es entendible: la frase de uno de los trabajadores —pensábamos que los que hacíamos las tareas físicas estábamos a salvo— es el titular perfecto. Pero para alguien que construye software arriba de todo esto, la señal es otra y es más incómoda.
Hasta ahora, el mantenimiento físico de un data center era artesanal por definición: un humano, un rack, una orden de trabajo. Esa artesanía es lenta, pero tiene una propiedad hermosa que damos por sentada: no escala los errores. Un técnico cansado desconecta el servidor equivocado, uno solo. Cuando esa misma acción pasa a ser un actuador con una cola de trabajos, un scheduler y un firmware, el mantenimiento se convierte en un sistema con throughput, latencia y bugs. Y los bugs de ese tipo de sistema no se ven como un incidente aislado: se ven como fallas correlacionadas.
Es la misma curva que ya vivimos en la capa de software. Infraestructura como código nos dio velocidad y reproducibilidad, y también nos dio el borrado de una tabla de producción con un terraform apply a las dos de la mañana. Ahora la promesa —respuesta más rápida a incidentes, monitoreo continuo, mantenimiento preventivo, según lo que el director senior de robótica de Meta, Eric Xu, planteó públicamente— viene con el mismo paquete adjunto: menos MTTR, más blast radius potencial.
Qué cambia en la práctica
No cambia tu stack esta semana. Cambia qué supuestos podés seguir sosteniendo sobre el piso donde corre tu app. Yo miraría estas cuatro cosas, en este orden.
| Tarea que se automatiza | Supuesto que se cae | Qué reviso en mi lado |
|---|---|---|
| Cambio de cables de red | La partición de red es rara y breve | Timeouts explícitos, reintentos con backoff, idempotencia en los writes |
| Encendido y apagado de servidores | Un shutdown siempre es anunciado | Manejo real de SIGTERM y drenaje de conexiones |
| Corte de suministro eléctrico | El proceso alcanza a cerrar prolijo | Escrituras atómicas, transacciones cortas, nada de estado sólo en memoria |
| Mantenimiento preventivo programado | Las fallas son independientes entre sí | Distribución entre zonas, no entre máquinas de un mismo rack |
El punto del apagón abrupto es el que más veo mal resuelto en proyectos reales. Muchísimos servicios Node en producción no tienen cierre ordenado: el contenedor recibe la señal, muere, y las requests en vuelo se cortan a la mitad. Eso hoy se paga con un pico de 502; en un mundo donde el ciclo de energía de un servidor es una acción programática y más frecuente, se paga seguido.
process.on('SIGTERM', async () => {
server.close() // deja de aceptar nuevas conexiones
await inFlight.drain(15_000) // termina lo que ya entró
await db.end() // libera el pool
process.exit(0)
})Y si tu respuesta es “nunca probé qué pasa si la máquina se apaga sin avisar”, ahí está el trabajo de esta semana. No hace falta caos engineering con presupuesto de Netflix: matar el proceso con SIGKILL mientras corre carga y ver qué queda inconsistente ya te dice casi todo.
Cuándo NO usarlo
Acá va la parte honesta, porque esta noticia se presta al sobreanálisis.
- La evidencia es delgada. Son testimonios anónimos sobre pruebas. No hay cifras de despliegue, ni cantidad de robots, ni resultados de esas evaluaciones, ni un cronograma. El material disponible no dice si el brazo Kinova pasó de la evaluación a la operación. Tratarlo como un cambio consumado es inventar.
- Meta no es tu proveedor. Salvo casos puntuales, no alquilás capacidad en los data centers de Meta. Esto es una señal de dirección de la industria, no un cambio en el SLA que firmaste. Migrar de proveedor por esta nota sería una decisión sin fundamento.
- Si tu app vive en un VPS único, esto es literatura. Tu riesgo real ahí es otro: no tenés redundancia, y ningún robot va a cambiar eso. Primero resolvé backups y recuperación, después preocupate por la correlación de fallas.
- No copies el patrón en tu propia infra sin límites. La tentación de automatizar runbooks destructivos —reiniciar nodos, rotar instancias, cortar tráfico— crece con cada incidente que resolviste a mano. Automatizalo, sí, pero con blast radius acotado: tope de nodos por ventana, confirmación humana arriba de cierto umbral, y kill switch. Un actuador sin límite superior es una fábrica de incidentes grandes.
Tampoco leería esto como “la robótica ya está lista”. Que Meta esté evaluando proveedores distintos para tareas tan específicas sugiere lo contrario: todavía se está buscando qué funciona.
Qué haría hoy
Nada de arquitectura. Una tarde de verificación: confirmar que cada servicio maneja SIGTERM, que las operaciones críticas son idempotentes, y que las réplicas están repartidas entre zonas de verdad y no por casualidad. Es trabajo que ya deberías tener hecho; esta noticia solo mueve la prioridad hacia arriba.
Y una nota al margen que me parece la más interesante de la semana: en paralelo a esto, Meta presentó Muse, su agente personal, un lanzamiento que Stratechery señala como potencialmente mucho más impactante en la vida diaria que otros anuncios más vistosos. La misma compañía empuja automatización en los dos extremos de la cadena: el brazo que reemplaza un cable y el agente que te reserva un vuelo. El software del medio —el nuestro— es lo que tiene que aguantar ambos.