Després de l'automatització: el framer, no el frame, és on segueix vivint la feina

Dan Shipper (Every) acaba de publicar After Automation, un assaig que val la pena llegir sencer i que mereix una resposta des de la trinxera europea de DevOps i plataforma. La seva tesi central és que com més automatitza amb IA, més feina humana experta apareix — no menys. Every té 30 empleats, ha automatitzat amb Claude Code i agents async tot el que ha pogut, i no ha eliminat posicions. La feina ha canviat de forma, no ha desaparegut.

Hi estic d'acord. Però la part de l'article que es mereix més atenció — i que cap roadmap de "transformació amb IA" que he revisat aquest any nomena — és la distinció entre el frame i el framer. Aquesta és la línia que separa els equips que entendran què estan comprant els pròxims dos anys dels que es despertaran havent comprat un dashboard.

La paradoxa que els meus clients ja viuen sense saber-ho

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

Tradueixo això al meu món. Quan posem Claude Code, agents de revisió de PR i pipelines amb LLMs en un equip de plataforma de banca o salut, no veig l'equip encongir-se. Veig:

• Més PRs oberts per unitat de temps, perquè el cost marginal d'obrir-ne un baixa.
• Més decisions arquitectòniques per setmana, perquè cada PR força una sobre destí, autoritzacions o impacte regulatori que abans s'evitava per fricció.
• Més temps dedicat a definir què val la pena automatitzar, perquè automatitzar la feina equivocada ara és barat i ràpid — la qual cosa la fa més perillosa, no menys.

El cap de plataforma que pensava que la IA li reduiria headcount es troba amb la pregunta inversa: com escalo el judici sènior necessari per filtrar el volum que els agents ara produeixen? Aquesta pregunta no és una crítica de la IA. És la prova que funciona.

És el mateix patró que vaig llegir als números d'ActionNex de Microsoft: 71% de precision, 53% de recall sobre incidents reals d'Azure. El sistema funciona prou bé per ser desplegable i no prou bé per ser autònom. La conseqüència no és "menys SREs"; és SREs amb una superfície de decisió més gran perquè ara revisen recomanacions a una cadència que abans no existia.

El frame, el framer, i per què aquesta distinció és la única que importa

La part més infrautilitzada de l'article de Shipper és aquesta:

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

Tradueixo. Un benchmark mesura el rendiment del model dins d'un frame — un prompt concret, un dataset concret, una definició concreta de "tasca completada". Quan un model satura aquell frame, la indústria desplaça el frame: ara no mesurem "escriure el codi" sinó "decidir quan reescriure el codi". El nou frame torna a marcar 60 i tots ens posem nerviosos altra vegada.

Shipper en diu Zeno's Paradox of AI. Jo en dic una cosa més operativa: el framer és el rol que sobreviu, i és el rol que la majoria de roadmaps no anomenen perquè no saben com pressupostar-lo.

Tres conseqüències pràctiques que cap pitch d'IA que he sentit aquest any aborda directament:

1. El frame del proveïdor caduca abans que el contracte. Si compres una "plataforma d'IA per a operacions" basant-te en una capacitat que avui demostra dins d'un frame concret, el frame es desplaçarà abans no acabi el cicle pressupostari. El que has comprat no és la capacitat — és la promesa que el proveïdor sabrà reframejar abans que tu. Sovint no la sap.

2. El framer no és un càrrec. És una funció distribuïda. A un equip de plataforma, el framer és qui decideix quins workloads valen la pena ser automatitzats aquest trimestre, sota quines restriccions de compliance, energia i risc, amb quin pressupost d'errors acceptable. No és el ML lead. No és el VP d'enginyeria sol. És la composició dels dos amb el regulador a la sala — i és el rol més infraestaffejat que veig avui.

3. A sectors regulats, el frame és un artefacte regulatori. Aquesta és la part que Shipper, escrivint des d'una SaaS B2B, no necessita dir. Però per a un client de banca, salut o sector públic, el frame mateix — què compta com a "decisió correcta", quina dada compta com a "PII", què compta com a "incident reportable" — el defineix el regulador. Per definició, no es pot deixar a un model que va ser entrenat sobre el frame d'ahir. El framer aquí no és opcional. És el lloc on viu la legitimitat del sistema.

L'analogia del nen — i per què a producció és més incòmoda del que sembla

Shipper compara els agents actuals amb un nen petit: tenen agència, volen coses, persegueixen objectius autodirigits que ningú els ha donat. Els LLMs no. Executen frames donats.

A producció enterprise aquesta distinció és més incòmoda del que sembla per dues raons:

