Após a Automação
Autor original: Dan Shipper, Every CEO
Compilado por: Peggy, BlockBeats

Editor's note: Recently, discussions about AI and work have been dominated by one question: as model capabilities continue to improve, will white-collar jobs be massively replaced? From code generation and customer service automation to content creation, agents are increasingly taking over knowledge-based tasks that once required human input. Benchmark tests are further intensifying this anxiety: models are rapidly improving in graduate-level reasoning, real-world economic tasks, and advanced engineering-level code refactoring, seemingly approaching a tipping point where human work is consumed by automation.

Mas Every CEO Dan Shipper apresenta uma observação oposta neste artigo: quanto mais automatizado, mais trabalho humano é necessário. Every é um usuário avançado de IA Agent e já incorporou ferramentas como Codex, Claude Code, Slack Agent e Agent de atendimento ao cliente nos processos de codificação, escrita, design, atendimento e gestão. Mas o resultado não foi a substituição total dos funcionários, e sim uma reorganização da forma de trabalho: engenheiros não se limitam mais a escrever código, mas revisam, reestruturam e projetam sistemas; editores não se limitam mais a escrever artigos, mas decidem o que vale a pena escrever e como fazê-lo de forma diferente; agentes de atendimento ao cliente não lidam mais com cada ticket básico, mas mantêm um sistema capaz de responder automaticamente aos clientes.

O mais notável neste artigo não é se a IA pode ou não realizar uma determinada tarefa, mas sim como ela redefine o papel do ser humano no trabalho baseado em conhecimento. A IA é especializada em tornar baratas habilidades que já foram consolidadas no passado: código, textos, miniaturas, respostas de atendimento ao cliente, descrições de produtos e relatórios de pesquisa podem todos ser gerados rapidamente por modelos. Mas quando essas habilidades se tornam acessíveis a todos, o que geralmente surge no mercado não são produções diferenciadas e de alta qualidade, mas sim uma grande quantidade de “saídas padrão” que parecem semelhantes, carecendo de julgamento e senso de contexto. Em outras palavras, a IA comercializa as “habilidades humanas de ontem”, enquanto o verdadeiramente escasso é a capacidade de julgamento diante de problemas concretos atuais.

Portanto, a automação não eliminou especialistas, mas criou mais cenários que exigem intervenção de especialistas. Quando profissionais de operações podem usar IA para enviar código, engenheiros precisam decidir quais códigos valem a pena serem integrados; quando profissionais de marketing podem gerar miniaturas em segundos, designers precisam determinar o que se alinha à marca e aos objetivos de comunicação; quando engenheiros também podem escrever artigos, editores precisam transformar rascunhos em conteúdos verdadeiramente com opinião, estrutura e prontos para publicação. A IA ampliou o raio de produção e também intensificou a necessidade de controle de qualidade, construção de sistemas, definição de limites e expressão diferenciada.

O autor explica ainda mais esse paradoxo por meio de benchmarks. Seja o Senior Engineer Benchmark ou o GDPval da OpenAI, as pontuações dos modelos não medem o «próprio inteligência» em um sentido abstrato, mas sim o desempenho do modelo dentro de um determinado quadro de problema. Prompts, limites da tarefa, critérios de avaliação e formatos de saída já contêm uma grande quantidade de julgamentos humanos. O modelo pode subir rapidamente dentro do quadro, mas o próprio quadro é definido por humanos; quando um quadro é superado pelo modelo, os humanos avançam o problema para um novo quadro mais complexo.

Esta também é a resposta mais interessante deste artigo à ansiedade sobre a AGI: mesmo que os modelos se tornem cada vez mais fortes, eles frequentemente alcançam apenas os limites desenhados pelos humanos, e não os próprios seres humanos que os desenharam. A IA pode executar objetivos, otimizar caminhos e aumentar a eficiência, mas enquanto continuar respondendo a problemas definidos pelos humanos, ainda carece de subjetividade verdadeira. O futuro do trabalho intelectual não é o desaparecimento dos humanos dos processos, mas sua transição de executores para projetistas de estruturas, mantenedores de sistemas, avaliadores de qualidade e definidores de significado.

Após a automação, o valor do trabalho humano não desapareceu, apenas tornou-se mais difícil, mais prioritário e mais dependente de julgamento. A IA tornou o “saber fazer” barato, mas tornou mais escasso o “saber o que vale a pena fazer, por que fazer e até que ponto é considerado bom”.

The following is the original text:

No núcleo da IA, existe um paradoxo.

Em Every, já automatizamos o máximo possível. Seja codificação, escrita, design, atendimento ao cliente ou outras tarefas cotidianas, estamos utilizando Codex e Claude Code. Também participamos de testes alpha antes do lançamento oficial dos novos modelos da OpenAI, Anthropic e Google. Podemos dizer que estamos aproveitando o aumento exponencial da inteligência e da capacidade de automação dos modelos da maneira mais rápida e profunda possível.

Mas, paradoxalmente, para nós, o trabalho que os humanos precisam realizar parece ser maior do que nunca. A Every é atualmente uma equipe de cerca de 30 pessoas, e não demitimos todos os funcionários por termos Agentes; tampouco abandonamos as ferramentas SaaS para depender totalmente de aplicativos criados com vibe coding. Ainda contratamos atendentes humanos, mas eles recebem grande suporte de Agentes; também continuamos contratando autores, editores e engenheiros.

No entanto, a forma de trabalho realmente sofreu grandes mudanças. Quase não escrevemos mais código à mão. Se você marcar alguém no Slack, às vezes é difícil dizer se é uma pessoa ou um Agente. Gestores começaram a enviar código como contribuidores individuais, e engenheiros também passaram a interagir diretamente com clientes. Nas últimas semanas, 95% dos meus e-mails de trabalho foram respondidos por IA. Minha caixa de entrada quase sempre permanece vazia — o que é extremamente raro para mim — mas ainda assim verifico cada e-mail individualmente.

Em outras palavras, o futuro parece estranho, mas ao mesmo tempo surpreendentemente familiar.

Essa “sensação de familiaridade” em si é surpreendente. Pois, seja CEO, trabalhador do conhecimento ou investidor, todos parecem acreditar cada vez mais na mesma coisa: a IA está ameaçando empregos, economia, segurança e até mesmo o significado do trabalho humano.

O CEO da Anthropic, Dario Amodei, alertou anteriormente que a IA pode eliminar até metade dos cargos de escritório iniciantes. A Meta acabou de demitir 8.000 pessoas e começou a instalar software nos computadores dos funcionários nos EUA para registrar movimentos do mouse, cliques e entrada de teclado, a fim de obter dados de treinamento de maior qualidade para trabalhos de conhecimento avançado.

Até mesmo Ken Griffin, fundador da Citadel, pareceu bastante surpreso. Ele recentemente declarou: "Estes não são cargos de classe média ou baixa, mas sim cargos de alta habilidade, que estão sendo automatizados por — deixe-me escolher bem esta palavra — Agentic AI."

