Després de l'automatització: el framer, no el frame, és on encara viu 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 del DevOps i la plataforma. La seva tesi central és que com més automatitzes amb IA, més feina humana experta apareix — no menys. Every té 30 empleats, ha automatitzat amb Claude Code i agents asíncrons tot el que ha pogut, i no ha retallat ni un sol lloc de treball. La feina ha canviat de forma, no ha desaparegut.

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

La paradoxa que alguns ja viuen sense adonar-se'n

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

T'ho tradueixo al meu món. Quan posem Claude Code, agents de revisió de PRs i pipelines basats en LLMs dins d'un equip de plataforma de banca o de salut, no veig que l'equip s'encongeixi. Veig:

• Més PRs oberts per unitat de temps, perquè el cost marginal d'obrir-ne un cau.
• Més decisions d'arquitectura cada setmana, perquè ara cada PR n'obliga una — sobre residència de dades, autorització, abast de l'impacte regulatori — que abans la fricció absorbia en silenci.
• Més temps dedicat a decidir què val la pena automatitzar, perquè automatitzar la feina equivocada ara és barat i ràpid, cosa que ho fa més perillós, no menys.

El cap de plataforma que esperava que la IA li reduís la plantilla es topa amb la pregunta inversa: com escalo el judici sènior que cal per filtrar el volum que ara produeixen els agents? Aquesta pregunta no és una crítica a la IA. És la prova que funciona.

És el mateix patró que vaig llegir en els números d'ActionNex de Microsoft: un 71% de precisió i un 53% de recall sobre incidents reals d'Azure. El sistema funciona prou bé per desplegar-lo 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 és la distinció que importa

La part més desaprofitada de l'assaig de Shipper és aquesta:

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

M'explico. 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 aquest frame, la indústria el desplaça: deixem de mesurar «escriure el codi» i passem a mesurar «decidir quan reescriure el codi». El nou frame torna a puntuar 60 i tothom s'esvera, com si fos la primera vegada.

Shipper en diu la paradoxa de Zenó de la IA. Jo en diria 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 no aborda directament:

1. Els frames dels proveïdors caduquen abans que els contractes. Si avui compres una «plataforma d'IA per a operacions» per una capacitat que llueix en demo dins d'un frame concret, el frame s'haurà desplaçat abans que s'acabi el cicle pressupostari. El que has comprat no és la capacitat: és la promesa que el proveïdor redefinirà el frame abans que tu. Sovint no ho farà.

2. El framer no és un càrrec. És una funció distribuïda. En un equip de plataforma, el framer és qui decideix quins workloads val la pena automatitzar aquest trimestre, sota quines restriccions de compliance, energia i risc, amb quin pressupost d'error acceptable. No és el responsable de ML. No és el VP d'enginyeria tot sol. És la combinació de tots dos amb el regulador a la sala — i és el rol més mancat de personal que veig avui.

3. En els sectors regulats, el frame és un artefacte regulatori. Aquesta és la part que Shipper, que escriu des de la talaia d'un SaaS B2B, no necessita explicitar. Però per a un client de banca, de salut o del sector públic, el frame mateix — què compta com a «decisió correcta», què compta com a «PII», què compta com a «incident notificable» — el defineix el regulador. Per definició, no es pot delegar en un model entrenat amb el frame d'ahir. Aquí el framer no és opcional. És on viu la legitimitat del sistema.

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

Shipper compara els agents actuals amb un nen petit: un nen petit té agència, vol coses, persegueix objectius propis que ningú no li ha donat. Els LLMs, no. Executen els frames que se'ls donen.

En 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 de Silicon Valley de l'«AGI amb voluntat pròpia» és exactament el contrari del que un CISO signarà mai. Per tant, la limitació que Shipper assenyala — «els models executen els objectius d'altri» — al meu sector és una feature, no un defecte.

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

Aquesta és la lectura que jo hi afegiria: el «framer» no és només un rol de producte o d'estratègia. En entorns regulats, el framer és el control pitjor documentat de tot el sistema sociotècnic, i els auditors hi arribaran abans del 2027.

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

Shipper observa que els models només coneixen la feina que ja s'ha fet. Els humans coneixen la feina que cal fer ara mateix. Aquesta asimetria té una conseqüència de procurement que no surt en cap deck de proveïdor:

Quan un proveïdor d'IA et presenta una capacitat nova, t'està ensenyant el rendiment sobre instantànies del passat: codi ja escrit, incidents ja resolts, contractes ja signats. El que no et pot ensenyar és el rendiment sobre el problema d'aquest trimestre, perquè el problema d'aquest trimestre encara no és al training set de ningú. Per tant:

• La distància entre el rendiment en demo i el rendiment en producció no és un error del proveïdor. És estructural.
• Aquesta distància la tanca el framer humà — que el proveïdor no et ven, perquè no és el seu producte.
• 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 el primer.

Si el teu business case d'IA d'aquest any no té una línia per a «plantilla sènior per mantenir els frames al dia», el business case és incomplet. La línia no és gran. Però no és zero, i, sense aquesta línia, el sistema va a la deriva.

Què posaria jo al roadmap aquest trimestre

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

1. Posa nom al rol de framer a l'organigrama. No cal crear cap càrrec nou. Però algú concret ha de tenir-ho escrit a la descripció del seu lloc de treball: «defineix els frames sota els quals operen els nostres sistemes d'IA, els revisa cada trimestre i és el punt de contacte amb compliance quan el frame canvia». Si ningú no ho té per escrit, tothom n'és una mica responsable i ningú no ho és bé.

2. Audita l'asimetria del training set. Per a cada sistema d'IA en producció, munta una taula: quin frame del proveïdor vas comprar, amb quines dades es va entrenar, quines decisions de negoci han canviat des de llavors. La distància entre aquestes dues columnes és el deute tècnic invisible. Probablement és més gran del que et penses.

3. Pressuposta la feina de després de l'automatització, no la d'abans. El cost del sistema no és el cost de desplegar-lo; és el cost de mantenir-lo rellevant mentre el frame es mou sota els seus peus. Un agent de revisió de PRs desplegat el gener del 2026 contra un monòlit en Python 3.11 no és el mateix sistema al desembre, quan ja has migrat a microserveis en Go. El frame ha canviat. Algú l'ha de tornar a definir. Aquest algú és una línia del pressupost, no un voluntari.

La línia que traço

Ho he dit públicament: defenso els LLMs i els sistemes agèntics en producció. Els despleguem, els facturem, els clients em paguen per fer-ho. El que veig — i el que l'assaig de Shipper articula millor que la majoria — és que el guany real de l'automatització no apareix a la línia «FTEs reduïts» del business case. Apareix com a «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 no retalla costos. Totes fan créixer la capacitat. Aquesta és la conversa honesta.

I darrere de tot plegat hi ha sempre algú que defineix el frame: què val la pena decidir, què val la pena obrir, què val la pena detectar. Aquest algú no el pot substituir cap model entrenat amb el passat, perquè la pregunta es mou més de pressa que el cicle d'entrenament. Si el teu programa d'IA d'aquest any no ha posat nom al framer — i no només al frame —, estàs construint un sistema que envellirà al ritme del proveïdor, no al ritme del teu negoci.

La feina interessant, com sempre, passa just al costat d'on tothom mira.

---

Fonts:

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

Estàs posant agents i LLMs en producció en un entorn regulat i no tens clar qui s'encarrega del rol de 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.