Después de la automatización: el framer, no el frame, es donde sigue viviendo el trabajo

Dan Shipper (Every) acaba de publicar After Automation, un ensayo que vale la pena leer entero y que merece una respuesta desde la trinchera europea de DevOps y plataforma. Su tesis central es que cuanto más automatizas con IA, más trabajo humano experto aparece — no menos. Every tiene 30 empleados, ha automatizado con Claude Code y agentes async todo lo que ha podido, y no ha eliminado puestos. El trabajo ha cambiado de forma, no ha desaparecido.

Estoy de acuerdo. Pero la parte del artículo que merece más atención — y que ningún roadmap de "transformación con IA" que haya revisado este año nombra — es la distinción entre el frame y el framer. Esa es la línea que separa los equipos que entenderán qué están comprando los próximos dos años de los que se despertarán habiendo comprado un dashboard.

La paradoja que mis clientes ya viven sin saberlo

Shipper formula la paradoja con una frase limpia: "Making expert work cheaper does not simply replace experts. It creates more situations where expert judgment is needed."

Traduzco esto a mi mundo. Cuando metemos Claude Code, agentes de revisión de PR y pipelines con LLMs en un equipo de plataforma de banca o salud, no veo al equipo encoger. Veo:

• Más PRs abiertos por unidad de tiempo, porque el coste marginal de abrir uno baja.
• Más decisiones arquitectónicas por semana, porque cada PR fuerza una sobre residencia de datos, autorizaciones o impacto regulatorio que antes la fricción absorbía silenciosamente.
• Más tiempo dedicado a definir qué vale la pena automatizar, porque automatizar el trabajo equivocado ahora es barato y rápido — lo cual lo hace más peligroso, no menos.

El jefe de plataforma que pensaba que la IA le iba a reducir headcount se encuentra con la pregunta inversa: ¿cómo escalo el juicio sénior necesario para filtrar el volumen que los agentes están produciendo ahora? Esa pregunta no es una crítica de la IA. Es la prueba de que funciona.

Es el mismo patrón que leí en los números de ActionNex de Microsoft: 71% de precision, 53% de recall sobre incidentes reales de Azure. El sistema funciona lo bastante bien como para ser desplegable y no lo bastante como para ser autónomo. La consecuencia no es "menos SREs"; es SREs con una superficie de decisión mayor porque ahora revisan recomendaciones a una cadencia que antes no existía.

El frame, el framer, y por qué esta distinción es la única que importa

La parte más infrautilizada del ensayo de Shipper es esta:

The frame is not the framer. […] Humans know about what needs to be done, right now.

Traduzco. Un benchmark mide el rendimiento del modelo dentro de un frame — un prompt concreto, un dataset concreto, una definición concreta de "tarea completada". Cuando un modelo satura ese frame, la industria desplaza el frame: ahora no medimos "escribir el código" sino "decidir cuándo reescribir el código". El nuevo frame vuelve a marcar 60 y todos nos ponemos nerviosos otra vez.

Shipper lo llama Zeno's Paradox of AI. Yo lo llamo algo más operativo: el framer es el rol que sobrevive, y es el rol que la mayoría de roadmaps no nombran porque no saben cómo presupuestarlo.

Tres consecuencias prácticas que ningún pitch de IA que haya oído este año aborda directamente:

1. El frame del proveedor caduca antes que el contrato. Si compras una "plataforma de IA para operaciones" basándote en una capacidad que hoy demuestra dentro de un frame concreto, el frame se desplazará antes de que termine el ciclo presupuestario. Lo que has comprado no es la capacidad — es la promesa de que el proveedor sabrá reframear antes que tú. A menudo no sabe.

2. El framer no es un cargo. Es una función distribuida. En un equipo de plataforma, el framer es quien decide qué workloads vale la pena automatizar este trimestre, bajo qué restricciones de compliance, energía y riesgo, con qué presupuesto de errores aceptable. No es el ML lead. No es el VP de Ingeniería solo. Es la composición de ambos con el regulador en la sala — y es el rol más infraestaffeado que veo hoy.

3. En sectores regulados, el frame es un artefacto regulatorio. Esta es la parte que Shipper, escribiendo desde una SaaS B2B, no necesita decir. Pero para un cliente de banca, salud o sector público, el frame mismo — qué cuenta como "decisión correcta", qué cuenta como "PII", qué cuenta como "incidente reportable" — lo define el regulador. Por definición, no se puede delegar a un modelo entrenado sobre el frame de ayer. El framer aquí no es opcional. Es el lugar donde vive la legitimidad del sistema.

La analogía del niño — y por qué en producción es más incómoda de lo que parece

Shipper compara los agentes actuales con un niño pequeño: tienen agencia, quieren cosas, persiguen objetivos autodirigidos que nadie les ha dado. Los LLMs no. Ejecutan frames dados.

En producción enterprise esa distinción es más incómoda de lo que parece por dos razones:

• Queremos que los agentes no tengan agencia. Un agente con objetivos emergentes en un entorno regulado es un problema, no una promesa. La narrativa de "AGI con voluntad propia" que circula por Silicon Valley es exactamente lo contrario de lo que un CISO acepta firmar. Por tanto, la limitación que Shipper nombra ("los modelos ejecutan objetivos ajenos") es, en mi sector, una feature, no un defecto.

• Pero significa que el coste de definir bien el objetivo no baja, sube. Si el agente no se autodirige, cada autorización, cada constraint, cada criterio de éxito lo tiene que poner un humano — y la calidad del resultado la determina la calidad del frame, no la del modelo. Un equipo que escala agentes sin escalar la calidad de sus frames está fabricando slop a velocidad industrial con un certificado ISO grapado al lado.

Esta es la lectura que yo añadiría a Shipper: el "framer" no es solo un rol de producto o estrategia. En entornos regulados, el framer es el control peor documentado del sistema sociotécnico completo, y los auditores llegarán a él antes de 2027.

La asimetría que ningún proveedor te explicará

Shipper observa que los modelos solo saben sobre trabajo que ya se ha hecho. Los humanos saben sobre trabajo que hay que hacer ahora. Esa asimetría tiene una consecuencia de procurement que no aparece en ningún deck:

Cuando un proveedor de IA te presenta una capacidad nueva, te está enseñando el resultado sobre capturas del pasado: códigos ya escritos, incidentes ya resueltos, contratos ya firmados. Lo que no te puede demostrar es el rendimiento sobre el problema de este trimestre, porque ese problema todavía no está en el training set de nadie. Por tanto:

• La diferencia entre rendimiento de demo y rendimiento en producción no es un bug del proveedor. Es estructural.
• Esa diferencia la cierra el framer humano — que el proveedor no te vende, porque no es su producto.
• Coste real del sistema = coste de la licencia + coste del framer humano que lo mantiene relevante. La mayoría de business cases solo presupuestan el primero.

Si tu business case de IA este año no tiene una línea para "headcount sénior para mantener los frames actualizados", el business case está incompleto. La línea no es grande, pero no es cero, y sin ella el sistema deriva.

Qué pondría en el roadmap este trimestre

Para un equipo de plataforma o de ingeniería en un sector regulado, tres movimientos concretos en respuesta al ensayo de Shipper:

1. Nombra el rol de framer en tu org chart. No hace falta crear un puesto nuevo. Pero alguien concreto tiene que tener escrito en su descripción de puesto: "define los frames bajo los que operan nuestros sistemas de IA, los revisa trimestralmente, y es el punto de contacto con compliance cuando el frame cambia." Si nadie lo tiene por escrito, lo hace todo el mundo un poco y nadie bien.

2. Auditad la asimetría del training set. Para cada sistema de IA en producción, una tabla: qué frame del proveedor compraste, con qué datos lo entrenaron, qué decisiones de tu negocio han cambiado desde entonces. La distancia entre esas dos columnas es la deuda técnica invisible. Probablemente más grande de lo que esperas.

3. Presupuesta el trabajo post-automatización, no el pre-. El coste del sistema no es el coste de desplegarlo; es el coste de mantenerlo relevante mientras el frame cambia debajo. Un agente de PR review desplegado en enero de 2026 sobre un codebase Python 3.11 monolítico no es el mismo sistema en diciembre cuando has migrado a microservicios Go. El frame ha cambiado. Alguien lo tiene que redefinir. Ese "alguien" es una línea presupuestaria, no un voluntario.

La línea que dibujo

Estoy on the record como positivo respecto a los LLMs y los sistemas agénticos en producción. Los desplegamos, los facturamos, me pagan por hacerlo. Lo que veo — y lo que el ensayo de Shipper articula mejor que la mayoría — es que la ganancia real de automatización no aparece en la línea "FTEs reducidos" del business case. Aparece en la línea "decisiones por semana que antes no tomábamos", "PRs por semana que antes no abríamos", "incidentes por mes que antes no detectábamos". Ninguna de esas líneas recorta coste — todas incrementan capacidad. Esa es la conversación honesta.

Y detrás de todo, siempre hay alguien definiendo el frame: qué vale la pena decidir, qué vale la pena abrir, qué vale la pena detectar. Ese alguien no es sustituible por ningún modelo entrenado sobre el pasado, porque la pregunta cambia más rápido que el ciclo de entrenamiento. Si tu programa de IA este año no tiene nombrado el framer — y no solo el frame — estás construyendo un sistema que envejecerá a la velocidad del proveedor, no a la de tu negocio.

El trabajo interesante, como siempre, pasa justo al lado de donde todo el mundo está mirando.

---

Fuentes:

• Dan Shipper, After Automation, Every, mayo de 2026. every.to/p/after-automation

¿Poniendo agentes y LLMs en producción en un entorno regulado y no estás seguro de quién es el framer en tu equipo? Habla con un CTO — te ayudamos a separar el frame del trabajo del framer antes de que el regulador lo haga por ti.