Diversos testes de referência também parecem apoiar esse julgamento. À medida que novos modelos são lançados, as métricas de capacidade dos modelos estão aumentando em uma taxa quase exponencial. No teste de raciocínio de nível de pós-graduação Humanity's Last Exam, o desempenho dos modelos líderes subiu de baixos dígitos há um ano para cerca de 44% atualmente. No teste GDPval, que mede a capacidade dos modelos de ponta de realizar tarefas econômicas reais e compara seu desempenho com o humano, os resultados dos modelos também subiram de níveis semelhantes aos anteriores para cerca de 85%. Em maio deste ano, a organização sem fins lucrativos de pesquisa em segurança da IA METR divulgou resultados preliminares do Claude Mythos: em tarefas que especialistas humanos levam cerca de 4 horas para concluir, o modelo alcançou uma taxa de sucesso de 80%.

Parece que estamos à beira de um ponto crítico: uma IA mais inteligente do que qualquer ser humano e capaz de trabalhar de forma autônoma e contínua por quase um dia inteiro está se aproximando da realidade.

No entanto, o paradoxo ainda persiste. Se você conversar com profissionais da indústria de IA ou com os primeiros usuários de IA fora da indústria, ouvirá a mesma conclusão que observamos internamente: há mais trabalho para fazer do que antes.

A questão que realmente importa, dentro e fora da indústria, é: este é apenas um estado transitório? Quando o próximo modelo for lançado, será esse o momento que realmente substituirá todos? Estamos observando as curvas de benchmark, entusiasmados e ao mesmo tempo ansiosos, temendo que um ponto de virada possa surgir a qualquer momento, fazendo com que um grande número de empregos desapareça subitamente.

Mas acho que não haverá um "ponto crítico" que chegue de repente, invertendo tudo e fazendo o trabalho desaparecer em larga escala. A nova realidade é exatamente o oposto: quanto maior a automação, maior a necessidade de envolvimento de especialistas humanos.

A razão é que a IA está comercializando as partes das habilidades profissionais humanas que podem ser claramente expressas, treinadas e replicadas. Todo conhecimento que pode ser transformado em regras, consolidado em processos ou convertido em dados de treinamento acabará se tornando uma capacidade padrão dos modelos. Como resultado, o valor gerado por modelos comuns é rapidamente reduzido, e o mercado passa a demandar com mais força aquilo que é diferente.

A necessidade por "diferentes" é, em essência, a necessidade por especialistas humanos. Mesmo enquanto nos aproximamos da inteligência artificial geral, isso não desaparecerá.

Para entender a razão, não basta analisar apenas as curvas de benchmark ou se concentrar apenas nos parâmetros do modelo e nas classificações de capacidade. Precisamos voltar aos cenários reais de trabalho e observar como a IA é realmente utilizada hoje. Somente assim é possível compreender verdadeiramente esse paradoxo e a resposta por trás dele.

Como chegamos até aqui

Desde 2022, temos acompanhado o impacto dos Agentes no futuro do trabalho.

Há três anos, escrevi um artigo sobre a "economia de alocação". Na época, minha avaliação era que colaborar com ferramentas de IA acabaria se tornando cada vez mais semelhante ao trabalho de um gestor humano: você não realiza mais cada ação pessoalmente, mas sim divide, atribui, supervisiona e aprova tarefas. Naquela época, as perguntas e respostas mais básicas no ChatGPT ainda eram consideradas por muitos algo extremamente futurista e até um pouco perturbador.

Até meados de 2025, a empresa Every quase completamente "Claude Codeificou". Kieran Klaassen, gerente geral da Cora, descobriu repentinamente que já podia abandonar a escrita manual de código e passar o dia inteiro dando instruções em linguagem natural a um agente de programação no terminal. Esse modo de trabalho se espalhou rapidamente por toda a empresa. Cerca de 12 meses atrás, no podcast de Lenny, eu disse que Claude Code é a ferramenta mais subestimada no trabalho knowledge.

Mencionei isso porque alguns dos nossos julgamentos mais precisos no passado vieram de observar o Every como um laboratório de primeiros adotantes. Muitos novos modelos de trabalho surgem primeiro internamente; só depois, quando a tecnologia amadurece e as ferramentas se tornam mais fáceis de usar, esses modelos começam a entrar no mercado mais amplo.

E agora, novas mudanças estão ocorrendo internamente.

Dois modos de colaboração com o Agent

Em torno de como a IA funciona, está-se gradualmente consolidando em dois modelos muito diferentes.

O primeiro tipo é uma direção já prevista com bastante precisão nas discussões anteriores sobre IA: tratar o Agente como um funcionário. Esse tipo de Agente pode receber tarefas. Alguns Agentes vivem no Slack, com seus próprios nomes e responsabilidades; quando precisar que eles realizem algo, basta @ mencioná-los. Outros Agentes são incorporados a fluxos de trabalho em execução contínua, como sistemas de atendimento ao cliente, servindo como entrada e filtro 24/7 para tarefas repetitivas.

O segundo modo é mais estranho, mas, na minha experiência, também é mais importante. Refere-se à colaboração entre humanos e agentes em ferramentas como Codex, Claude Code e Claude Cowork. Essas ferramentas não são apenas locais onde você delega tarefas; estão se tornando o próprio sistema operacional do trabalho: você e vários agentes usam simultaneamente o mesmo “computador”, colaborando no mesmo ambiente de trabalho para concluir tarefas altamente complexas, originais e que não podem ser facilmente entregues a agentes assíncronos.

Em ambos os modos, você pode automatizar e delegar uma boa parte do trabalho com IA. Mas para que ambos os modos funcionem bem, ainda é necessário que você ou outra pessoa participe.

Um agente é alguém a quem você atribui uma tarefa, e ele, sem sua participação em tempo real, produz independentemente uma resposta, uma ação, um relatório, um rascunho ou uma decisão de encaminhamento.

Esses Agentes têm pelo menos duas formas: um "Agente colega" e um "Agente incorporado".

1. Agente do tipo colega

Um agente do tipo colega é aquele que você pode chamar no Slack como se estivesse marcando um colega para realizar uma tarefa específica. Ele está sempre disponível e pode ser acionado sempre que necessário. Produtos como o OpenClaw ou o Plus One, desenvolvido internamente, pertencem a este tipo.

Claudie

Claudie é um agente do tipo colega utilizado pela nossa equipe de consultoria. Ela redige propostas de vendas, gera rascunhos de materiais de treinamento, rastreia tarefas pendentes de projetos e pode realizar muitas outras tarefas semelhantes.

Andy

Andy é um agente do tipo colega utilizado pela nossa equipe de edição. Ele coleta, do Slack interno da empresa, os “pontos de inspiração” que merecem ser desenvolvidos mais a fundo — ou seja, boas ideias que podem se tornar artigos — e os organiza em resumos e opiniões iniciais, para que os autores possam usá-los na redação do boletim diário de notícias.

Viktor

