Dopo l'automazione: il framer, non il frame, è dove vive ancora il lavoro

Dan Shipper (Every) ha appena pubblicato After Automation, un saggio che vale la pena leggere per intero e che merita una risposta dalla trincea europea del DevOps e della piattaforma. La sua tesi centrale è che più automatizzi con l'IA, più lavoro umano esperto emerge — non meno. Every ha 30 dipendenti, ha automatizzato con Claude Code e agenti async tutto quello che ha potuto, e non ha eliminato nessuna posizione. Il lavoro ha cambiato forma, non è scomparso.

Sono d'accordo. Ma la parte del pezzo che merita più attenzione — e che nessuna roadmap di "trasformazione AI" che ho revisionato quest'anno nomina davvero — è la distinzione tra frame e framer. È la linea che separa i team che capiranno cosa stanno comprando nei prossimi due anni dai team che si sveglieranno una mattina con un dashboard in mano.

Il paradosso che i miei clienti vivono già senza saperlo

Shipper formula il paradosso in una frase netta: "Making expert work cheaper does not simply replace experts. It creates more situations where expert judgment is needed."

Traduco nel mio mondo. Quando mettiamo Claude Code, agenti di revisione di PR e pipeline a base di LLM in un team di piattaforma bancario o sanitario, non vedo il team rimpicciolirsi. Vedo:

• Più PR aperte per unità di tempo, perché il costo marginale di aprirne una scende.
• Più decisioni architetturali a settimana, perché ogni PR ora forza una decisione — su residenza dei dati, autorizzazioni, impatto regolatorio — che prima l'attrito assorbiva silenziosamente.
• Più tempo speso a decidere cosa vale la pena automatizzare, perché automatizzare il lavoro sbagliato adesso è economico e veloce — il che lo rende più pericoloso, non meno.

Il responsabile di piattaforma che pensava che l'IA gli avrebbe ridotto l'organico si ritrova con la domanda inversa: come scalo il giudizio senior necessario per filtrare il volume che gli agenti stanno producendo adesso? Quella domanda non è una critica all'IA. È la prova che funziona.

È lo stesso schema che ho letto nei numeri di ActionNex di Microsoft: 71% di precision, 53% di recall su incidenti reali di Azure. Il sistema funziona abbastanza bene da essere distribuibile e non abbastanza da essere autonomo. La conseguenza non è "meno SRE"; è SRE con una superficie decisionale più ampia perché ora rivedono raccomandazioni a una cadenza che prima non esisteva.

Il frame, il framer, e perché questa distinzione è l'unica che conta

La parte più sottoutilizzata del saggio di Shipper è questa:

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

Apro il discorso. Un benchmark misura le prestazioni del modello dentro un frame — un prompt preciso, un dataset preciso, una definizione precisa di "task completata". Quando un modello satura quel frame, l'industria sposta il frame: non misuriamo più "scrivere il codice" ma "decidere quando riscriverlo". Il nuovo frame torna a 60 e tutti ricominciamo a innervosirci a comando.

Shipper lo chiama Zeno's Paradox of AI. Io lo chiamo qualcosa di più operativo: il framer è il ruolo che sopravvive, ed è il ruolo che la maggior parte delle roadmap non nomina perché non sa come metterlo a budget.

Tre conseguenze pratiche che nessun pitch IA sentito quest'anno affronta direttamente:

1. Il frame del fornitore scade prima del contratto. Se compri una "piattaforma IA per le operations" sulla base di una capacità che oggi fa demo dentro un frame preciso, il frame si sarà spostato prima della fine del ciclo di budget. Quello che hai comprato non è la capacità — è la promessa che il fornitore saprà rifare il frame prima di te. Spesso non sa.

2. Il framer non è un ruolo job-title. È una funzione distribuita. In un team di piattaforma, il framer è chi decide quali workload vale la pena automatizzare questo trimestre, sotto quali vincoli di compliance, energia e rischio, con quale budget di errori accettabile. Non è il ML lead. Non è il VP Engineering da solo. È la composizione dei due con il regolatore in stanza — ed è il ruolo più sottostaffato che vedo oggi.

3. In settori regolati, il frame è un artefatto regolatorio. Questa è la parte che Shipper, scrivendo da una SaaS B2B, non ha bisogno di esplicitare. Ma per un cliente in banca, sanità o settore pubblico, il frame stesso — cosa conta come "decisione corretta", cosa conta come "PII", cosa conta come "incidente da segnalare" — lo definisce il regolatore. Per definizione, non si può delegare a un modello addestrato sul frame di ieri. Qui il framer non è opzionale. È il posto in cui vive la legittimità del sistema.

L'analogia del bambino piccolo — e perché in produzione è più scomoda di quanto sembri

Shipper paragona gli agenti attuali a un bambino piccolo: hanno agentività, vogliono delle cose, perseguono obiettivi autodiretti che nessuno ha dato loro. Gli LLM no. Eseguono frame che gli vengono dati.

In produzione enterprise quella distinzione è più scomoda di quanto sembri per due motivi:

• Vogliamo che gli agenti non abbiano agentività. Un agente con obiettivi emergenti in un ambiente regolato è un problema, non una promessa. La narrazione della Silicon Valley di una "AGI con una volontà propria" è esattamente l'opposto di quello che un CISO accetterà di firmare. Quindi il limite che Shipper nomina — "i modelli eseguono obiettivi di altri" — nel mio settore è una feature, non un difetto.

• Ma significa che il costo di definire bene l'obiettivo non scende, sale. Se l'agente non si autodirige, ogni autorizzazione, ogni vincolo, ogni criterio di successo lo deve mettere un umano — e la qualità del risultato è limitata dalla qualità del frame, non da quella del modello. Un team che scala gli agenti senza scalare la qualità dei propri frame sta fabbricando slop a velocità industriale con un certificato ISO graffettato di fianco.

Questa è la lettura che aggiungerei a Shipper: il "framer" non è solo un ruolo di prodotto o strategia. In ambienti regolati, il framer è il controllo peggio documentato dell'intero sistema sociotecnico, e gli auditor ci arriveranno prima del 2027.

L'asimmetria che nessun fornitore ti spiegherà

Shipper osserva che i modelli sanno solo sul lavoro che è già stato fatto. Gli umani sanno sul lavoro che va fatto ora. Quell'asimmetria ha una conseguenza procurement che non compare in nessun deck:

Quando un fornitore IA ti presenta una nuova capacità, ti sta mostrando le prestazioni su scatti del passato: codice già scritto, incidenti già risolti, contratti già firmati. Quello che non può dimostrarti è la prestazione sul problema di questo trimestre, perché quel problema non è ancora nel training set di nessuno. Quindi:

• Il divario tra prestazione da demo e prestazione in produzione non è un bug del fornitore. È strutturale.
• Quel divario lo chiude il framer umano — che il fornitore non ti vende, perché non è il suo prodotto.
• Costo reale del sistema = costo della licenza + costo del framer umano che lo mantiene rilevante. La maggior parte dei business case mette a budget solo il primo.

Se il tuo business case IA quest'anno non ha una riga per "headcount senior per tenere i frame aggiornati", il business case è incompleto. La riga non è grossa, ma non è zero, e senza di lei il sistema deriva.

Cosa metterei in roadmap questo trimestre

Per un team di piattaforma o ingegneria in un settore regolato, tre mosse concrete in risposta al saggio di Shipper:

1. Nomina il ruolo di framer nell'organigramma. Non serve creare un nuovo titolo. Ma qualcuno di concreto deve avere scritto nella propria job description: "definisce i frame sotto cui operano i nostri sistemi IA, li rivede trimestralmente, ed è il punto di contatto con compliance quando il frame cambia." Se nessuno lo possiede per iscritto, lo fa un po' tutti e nessuno bene.

2. Auditate l'asimmetria del training set. Per ogni sistema IA in produzione, una tabella: che frame del fornitore hai comprato, su quali dati è stato addestrato, quali decisioni di business sono cambiate da allora. La distanza tra quelle due colonne è il debito tecnico invisibile. Probabilmente più grande di quanto ti aspetti.

3. Metti a budget il lavoro post-automazione, non il pre-. Il costo del sistema non è il costo di distribuirlo; è il costo di mantenerlo rilevante mentre il frame si sposta sotto. Un agente di revisione PR distribuito a gennaio 2026 su una codebase Python 3.11 monolitica non è lo stesso sistema a dicembre quando sei migrato a microservizi Go. Il frame è cambiato. Qualcuno deve ridefinirlo. Quel "qualcuno" è una voce di budget, non un volontario.

La linea che traccio

Sono on the record come positivo su LLM e sistemi agentici in produzione. Li distribuiamo, li fatturiamo, i clienti mi pagano per farlo. Quello che vedo — e che il saggio di Shipper articola meglio della maggior parte — è che il vero guadagno di automazione non compare nella riga "FTE ridotti" del business case. Compare nelle righe "decisioni a settimana che prima non prendevamo", "PR a settimana che prima non aprivamo", "incidenti al mese che prima non rilevavamo". Nessuna di queste righe taglia costi — tutte aumentano capacità. È la conversazione onesta.

E dietro tutto, c'è sempre qualcuno che definisce il frame: cosa vale la pena decidere, cosa vale la pena aprire, cosa vale la pena rilevare. Quel qualcuno non è sostituibile da nessun modello addestrato sul passato, perché la domanda si muove più veloce del ciclo di addestramento. Se il tuo programma IA quest'anno non ha nominato il framer — non solo il frame — stai costruendo un sistema che invecchierà al ritmo del fornitore, non al ritmo del tuo business.

Il lavoro interessante, come sempre, succede appena di lato a dove tutti stanno guardando.

---

Fonti:

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

Stai mettendo agenti e LLM in produzione in un ambiente regolato e non sai chi è il framer nel tuo team? Parla con un CTO — ti aiutiamo a separare il frame dal lavoro del framer prima che lo faccia il regolatore per te.