Depois da automação: o framer, não o frame, é onde o trabalho continua a viver

Dan Shipper (Every) acabou de publicar After Automation, um ensaio que vale a pena ler na íntegra e que merece uma resposta a partir da trincheira europeia de DevOps e plataforma. A sua tese central é que quanto mais automatizas com IA, mais trabalho humano especializado aparece — não menos. A Every tem 30 empregados, automatizou com Claude Code e agentes async tudo o que conseguiu, e não eliminou nenhuma posição. O trabalho mudou de forma, não desapareceu.

Concordo. Mas a parte do artigo que merece mais atenção — e que nenhum roadmap de "transformação com IA" que revi este ano nomeia de facto — é a distinção entre o frame e o framer. É a linha que separa as equipas que vão perceber o que estão a comprar nos próximos dois anos das equipas que vão acordar uma manhã com um dashboard na mão.

O paradoxo que os meus clientes já vivem sem saber

Shipper formula o paradoxo numa frase limpa: "Making expert work cheaper does not simply replace experts. It creates more situations where expert judgment is needed."

Traduzo para o meu mundo. Quando metemos Claude Code, agentes de revisão de PR e pipelines com LLMs numa equipa de plataforma de banca ou saúde, não vejo a equipa encolher. Vejo:

• Mais PRs abertos por unidade de tempo, porque o custo marginal de abrir um desce.
• Mais decisões arquitetónicas por semana, porque cada PR força agora uma — sobre residência de dados, autorizações, impacto regulatório — que o atrito antes absorvia em silêncio.
• Mais tempo dedicado a definir o que vale a pena automatizar, porque automatizar o trabalho errado agora é barato e rápido — o que o torna mais perigoso, não menos.

O responsável de plataforma que pensava que a IA lhe ia reduzir headcount depara-se com a pergunta inversa: como escalo o juízo sénior necessário para filtrar o volume que os agentes estão a produzir agora? Essa pergunta não é uma crítica à IA. É a prova de que funciona.

É o mesmo padrão que li nos números do ActionNex da Microsoft: 71% de precision, 53% de recall sobre incidentes reais do Azure. O sistema funciona bem o suficiente para ser implantável e não o suficiente para ser autónomo. A consequência não é "menos SREs"; é SREs com uma superfície de decisão maior porque agora revêem recomendações a uma cadência que antes não existia.

O frame, o framer, e porque é que esta distinção é a única que importa

A parte mais subutilizada do ensaio de Shipper é esta:

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

Abro o assunto. Um benchmark mede o desempenho do modelo dentro de um frame — um prompt concreto, um dataset concreto, uma definição concreta de "tarefa completa". Quando um modelo satura esse frame, a indústria desloca o frame: deixamos de medir "escrever o código" e passamos a medir "decidir quando reescrevê-lo". O novo frame volta a marcar 60 e todos voltamos a ficar nervosos a comando.

Shipper chama-lhe Zeno's Paradox of AI. Eu chamo-lhe uma coisa mais operacional: o framer é o papel que sobrevive, e é o papel que a maioria dos roadmaps não nomeia porque não sabe como o orçamentar.

Três consequências práticas que nenhum pitch de IA que ouvi este ano aborda diretamente:

1. O frame do fornecedor expira antes do contrato. Se compras uma "plataforma de IA para operações" com base numa capacidade que hoje faz demo dentro de um frame concreto, o frame vai ter-se deslocado antes de o ciclo orçamental acabar. O que compraste não é a capacidade — é a promessa de que o fornecedor saberá reframear antes de ti. Muitas vezes não sabe.

2. O framer não é um cargo. É uma função distribuída. Numa equipa de plataforma, o framer é quem decide que workloads valem a pena ser automatizados este trimestre, sob que restrições de compliance, energia e risco, com que orçamento de erros aceitável. Não é o ML lead. Não é o VP de Engenharia sozinho. É a composição dos dois com o regulador na sala — e é o papel mais infraestaffado que vejo hoje.

3. Em setores regulados, o frame é um artefacto regulatório. Esta é a parte que Shipper, a escrever a partir de uma SaaS B2B, não precisa de explicitar. Mas para um cliente de banca, saúde ou setor público, o próprio frame — o que conta como "decisão correta", o que conta como "PII", o que conta como "incidente reportável" — é definido pelo regulador. Por definição, não pode ser delegado a um modelo treinado sobre o frame de ontem. O framer aqui não é opcional. É o lugar onde vive a legitimidade do sistema.

A analogia da criança pequena — e porque em produção é mais incómoda do que parece

Shipper compara os agentes atuais a uma criança pequena: têm agência, querem coisas, perseguem objetivos autodirigidos que ninguém lhes deu. Os LLMs não. Executam frames que lhes são dados.

Em produção enterprise essa distinção é mais incómoda do que parece por duas razões:

• Queremos que os agentes não tenham agência. Um agente com objetivos emergentes num ambiente regulado é um problema, não uma promessa. A narrativa de Silicon Valley de uma "AGI com vontade própria" é exatamente o oposto do que um CISO aceita assinar. Portanto, a limitação que Shipper nomeia — "os modelos executam objetivos alheios" — no meu setor é uma feature, não um defeito.

• Mas significa que o custo de definir bem o objetivo não desce, sobe. Se o agente não se autodirige, cada autorização, cada constraint, cada critério de sucesso tem de ser colocado por um humano — e a qualidade do resultado é limitada pela qualidade do frame, não pela do modelo. Uma equipa que escala agentes sem escalar a qualidade dos seus frames está a fabricar slop a velocidade industrial com um certificado ISO agrafado ao lado.

Esta é a leitura que eu acrescentaria a Shipper: o "framer" não é apenas um papel de produto ou estratégia. Em ambientes regulados, o framer é o controlo pior documentado do sistema sociotécnico completo, e os auditores vão chegar a ele antes de 2027.

A assimetria que nenhum fornecedor te vai explicar

Shipper observa que os modelos só sabem sobre trabalho que já foi feito. Os humanos sabem sobre trabalho que precisa de ser feito agora. Essa assimetria tem uma consequência de procurement que não aparece em nenhum deck:

Quando um fornecedor de IA te apresenta uma capacidade nova, está a mostrar-te o desempenho sobre capturas do passado: código já escrito, incidentes já resolvidos, contratos já assinados. O que não te pode demonstrar é o desempenho sobre o problema deste trimestre, porque esse problema ainda não está no training set de ninguém. Portanto:

• O fosso entre desempenho de demo e desempenho em produção não é um bug do fornecedor. É estrutural.
• Esse fosso é fechado pelo framer humano — que o fornecedor não te vende, porque não é o produto dele.
• Custo real do sistema = custo da licença + custo do framer humano que o mantém relevante. A maioria dos business cases só orçamenta o primeiro.

Se o teu business case de IA este ano não tem uma linha para "headcount sénior para manter os frames atualizados", o business case está incompleto. A linha não é grande. Mas não é zero, e sem ela o sistema vai à deriva.

O que poria no roadmap este trimestre

Para uma equipa de plataforma ou engenharia num setor regulado, três movimentos concretos em resposta ao ensaio de Shipper:

1. Nomeia o papel de framer no organigrama. Não é preciso criar um cargo novo. Mas alguém concreto tem de ter escrito na sua descrição de função: "define os frames sob os quais operam os nossos sistemas de IA, revê-os trimestralmente, e é o ponto de contacto com compliance quando o frame muda." Se ninguém o possui por escrito, fá-lo toda a gente um bocado e ninguém bem.

2. Auditem a assimetria do training set. Para cada sistema de IA em produção, uma tabela: que frame do fornecedor compraste, com que dados foi treinado, que decisões do teu negócio mudaram desde então. A distância entre essas duas colunas é a dívida técnica invisível. Provavelmente maior do que esperas.

3. Orçamenta o trabalho pós-automação, não o anterior. O custo do sistema não é o custo de o implantar; é o custo de o manter relevante enquanto o frame se desloca por baixo. Um agente de revisão de PR implantado em janeiro de 2026 sobre uma codebase Python 3.11 monolítica não é o mesmo sistema em dezembro quando já migraste para microsserviços Go. O frame mudou. Alguém tem de o redefinir. Esse "alguém" é uma rubrica de orçamento, não um voluntário.

A linha que traço

Estou on the record como positivo em relação aos LLMs e aos sistemas agênticos em produção. Implantamo-los, faturamo-los, os clientes pagam-me para o fazer. O que vejo — e o que o ensaio de Shipper articula melhor do que a maioria — é que o ganho real de automação não aparece na linha "FTEs reduzidos" do business case. Aparece na linha "decisões por semana que antes não tomávamos", "PRs por semana que antes não abríamos", "incidentes por mês que antes não detetávamos". Nenhuma dessas linhas corta custo — todas aumentam capacidade. Essa é a conversa honesta.

E por detrás de tudo há sempre alguém a definir o frame: o que vale a pena decidir, o que vale a pena abrir, o que vale a pena detetar. Esse alguém não é substituível por nenhum modelo treinado sobre o passado, porque a pergunta move-se mais depressa do que o ciclo de treino. Se o teu programa de IA este ano não tem o framer nomeado — e não apenas o frame — estás a construir um sistema que vai envelhecer ao ritmo do fornecedor, não ao do teu negócio.

O trabalho interessante, como sempre, passa-se mesmo ao lado de onde toda a gente está a olhar.

---

Fontes:

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

A pôr agentes e LLMs em produção num ambiente regulado e sem saber quem é o framer na tua equipa? Fala com um CTO — ajudamos-te a separar o frame do trabalho do framer antes de o regulador o fazer por ti.