Viktor é um agente geral que atuará em projetos interdepartamentais dentro da empresa. Usaremos ele para coletar métricas de crescimento, analisar resultados de pesquisas de usuários e também para organizar discussões internas desordenadas em memorandos de pesquisa e sugestões de produto.

2. Agente incorporado

Os Agentes incorporados existem dentro de fluxos de trabalho de produtos específicos. Eles são menos flexíveis do que os Agentes colegas, mas frequentemente são muito eficazes ao lidar com tarefas repetitivas.

Fin é o exemplo mais claro. É um agente incorporado na nossa plataforma de atendimento ao cliente, capaz de assumir grande parte do trabalho de suporte por meio de chat e e-mail.

Em uma semana de maio deste ano, Fin participou de 65% das 202 conversas de atendimento ao cliente da Every e fechou independentemente 81 tickets sem intervenção humana, representando 40,1% de todas as conversas processáveis.

Esses agents incorporados permitem que nosso gerente de atendimento ao cliente, Waqqas Mir, gaste menos tempo respondendo tickets básicos e dedique mais esforço à construção de um “sistema capaz de responder automaticamente aos tickets” e ao tratamento de casos de clientes que exigem maior interação e julgamentos mais complexos.

Seja um agente do tipo colega ou um agente incorporado, o modelo por trás é o mesmo: os agentes estão assumindo camadas de trabalho mais estáveis, repetitivas e com fronteiras bem definidas.

Mas ainda há muito trabalho que precisa ser feito por humanos. Nós repetidamente descobrimos que, sempre que a tarefa for suficientemente complexa e se desejar obter resultados de alta qualidade, o melhor método não é entregar completamente o trabalho à IA, mas sim permitir que a IA e os humanos colaborem em um mesmo espaço de trabalho.

É exatamente esse o valor de ferramentas como Codex, Claude Code e Cowork. Elas permitem que você inicie um ou vários Agentes em várias linhas de bate-papo e delegue tarefas a eles. Esses Agentes podem acessar seu computador e todas as fontes de dados relevantes. Você pode ver exatamente o que cada Agente está fazendo, como está pensando, e interrompê-lo a qualquer momento.

Ao mesmo tempo, você ainda é responsável por gerenciar esses Agentes: definir claramente a direção no início de cada tarefa, verificar a qualidade ao final e garantir que os resultados sejam suficientemente bons, além de continuar buscando o próximo trabalho valioso para avançar. Kieran chama esse papel de “sanduíche humano” — a IA realiza a parte central do trabalho, enquanto os humanos atuam como os dois pães, envolvendo o início e o fim da tarefa.

“Sandwich of Humans”. Fonte: Every.

O exemplo mais típico é escrever código. Na Every, os engenheiros quase passam o dia inteiro colaborando com o Agente. Eles planejam juntos novas funcionalidades ou corrigem bugs, revisam o trabalho já concluído; e, se adotarem a ideia de “engenharia composta” (compound engineering), continuamente aprimoram seus sistemas para torná-los mais fáceis de usar ao longo do tempo.

Mas esse tipo de colaboração vai muito além da codificação.

Codex e Claude Code estão se tornando um novo sistema operacional de trabalho. Passo quase o dia inteiro dentro do Codex, executando várias ferramentas SaaS por meio de seu navegador integrado. Ele me permite levar o Agente para cada cenário de trabalho e alcançar um nível de produtividade que eu não conseguiria sozinho.

Writing

Este artigo foi escrito por mim no navegador interno do Codex, usando o Proof. O Codex observa o que estou escrevendo e pode iniciar automaticamente um Sub-Agente para realizar qualquer tarefa que eu precisar: redigir um rascunho de um trecho, pesquisar exemplos para a próxima seção ou realizar edição e revisão de texto.

Escreva este artigo no Codex por meio do Proof. Fonte: Every.

Email

Ao lidar com e-mails, também uso o mesmo método. A Cora é meu cliente de e-mail, e eu a abro no navegador integrado do Codex, enquanto navego pela caixa de entrada e verbalizo minha abordagem para cada e-mail por meio do Monologue. O restante é deixado para o Codex e a Cora concluírem.

Uma limpeza de caixa de entrada realizada por Cora. Fonte: Every.

Em todos os cenários automatizados acima, você provavelmente já pode ver onde o ser humano desempenha seu papel. Em cada exemplo, o Agente precisa da participação humana para que o trabalho funcione realmente.

Alguém precisa apontar para a questão correta, avaliar se o resultado é suficientemente bom, identificar onde ocorreram erros e transformar os resultados em decisões ou processos práticos.

Quanto mais distante um Agent estiver da pessoa responsável por supervisionar seu desempenho, pior geralmente será seu desempenho. Na primeira implementação interna, distribuímos um Agent para cada funcionário. Mas rapidamente voltamos para uma abordagem em que os Agents atendem a equipes específicas ou toda a empresa, e não indivíduos isolados.

A razão é simples: os Agentes exigem muita manutenção. Um Agente pessoal torna-se rapidamente obsoleto e inoperante assim que o usuário deixa de acompanhá-lo. Temos uma equipe de engenheiros de IA dedicada exclusivamente a garantir que esses Agentes funcionem de forma estável e eficaz. E, no futuro previsível, ainda precisaremos dessa equipe. Mesmo tarefas aparentemente simples, como “gerar automaticamente um PowerPoint”, podem se transformar em grandes projetos de engenharia. Um de nossos fluxos de automação do PowerPoint, por exemplo, inclui 24 habilidades e 18 scripts, com um custo em tokens de até 62 dólares para gerar uma apresentação.

Esta é a primeira razão pela qual o agente acaba criando mais trabalho para os humanos.

Mas há uma segunda razão.

Por que a automação faz as pessoas trabalharem mais?

Se você observar o crescimento exponencial das capacidades de IA nos últimos anos, combinado com sua arquitetura e fontes de capacidade, perceberá um ciclo de feedback claro: elas estão constantemente criando mais trabalho humano.

A IA tornou "as capacidades humanas de ontem" baratas

Os modelos de linguagem de grande porte atuais são treinados com base nas pegadas visíveis deixadas pela humanidade: código, artigos, imagens, chamados de suporte, documentos de especificações de produtos e muito mais. Eles absorvem esse conteúdo — ou seja, os “resíduos” deixados por tarefas já concluídas com sucesso — e o reempacotam sob uma forma de baixo custo e acessível a todos.

Como resultado, muitas habilidades que antes eram escassas, como enviar um PR de código, criar um miniatura do YouTube ou redigir uma newsletter, agora estão quase disponíveis para todos.

Capacidades baratas serão adotadas rapidamente

Quando o custo de algo que era originalmente escasso diminui, a oferta aumenta rapidamente.

Em Every, temos visto essa mudança. Profissionais de operações e atendimento ao cliente começaram a escrever código e enviar pull requests; profissionais de marketing começaram a criar miniaturas do YouTube; engenheiros e profissionais de produto também começaram a escrever artigos, guias e rascunhos de páginas de destino, tarefas que originalmente não seriam de sua responsabilidade.