• Volem que els agents no tinguin agència. Un agent amb objectius emergents en un entorn regulat és un problema, no una promesa. La narrativa "AGI amb voluntat pròpia" que circula a Silicon Valley és exactament el contrari del que un CISO accepta. Per tant, la limitació que Shipper anomena ("els models executen objectius d'altri") és, al meu sector, una feature, no un defecte.

• Però vol dir que el cost de definir bé l'objectiu no baixa, puja. Si l'agent no s'autodirigeix, cada autorització, cada constraint, cada criteri d'èxit l'ha de posar un humà — i la qualitat del resultat la determina la qualitat del frame, no la del model. Un equip que escala agents sense escalar la qualitat dels seus frames està fabricant slop a velocitat industrial amb un certificat ISO al darrere.

Aquesta és la lectura que jo afegiria a Shipper: el "framer" no és només un rol de producte o estratègia. En entorns regulats, el framer és el control més pobrament documentat del sistema sociotècnic complet, i els auditors hi arribaran abans del 2027.

L'asimetria que cap proveïdor t'explicarà

Shipper observa que els models només saben sobre feina que ja s'ha fet. Els humans saben sobre feina que cal fer ara. Aquesta asimetria té una conseqüència de procurement que no apareix a cap deck:

Quan un proveïdor d'IA et presenta una capacitat nova, t'està mostrant el resultat sobre dades de captures del passat: codis ja escrits, incidents ja resolts, contractes ja signats. El que no et pot demostrar és el rendiment sobre el problema d'aquest trimestre, perquè aquell problema encara no és al training set de ningú. Per tant:

• La diferència entre el rendiment de demo i el rendiment de producció no és un bug del proveïdor. És estructural.
• Aquesta diferència l'omple el framer humà — el qual el proveïdor no et ven, perquè no és el seu producte.
• El cost real del sistema = cost de la llicència + cost del framer humà que el manté rellevant. La majoria de business cases només pressuposten la primera.

Si el teu business case d'IA aquest any no té una línia per "headcount sènior per mantenir els frames actualitzats", el business case està incomplet. La línia no és gran, però no és zero, i sense ella el sistema deriva.

Què faria al roadmap aquest trimestre

Per a un equip de plataforma o d'enginyeria en un sector regulat, tres moviments concrets en resposta a l'article de Shipper:

1. Anomena el rol de framer al teu org chart. No cal crear un càrrec nou. Però sí cal que algú concret tingui escrit a la seva descripció de feina: "defineix els frames sota els quals operen els nostres sistemes d'IA, els revisa trimestralment, i és el punt de contacte amb compliance quan el frame canvia." Si ningú té això escrit, ho fa tothom una mica i ningú bé.

2. Auditeu l'asimetria de training set. Per a cada sistema d'IA en producció, una taula: quin frame del proveïdor va comprar-se, quines dades l'entrenaven, quines decisions del teu negoci han canviat des d'aleshores. La distància entre aquelles dues columnes és el deute tècnic invisible. Probablement més gran del que esperes.

3. Pressuposta la feina post-automatització, no la pre-. El cost del sistema no és el cost de desplegar-lo; és el cost de mantenir-lo rellevant mentre el frame canvia sota ell. Un agent de PR review desplegat al gener de 2026 sobre un codebase Python 3.11 monolític no és el mateix sistema al desembre quan has migrat a microserveis Go. El frame ha canviat. Algú l'ha de tornar a definir. Aquest "algú" és una línia pressupostària, no un voluntari.

La línia que dibuixo

Estic on the record com a positiu envers els LLMs i els sistemes agèntics en producció. Els despleguem, els facturem, em paguen per fer-ho. El que veig — i el que l'article de Shipper articula millor que la majoria — és que el guany d'automatització real no apareix a la línia "FTEs reduïts" del business case. Apareix a la línia "decisions per setmana que abans no preníem", "PRs per setmana que abans no obríem", "incidents per mes que abans no detectàvem". Cap d'aquestes línies retalla cost — totes incrementen capacitat. Aquesta és la conversa honesta.

I al darrere de tot, hi ha sempre algú definint el frame: què val la pena decidir, què val la pena obrir, què val la pena detectar. Aquest algú no és substituïble per cap model entrenat sobre el passat, perquè la pregunta canvia més ràpid que el cicle d'entrenament. Si el teu programa d'IA aquest any no té nominat el framer — i no només el frame — estàs construint un sistema que envellirà a la velocitat del proveïdor, no a la velocitat del teu negoci.

La feina interessant, com sempre, passa just al costat d'on tothom està mirant.

---

Fonts:

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

Posant agents i LLMs en producció en un entorn regulat i no estàs segur de qui és el framer al teu equip? Parla amb un CTO — t'ajudem a separar el frame de la feina del framer abans que el regulador ho faci per tu.