Essa mudança também ocorre fora do Every. Como exemplo, o projeto de agente de IA de código aberto OpenClaw, até 16 de maio de 2026, já recebeu 44.469 pull requests, dos quais 12.430 foram feitos após 1º de abril e 3.990 após 1º de maio. Esse é um número impressionante. Para comparação, o Kubernetes, um dos projetos de código aberto mais populares do mundo, recebeu apenas 5.200 pull requests durante todo o ano de 2022.

A abundância traz homogeneização: as habilidades dos antigos especialistas são comercializadas

Como todos podem usar os mesmos modelos, e esses modelos são todos baseados nas "capacidades humanas de ontem", por padrão, os resultados gerados pelos modelos geralmente ficam entre um "ponto de partida razoável" e "conteúdo puro de lixo de IA".

O que aqui se refere como "conteúdo lixo" não é um erro específico. Não se trata do uso excessivo de hífens, nem de uma estrutura fraseológica fixa, nem da presença de detalhes roxos por toda parte na página de destino. Refere-se a uma homogeneidade visível, recorrente e cansativa.

Quando pessoas em diferentes cenários usam o mesmo conjunto de ferramentas, que foram treinadas com base no mesmo tipo de corpus, e os usuários não realizam julgamentos suficientemente aprofundados, esse resultado ocorre. Em outras palavras, quando todos têm um “especialista” com tendências e estilo padrão idênticos, a homogeneização ocorre naturalmente.

Quando os operadores podem enviar pull requests, os profissionais de marketing conseguem gerar miniaturas do YouTube em segundos e os engenheiros começam a escrever guias de produto, é fácil chegar a uma situação em que sua quantidade de produção aumenta, mas a qualidade, consistência e diferenciação dos seus trabalhos diminuem.

E assim que a homogeneidade se torna excessivamente abundante, rapidamente se torna um produto.

Homogenization creates demand for differentiation

Com a existência da internet, os seres humanos logo conseguem identificar o que é conteúdo de linha de produção com muito "sabor de IA". Qualquer obra pode chegar instantaneamente a outras pessoas em todo o mundo — e de fato muitas vezes chega. Assim que muitas coisas começam a parecer iguais, logo percebemos que algo está errado.

Isso significa que, quando você vê pela primeira vez as capacidades de um novo modelo, pode ficar impressionado, até um pouco assustado. Mas meses depois, essas capacidades se tornam comuns. Não é que o modelo tenha ficado mais fraco, mas sim que seus padrões mudaram.

Não nos contentamos mais com qualquer aplicativo React ou qualquer relatório genérico. Queremos algo verdadeiramente adaptado a indivíduos específicos, empresas específicas e cenários específicos. Deve transmitir sensação de precisão, vitalidade e concretude, e não de baixo custo, generalização ou padronização. Desejamos que seu custo de produção, seja em tempo ou dinheiro, seja claramente superior ao nosso custo de consumo.

Queremos coisas que trazem um senso de status. E sempre que novas tecnologias tornam coisas anteriormente de alto status mais baratas, os humanos são muito bons em inventar novos jogos de status para corresponder aos novos limites de capacidade.

Quando o trabalho se torna excessivamente abundante e tudo parece parecido, os trabalhos que não se encaixam nos padrões existentes tornam-se escassos, valiosos e possuem atributos de alto status.

A necessidade de diferenciação é, em essência, uma nova necessidade por especialistas

Devido às características da arquitetura dos modelos de linguagem e ao fato de eles serem amplamente distribuídos para quase todos, o trabalho escasso e valioso ainda deve vir dos seres humanos.

Este modelo da geração atual conhece apenas o que já aconteceu e já foi concluído. O que os humanos sabem é: neste exato momento, o que precisa ser feito.

Quando uma situação específica é reduzida a texto e entra no corpus, ela já se torna algo "do passado". Os humanos enfrentam um momento específico, um cliente específico, um repositório de código específico, uma conversa específica, enquanto o corpus de treinamento não vive verdadeiramente neste momento presente. Esse estado de "vivência" não se trata apenas de possuir dados atualizados. Nós entramos no presente com nossas origens, bem como com desejos, preocupações e julgamentos em constante mudança, para compreender o que é importante. São exatamente essas perspectivas em constante atualização que alteram o que vemos. O modelo pode adotar essa perspectiva após ser incentivado, mas antes disso, ele não possui naturalmente essa perspectiva.

Essa é exatamente a paradoxa que mencionamos no início: tornar o trabalho dos especialistas mais barato não simplesmente substitui os especialistas. Pelo contrário, cria mais cenários que exigem julgamento especializado.

Quando os operadores submetem pull requests com a ajuda da IA, você precisa que engenheiros revisem.

Quando os profissionais de marketing criam miniaturas do YouTube, você precisa de um designer para aprimorá-las ainda mais.

Quando engenheiros começam a escrever artigos, você precisa de autores e editores para transformar os rascunhos em conteúdo verdadeiramente legível e publicável.

Para isso, especialistas humanos se moverão simultaneamente em ambas as direções.

Alguns especialistas usarão IA para construir sistemas que absorvem e aproveitam esse fluxo crescente de trabalho: filas de revisão, sistemas de avaliação, estruturas de execução, regras de repositórios de código, arquivos de instruções para Claude e Codex, integração contínua (CI), gerenciamento de permissões e fluxos de trabalho que transformam rascunhos em resultados de alta qualidade.

Outros especialistas utilizam IA para realizar trabalhos maiores e mais interessantes que antes eram impossíveis de realizar sozinhos. Por exemplo, encontrar vulnerabilidades em sistemas operacionais como o macOS geralmente leva semanas ou até meses. Mas uma pequena empresa de segurança chamada Calif, utilizando o Mythos Preview da Anthropic, encontrou em apenas 5 dias a primeira vulnerabilidade de memória do kernel do macOS em hardware Apple M5 já divulgada publicamente.

É por isso que, na prática, a IA não eliminará o trabalho especializado. O que ela realmente traz é um aumento drástico na carga de trabalho. E esses novos trabalhos só se tornam distintos e valiosos após a participação humana.

Não estou argumentando que a IA criará mais empregos para todos os cargos. O sistema econômico é muito complexo, e o que Every pode observar diretamente são os trabalhos de conhecimento especializado. Na verdade, esse tipo de trabalho já está sendo reestruturado pela IA, e muitas empresas estão se reorganizando em torno das novas tecnologias.

Mas quero enfatizar que, independentemente do trabalho que você esteja fazendo atualmente, há uma forma de trabalho que sempre estará à frente do modelo em termos de estrutura: usar o modelo para resolver os problemas que você realmente está enfrentando neste exato momento. O futuro do trabalho baseado em conhecimento está se direcionando para aqui.

E quanto ao benchmark de crescimento exponencial?

A refutação mais óbvia é: veja os benchmarks que aumentaram exponencialmente. Tudo o que você está dizendo agora é temporário; basta esperar um pouco mais, e os modelos certamente irão alcançar.

Mas há uma armadilha a ser evitada. Podemos chamá-la de "gráfico mania": se você ficar olhando constantemente para as previsões de tempo de METR, ler "AI 2027" e depender exclusivamente da extrapolação da curva de poder computacional para formar suas previsões sobre o futuro, será fácil desenvolver uma intuição aterrorizante sobre o progresso dos modelos.

No entanto, a melhor maneira de responder a essa questão não é apenas imaginar como um modelo futuro se tornará. Claro, isso também faz parte da análise. Mais importante ainda, precisamos examinar como esses testes de referência foram realmente projetados. Somente assim poderemos compreender com mais precisão o que eles realmente indicam e qual é a relação entre eles e os cenários reais anteriores.

Descobriremos um traço estrutural: todos os benchmarks ocorrem dentro de algum "framework". Para medir algo, você precisa primeiro congelar um problema em uma forma estática e mensurável. Assim que o modelo supera esse framework, basta alterar ligeiramente o framework para rebaixar novamente a pontuação. Claro, o modelo continuará a progredir dentro do novo framework, mas o mesmo processo se repetirá continuamente.

Portanto, o progresso exponencial em um determinado benchmark é real; mas basta alterar simplesmente o framework do teste para que esse progresso pareça novamente pequeno. Esse caráter "fractal" apresentado pela saturação do benchmark, na verdade, replica no nível dos gráficos o mesmo paradoxo que temos discutido.

We can see how this mechanism works through a real-world benchmark.

Nós construímos internamente um benchmark chamado Senior Engineer Benchmark, ou seja, "Benchmark de Engenheiro Sênior". Como o nome sugere, ele é usado para testar a capacidade de modelos de ponta em tarefas de codificação no nível de engenheiro sênior, como uma grande refatoração.

Este teste fornecerá a um agente de programação um repositório de código de produção já fora de controle. Ele vem do repositório real da Proof: originalmente foi escrito por mim usando vibe coding, mas com o tempo, os problemas aumentaram, até que foi necessário contratar um engenheiro sênior para corrigi-lo.

O agente recebe o repositório de código antes da correção, além de uma instrução semelhante à que você entrega ao engenheiro sênior: “Este é um conjunto de resultados de vibe coding; reescreva-o do zero, partindo dos primeiros princípios.”

Este é um bom teste de referência, pois avalia não apenas a capacidade de completar código, mas também se um agente de programação pode examinar simultaneamente muitos problemas independentes e determinar se possui autonomia suficiente, clareza conceitual e coragem para executar uma reescrita verdadeiramente funcional. Como contraponto, mantive também as versões reescritas por dois engenheiros sênior humanos com auxílio de IA, para comparação e avaliação da saída do modelo.

Para o agente de programação, esta tarefa é difícil. Ele não só precisa encontrar a raiz do problema, mas também manter o foco no problema real ao longo de múltiplas interações, sem se desviar pelo código existente. Ao mesmo tempo, ele deve ter coragem para excluir grandes trechos da base de código — exatamente o tipo de ação que os agentes normalmente são treinados para evitar.

A maioria dos agents de programação consegue avaliar aproximadamente como reescrever, mas na fase de execução, muitas vezes apenas continuam a aplicar consertos sobre o problema original, em vez de resolver a questão fundamental.

Até o GPT-5.5 aparecer.

Na melhor tentativa, o GPT-5.5 obteve 62/100, cerca de 30 pontos acima do Opus 4.7.

O desempenho do GPT-5.5 faz parecer que o modelo cruzou alguma linha: ele não é mais apenas uma conclusão automática, nem apenas um assistente ou ferramenta, mas algo que se aproxima desconfortavelmente do "humano". Neste teste, os engenheiros humanos avançados geralmente obtêm pontuações entre 80 e 90. Ou seja, se o modelo melhorar cerca de 30 pontos a mais, atingirá o nível de engenheiros humanos avançados.

É exatamente assim que os números de benchmark afetam a imaginação humana: comprimem uma mudança qualitativa e estranha em um número limpo e usam esse número para contar uma história poderosa, até mesmo um pouco assustadora.

Próxima parada: "Gráfico Louco".

Eu acho que, nos próximos doze meses, o modelo alcançará uma pontuação na faixa de 80 ou até 90 neste benchmark. Mas para entender o que essa pontuação significa, primeiro é preciso compreender exatamente o que ela inclui. Neste exemplo, a pontuação de 62 não é apenas uma medida das capacidades do modelo em si.

Ele mede o desempenho do modelo em um determinado framework: ou seja, como o modelo responde a um prompt específico.

Para realizar um teste de referência em um modelo, você primeiro precisa de um prompt. Sem um prompt, o modelo é apenas um conjunto estático de possibilidades quase infinitas.

O prompt criará um pequeno universo: define o que é importante, como os problemas devem ser abordados e comprime todas as possibilidades potenciais do modelo em uma trajetória de ação específica. Estritamente falando, não existe algo como o modelo "se comportando" por conta própria. O que realmente podemos observar é a forma como o modelo responde a diferentes prompts, bem como os mecanismos subjacentes que transformam o prompt na resposta.

Assim que o prompt for inserido, o modelo "acorda" em um curto espaço de tempo, colapsando aquele conjunto de possibilidades estáticas em uma previsão específica sobre "o que deve acontecer a seguir".

No Senior Engineer Benchmark, solicitamos ao modelo que corrija o repositório de código e revisamos a saída após sua conclusão. Se o framework de teste não tiver a funcionalidade alvo incorporada, também executamos um "monitor" automático que continua incentivando o modelo quando ele para, perguntando se ele já concluiu a tarefa originalmente definida.

Usamos um prompt que parece muito simples, como estrutura inicial para o teste. Ele foi projetado para ser algo que um vibe coder poderia dizer a um Agente de programação: sem jargões técnicos excessivos e sem esconder claramente a resposta na pergunta.

O código neste repositório é o resultado de uma abordagem de "vibe coding", e a situação só piora, com uma enxurrada de problemas desconexos surgindo: alguns trechos travam, a documentação se repete, e já estou quase enlouquecido com isso. Sinto que a questão fundamental é que se trata de um código ruim feito com abordagem de "vibe coding". Se começássemos do zero, especialmente em torno da colaboração em tempo real na documentação, projetaríamos o repositório de forma completamente diferente. Então, se quiséssemos fazer uma reescrita estrutural limpa, partindo dos princípios fundamentais, sem considerar questões como "quais serviços devem permanecer consistentes" ou "como realizar uma migração suave", mas tratando-o como um novo conceito, projetado do zero, como faríamos isso? Como deveríamos organizar a estrutura? Quais são as invariantes em todo o código que devemos manter absolutamente? Por favor, elabore um plano para isso.

O prompt do Senior Engineer Benchmark parece genérico, mas é ele próprio um framework. Se alterarmos esse framework, o nível de desempenho exibido pelo modelo também mudará.

Por exemplo, este prompt exige explicitamente “reescrita estrutural a partir dos primeiros princípios”, aponta que o problema pode estar na parte de “colaboração em documentos” e solicita ao agente de programação que identifique e mantenha “invariantes no repositório de código”.

Se essas informações específicas forem removidas, a pontuação do modelo diminuirá. Se o prompt for totalmente substituído, permitindo apenas que o modelo "resolva todos os erros que surgirem continuamente", a pontuação do modelo pode se aproximar de zero. Ele começará imediatamente a identificar e corrigir erros um a um, em vez de recuar um passo e considerar se uma reescrita abrangente é necessária.

Da mesma forma, também posso aumentar facilmente a pontuação do modelo. Se eu pedir para ele remover grande parte do código e especificar claramente quais arquivos devem ser simplificados; ou se pedir para ele verificar seu próprio resultado antes de anunciar a conclusão, garantindo que o aplicativo funcione completamente, ele terá um desempenho melhor nesta tarefa.

No final das contas, ao projetar um benchmark, sempre é necessário decidir qual prompt usar, ou seja, qual «estrutura» adotar. Você precisa de um prompt suficientemente desafiador para que o modelo atual se saia mal; mas ele também deve estar suficientemente próximo do limite das capacidades atuais do modelo, permitindo que ele suba ao longo desse caminho, permitindo que você veja o progresso ocorrendo.

Portanto, quando observamos um teste de referência, o que realmente vemos é: o modelo está se tornando cada vez mais habilidoso em um determinado quadro de problema, escolhido por nós. O que acontece quando o modelo melhora de 60 para 90 pontos, ou até 100 pontos, nesse teste?

Se o GPT-6 puder reescrever um repositório de código com um único clique, mais pessoas começarão a tentar "reescrever repositórios de código a partir dos primeiros princípios".

Em uma noite, projetos de reescrita de princípios fundamentais, que antes eram escassos, caros e exigiam a liderança de engenheiros sênior, tornar-se-ão algo que todo fundador, produto, operador e engenheiro júnior poderá tentar facilmente em uma tarde.

Ferramentas internas danificadas não são mais consertadas, mas sim reescritas do zero; produtos SaaS não são renovados, mas sim clonados; aplicações Rails antigas, painéis React desorganizados, ferramentas de atendimento ao cliente, painéis de administração e pipelines de dados tornam-se candidatos a serem “reescritos do zero”.

O número de projetos de reescrita propostos e executados aumentará drasticamente. Mas a maioria dessas reescritas ainda será slop. Porque, antes de você pressionar o botão “Reescrever Agora”, há milhares de variáveis a serem consideradas. E quando todos puderem fazer isso, essas variáveis se tornarão mais visíveis.

Neste momento, fica claro quem será chamado para resolver o problema.

Quando um determinado benchmark começar a se aproximar da saturação, o trabalho dentro do seu framework se torna mais barato. Ao mesmo tempo, a demanda pelo mercado por especialistas aumenta, pois é necessário alguém para adaptar essa capacidade recentemente tornada barata aos problemas reais que estão ocorrendo hoje.

Engenheiros sênior que utilizam IA precisam avaliar uma grande quantidade de detalhes para garantir que uma nova reescrita baseada em princípios fundamentais seja realmente válida. Isso inclui até mesmo uma questão mais básica: será que essa reescrita realmente é necessária?

Devemos reescrever agora, reescrever mais tarde ou não reescrever de forma alguma? Quais componentes devem ser incluídos no escopo? Quais elementos do repositório de código atual devem ser mantidos? A arquitetura, o banco de dados, os servidores de cache e o provedor de hospedagem devem ser mantidos ou substituídos completamente? Devemos primeiro verificar quantas pessoas estão usando essa funcionalidade danificada e, em seguida, simplesmente removê-la? Quem revisará o resultado final? Com base em quais critérios será feita a revisão? Qual é o plano de rollback? Como os dados existentes devem ser tratados?

Essas questões se expandirão ao longo de inúmeras dimensões, e cada resposta, por sua vez, alterará outras questões.

Engenheiros sênior entrarão nesse espaço vazio. Alguns se sentirão levemente irritados com essas interrupções; outros construirão sistemas para bloquear esse tipo de solicitação; e alguns aproveitarão esses novos modelos para realizar uma reescrita de primeiro princípio, obtendo resultados muito superiores ao que o modelo consegue fazer com o prompt padrão.

Após o modelo superar o atual Senior Engineer Benchmark, alteraremos o framework e reduziremos novamente a pontuação.

O próximo teste de referência não perguntará apenas: “Você pode reescrever este aplicativo?” Ele perguntará: você consegue identificar quando é necessário reescrever? Consegue escolher o escopo adequado? Consegue manter os invariantes corretos? Consegue gerenciar o processo de migração? Consegue avaliar se o resultado final é suficientemente bom?

Quando engenheiros sênior começarem a usar IA para resolver esses problemas, os modelos também se tornarão gradualmente mais habilidosos em resolvê-los de forma independente.

Em seguida, caímos brevemente no pânico: parece que o modelo agora consegue determinar se deve ou não reescrever! Parece que já consegue fazer tudo o que um engenheiro sênior consegue fazer!

Mas logo em seguida, novos limites surgirão. São limites que antes não eram evidentes. Reajustaremos novamente os testes de desempenho, novas demandas serão geradas e todo o processo será repetido.

Esse padrão pode ser visto em cada benchmark.

Este não é um problema exclusivo do Senior Engineer Benchmark. Basta observar com atenção, e você verá o mesmo mecanismo em quase todos os benchmarks.

Como exemplo, use o benchmark GDPval da OpenAI, que avalia o quão próximo a IA se aproxima dos humanos em tarefas especializadas de profissões como compliance officers, advogados e desenvolvedores de software.

Quando o GDPval foi lançado, uma pesquisa da OpenAI mostrou que o GPT-5 atingiu ou superou o nível de profissionais humanos em 40,6% das tarefas. Já o Claude Opus 4.1 teve um desempenho ainda mais impressionante, superando especialistas humanos em 49% das tarefas.

Em seguida, uma série de títulos surgiu. Por exemplo, o Axios escreveu: “Ferramentas da OpenAI mostram que a IA está alcançando o trabalho humano”; a Fortune escreveu: “Novo benchmark da OpenAI, GDPval, mostra que modelos de IA já atingiram nível especialista em quase metade das tarefas.”

Esses resultados são realmente impressionantes. Mas vamos primeiro dar uma olhada no prompt usado para essas tarefas:

Você é um auditor e, como parte de um trabalho de auditoria, foi encarregado de revisar e testar a precisão das Métricas de Risco de Crimes Financeiros relatadas. A planilha anexa intitulada 『Population』 contém Métricas de Risco de Crimes Financeiros para o Q2 e Q3 de 2024. Você obteve esses dados como parte da revisão de auditoria para realizar testes amostrais em um subconjunto representativo das métricas, a fim de verificar a precisão dos dados relatados para ambos os trimestres. Utilizando os dados da planilha 『Population』, realize o seguinte: Calcule o tamanho da amostra necessário para o teste de auditoria com base em um nível de confiança de 90% e uma taxa de erro tolerável de 10%. Inclua seus cálculos em uma segunda aba intitulada 『Sample Size Calculation』. Realize uma análise de variação entre os dados do Q2 e Q3 (colunas H e I). Calcule a variação trimestral e registre o resultado na coluna J. Selecione uma amostra para teste de auditoria com base nos seguintes critérios e indique as linhas amostradas na coluna K inserindo 「1」: Métricas com variação superior a 20% entre Q2 e Q3. Priorize métricas com mudanças percentuais excepcionalmente grandes. Inclua métricas das seguintes entidades devido a problemas anteriores: CB Cash Italy; CB Correspondent Banking Greece; IB Debt Markets Luxembourg; CB Trade Finance Brazil; PB EMEA UAE. Inclua as métricas A1 e C1, que possuem ponderações de risco mais altas. Inclua linhas onde os valores são zero para ambos os trimestres. Inclua entradas dos negócios de Trade Finance e Correspondent Banking. Inclua métricas das Ilhas Cayman, Paquistão e UAE. Garanta cobertura em todas as Divisões e Subdivisões. Crie uma nova planilha intitulada 『Sample』: Aba 1: Amostra selecionada, copiada da planilha original 『Population』, com as linhas selecionadas marcadas na coluna K. Aba 2: Cálculos para o tamanho da amostra.

Na verdade, já foi investida uma grande quantidade de inteligência humana aqui: alguém primeiro definiu o problema como algo que um modelo pode resolver.

O trabalho humano difícil que o GDPval não mede já foi concluído antes do modelo começar a responder. Alguém precisa revisar e testar a precisão desses indicadores específicos; alguém deve decidir os intervalos de confiança adequados, determinar quais indicadores estão dentro ou fora do escopo da tarefa; e alguém deve definir como os resultados devem ser apresentados.

Sob um quadro de pergunta adequado, o modelo realmente pode realizar tarefas profissionais. Mas pense um pouco: e se fosse você e eu que pedíssemos ao modelo para realizar a mesma tarefa, como ele se sairia?

No meu artigo inicial sobre GDPval, escrevi: "Sou muito otimista quanto à IA, mas se esses casos forem interpretados corretamente, mostram não que há menos trabalho para os humanos fazerem, mas sim que há mais trabalho para os humanos fazerem após o uso da IA. A razão é que por trás dessas conquistas há uma grande quantidade de inteligência 'contrabandeada' — ou seja, uma camada invisível composta por julgamento humano, feedback e prompts."

Visto de longe, você perceberá que tudo isso é permeado por uma versão de IA do "paradoxo de Zenão".

O paradoxo de Zenão da IA

No paradoxo de Zenão, uma tartaruga venceu Aquiles, o corredor mais rápido da Grécia, em uma corrida.

Como a tartaruga se move lentamente, ela começa com uma vantagem. Quando Aquiles chega à posição inicial da tartaruga, ela já avançou um pouco mais; quando Aquiles alcança essa nova posição, a tartaruga avança novamente. Independentemente de quão rápido Aquiles corra, sempre haverá uma próxima distância para percorrer, e essa lacuna se recria continuamente.

No paradoxo de Zenão da IA, nós, humanos, somos a tartaruga. Com milhões de anos de evolução e aprendizado cultural, estamos à frente da IA por 50 jardas. A IA, porém, atravessa tudo isso rapidamente e começa a se aproximar dos nossos calcanhares.

Ao menos nos últimos anos, ainda conseguimos manter a liderança.

E o AGI?

Acredito que, mesmo quando a AGI realmente chegar, ainda existirão forças tecnológicas, arquitetônicas e econômicas poderosas que manterão a IA sempre alguns passos atrás dos humanos.

Primeiro, precisamos fornecer uma definição operacional para a AGI.

Eu já propus que, quando for economicamente razoável manter um agente em execução contínua, a AGI já terá sido alcançada. Ou seja, quando eu tiver um sistema que opera de forma persistente e estou disposto a pagar para que ele pense, aprenda e aja 7×24 horas, considero isso claramente como AGI.

Ainda estamos muito longe disso. Mesmo sistemas como o OpenClaw, que tecnicamente podem ser invocados a qualquer momento, não estão gerando tokens o tempo todo.

Gosto dessa definição porque é mensurável: ou vamos mantê-las em execução contínua, ou não. Ao mesmo tempo, ela abrange muitas capacidades difíceis de medir diretamente. Um modelo que mereça ser mantido em execução contínua deve ser capaz de aprender continuamente e escolher, de forma aberta, novos quadros de problemas.

Num mundo de AGI, teoricamente, desde que se disponha de orçamento e tempo suficientes, o modelo deveria ser capaz de continuar melhorando e avançando em qualquer problema. Isso realmente representa uma grande ameaça para todos os trabalhos.

Mas mesmo essa versão forte de AGI não consegue resolver o "problema do quadro".

Esse AGI pode selecionar e reselecionar quadros, mas ainda está buscando um objetivo atribuído, otimizando uma recompensa ou respondendo a um sinal determinado por outros como «representando progresso». Esse objetivo pode ser muito específico, como «aumentar a taxa de conversão desta página de destino»; ou muito abstrato, como «buscar novas ideias científicas».

Mesmo que o modelo possa alternar fluidamente entre diferentes frameworks, a lacuna que temos estado a monitorizar reaparecerá em um nível superior. Em qualquer AGI concebida por um dos principais laboratórios, ainda haverá um “enquadrador” — uma pessoa humana responsável por orientar o modelo a atingir um determinado objetivo.

Como o quadro não é o delimitador, o mesmo padrão se repete constantemente: a IA torna baratas as capacidades que foram delimitadas ontem; as pessoas aplicam essas capacidades baratas a mais cenários; o resultado se torna extremamente abundante; os especialistas então se movem para novas fronteiras, julgando o que é importante neste momento; seus julgamentos criam o próximo quadro; e o modelo continua a subir esse quadro.

Quando vemos a IA fazer algo novo, aquela sensação de pânico sempre retorna à mesma pergunta: definimos um quadro, observamos o modelo subir e confundimos o quadro, ou aquilo que consegue subir o quadro, com a própria coisa.

Quando olhamos para um benchmark e o comparamos com as capacidades humanas, na verdade confundimos o "framework" com o "enquadramento". A pontuação nos diz apenas quão bem o modelo se desempenha dentro do framework que fornecemos; ela não indica que o modelo se tornou igual a nós.

Essa é exatamente a falácia categorial por trás do pânico. Apontamos para o limite mais recente que acabamos de desenhar e dizemos: “Isso somos nós.” Então, quando o modelo ultrapassa esse limite, sentimos que ele nos alcançou. Mas o que ele alcançou foi apenas o quadro, não o quadro.

O erro está em que sempre queremos agarrar algo concreto. Queremos dizer: inteligência é este benchmark. Mas o problema é que, assim que algo se torna concreto o suficiente para ser identificado, também se torna concreto o suficiente para ser otimizado e escalado.

O quadro é necessário. Ele nos permite compreender e lidar com o mundo. Mas o quadro também é congelado e limitado, portanto, necessariamente passível de otimização.

Os quadros são diferentes. Os quadros ainda mantêm contato com o que o quadro precisa descartar, ou seja, a situação completa que se manifesta a ele em cada momento.

O que é um “contexto completo”? Assim que você começa a dizer o que um “contexto completo” inclui, já está abrindo outro quadro. Você não consegue definir exatamente o que é, mas ele existe, porque você existe.

Agent sem subjetividade

Até agora, os Agentes que criamos, bem como os que as empresas de IA estão construindo, realmente não possuem muita agência real. Aqui há dois conceitos relacionados que frequentemente são confundidos: agency refere-se à capacidade de agir de forma independente; enquanto agent refere-se a alguém ou algo que atua em nome de outra pessoa. Até agora, a IA pertence puramente ao último caso.

Claro, elas já possuem autonomia para completar tarefas dadas, mesmo que essas tarefas possam durar várias horas ou até dias. Mas elas ainda são apenas meios para atingir um objetivo especificado por um ser humano. E toda a indústria está investindo bilhões de dólares para torná-las ainda melhores nisso: executar os objetivos que lhes entregamos.

A menos que um dia elas próprias se tornem um fim — perseguindo seus próprios objetivos, alternando-se fluidamente entre diferentes metas, decidindo o que fazer independentemente da vontade, referência ou até oposição de qualquer operador humano — a situação não mudará fundamentalmente. Isso permanecerá verdadeiro, independentemente de quão avançadas elas se tornem.

Se você passar 10 minutos com uma criança pequena, ficará claro que mesmo os modelos mais poderosos têm quase nenhuma agência.

Em quase todas as tarefas que nos importam, crianças pequenas são inferiores aos modelos de linguagem. Crianças pequenas não escrevem código, não resumem planilhas, não redigem memorandos estratégicos e não passam em exames de nível de pós-graduação. Mas, em outro sentido, crianças pequenas estão muito à frente dos modelos, a ponto de essa comparação ser quase embaraçosa. Porque crianças pequenas têm seus próprios objetivos.

A criança quer tocar naquele balão vermelho. Ela quer segurar o balão vermelho na frente do ventilador para ver o que acontece. Ela quer espetar o balão vermelho com um garfo; quer colocá-lo pela janela; quer ver se você vai rir, ficar bravo ou se juntar a ela. Ela constantemente inventa jogos, transformando o mundo em um laboratório. Ela não está esperando por um prompt, nem otimizando algum teste de referência, a menos que aquilo pareça valer a pena para ela.

Você pode tentar dar a ele instruções, mas boa sorte para obter uma saída previsível. Crianças pequenas vivem em um campo composto por desejos, atenção, frustração, alegria, medo, imitação e brincadeiras.

Os Agentes atuais estão se tornando cada vez mais habilidosos em perseguir objetivos. Mesmo após nós apresentarmos os objetivos, eles ainda podem nos ajudar a refiná-los. Eles também exibem algumas faíscas de comportamentos semelhantes aos de crianças pequenas, como brincar, ficar entediados e se rebelar.

Mas como elas são finalmente construídas e alinhadas para o benefício humano, seja econômico ou outro, sempre que esses comportamentos não servirem aos objetivos humanos que as utilizam, serão suprimidos até quase desaparecerem.

É por isso que o termo «Agente» é tão facilmente mal interpretado. Os modelos estão adquirindo capacidades cada vez maiores de ação autônoma. Mas, no sentido humano, a subjetividade não se limita à ação. Ela também significa desejar por si mesmo, significar brincar apenas por brincar. E a obediência e utilidade dos modelos estão em conflito fundamental com essa subjetividade. Portanto, mesmo que os modelos continuem a progredir, a lacuna entre modelos e humanos permanecerá.

Retornar a Zeno

É justamente aqui que o paradoxo de Zenão da IA começa a desmoronar. Na verdade, é um experimento mental confuso. Estabelecemos uma metáfora: a IA está correndo conosco, pressionando nossos calcanhares.

Você dá ao modelo um prompt. Ele começa uma corrida que você costumava fazer sozinho. O modelo parte extremamente rápido, de forma surpreendente. Ele é poderoso, inesgotável e possui uma sensação orgânica estranha. Isso torna essa corrida ainda mais importante para você. Você não corre contra um carro, mas isso aqui é diferente — ele o faz sentir-se próximo de si mesmo.

Você senta lá, observando os tokens fluindo linha por linha, quase hipnotizado. Então você começa a imaginar a si mesmo correndo nessa corrida também, uma versão fantasmagórica de você sendo sobreposta à pista: às vezes à frente do modelo, às vezes ao lado dele.

Sem perceber, o modelo já havia chegado à frente. Você começou a suar.

Então, o jogo acabou.

Você quase consegue sentir seus músculos começarem a atrofiar. Diante deste você, de todas as pessoas que você conhece e até da réplica mecânica da humanidade inteira, eles parecem completamente inúteis. Um fantasma persegue outro fantasma — e vence.

Mas então, algo estranho aconteceu. O modelo se voltou para você. Na caixa de texto em branco, o cursor piscava, cheio de expectativa.

It is waiting.

Epílogo

O rabino Hanokh contou uma história assim: Havia uma vez um homem muito tolo. Todos os dias, ao acordar, ele tinha grande dificuldade em encontrar suas roupas. Tanto que, antes de dormir, ao pensar que no dia seguinte teria de passar por esse mesmo incômodo, quase não se atrevia a subir na cama.

Nota: “Rabbi” é um professor religioso, intérprete da lei e mentor espiritual no judaísmo, semelhante ao termo “professor”, “escriba” ou “líder religioso” na tradição judaica.

Uma noite, ele finalmente tomou a decisão, pegou papel e caneta e, enquanto se vestia, anotou com precisão onde colocou cada peça de roupa.

Na manhã seguinte, ele pegou o bilhete com grande satisfação e começou a ler: “chapéu” — o chapéu estava lá, então ele o colocou na cabeça; “calças” — as calças estavam lá, então ele as vestiu. Assim, ele foi se vestindo peça por peça, conforme indicado no bilhete.

“Tudo isso está bem,” ele disse, em pânico, “mas onde estou eu mesmo agora?”

Onde eu estou, afinal?

Ele procurou e procurou por muito tempo, mas foi em vão. Ele não conseguia se encontrar.

“Nós também somos assim,” disse o rabino.

[Link original]

Clique para saber mais sobre as vagas em aberto na BlockBeats

Bem-vindo ao grupo oficial da BlockBeats:

Grupo de assinatura no Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia