Há poucos anos, demonstrar produtividade significava mostrar resultados: uma entrega concluída, um processo melhorado, um problema resolvido.
Agora, parece que basta dizer que você usa inteligência artificial.
Empresas anunciam dezenas de agentes “autônomos”. Profissionais compartilham listas de prompts que supostamente resolvem qualquer problema. Na engenharia de software, surgem skills que prometem reduzir 80% dos tokens, acelerar entregas em 60% e transformar uma pessoa em uma equipe inteira.
Os números são sempre impressionantes.
O que quase nunca aparece é o trabalho necessário para fazê-los existir.
Não quero começar este artigo dizendo que a inteligência artificial não está automatizando o nosso trabalho. Seria desonesto. É óbvio que ela está reduzindo o tempo que gastamos em várias tarefas.
Mas estamos confundindo duas coisas muito diferentes: gerar mais rápido e trabalhar menos.
A primeira versão chega mais cedo, mas o trabalho necessário para transformá-la em algo confiável continua existindo. Precisamos preparar o contexto, escrever instruções, revisar o resultado, corrigir erros, testar o que foi produzido e manter o fluxo funcionando.
E quanto mais autonomia damos à IA, mais precisamos investir nesses controles ao redor dela.
O trabalho não desapareceu. Ele apenas mudou de lugar e, em muitos casos, ficou mais difícil de enxergar.
É sobre esse trabalho invisível que precisamos começar a falar. Porque, enquanto continuarmos medindo apenas o que a IA produz e ignorando tudo o que precisamos construir para tornar essa produção confiável, continuaremos celebrando uma produtividade que talvez nunca tenha existido.
A era dos números mágicos
Ao longo da carreira, você vê novos discursos e soluções mágicas surgirem o tempo todo. Alguém ainda se lembra do delírio das empresas comprando terrenos virtuais no metaverso? Eu estava lá.
E da promessa de que a blockchain acabaria com a computação centralizada? Se você é veterano na área de tecnologia, provavelmente viveu muito mais delírios do que eu.
O que mais chama minha atenção agora é que, desta vez, todas as empresas parecem ter descoberto o segredo definitivo da produtividade: a inteligência artificial.
Elas anunciam dezenas, centenas ou até milhares de agentes trabalhando sem parar. Agentes que respondem a clientes, analisam documentos, escrevem código, participam de reuniões, tomam decisões e supostamente automatizam 60%, 70% ou até 80% do trabalho.
Os profissionais também encontraram seus próprios atalhos. Hoje é quase impossível não ouvir alguém contando sobre os “hacks” que tem usado para ser mais produtivo: listas de prompts que escrevem e-mails, criam estratégias, analisam dados e supostamente transformam qualquer pessoa em especialista.
Na engenharia de software, surgem skills que prometem reduzir em 80% o consumo de tokens, agentes que aumentam em 60% a velocidade de entrega e fluxos que permitiriam a uma única pessoa fazer o trabalho de uma equipe inteira.
Os números mudam, mas quase sempre têm algo em comum: são grandes, impressionantes e difíceis de verificar.
Automatizou 80% em comparação com qual processo? A qualidade final foi equivalente? O tempo de revisão entrou na conta? E o custo de configuração? O experimento chegou à produção? O ganho permaneceu nas semanas seguintes? Quantos casos foram silenciosamente excluídos porque não funcionavam bem?
Sem respostas para essas perguntas, percentuais não são evidência. São marketing com aparência de medição.
Isso não significa que os ganhos sejam falsos. O problema começa quando um ganho local vira uma afirmação universal sobre produtividade, ou quando a melhor execução de uma demonstração é apresentada como o comportamento médio de um sistema em produção.
Enquanto isso, no trabalho real, alguém está escrevendo o terceiro prompt para corrigir a resposta do segundo, que tentou consertar o resultado errado produzido pelo primeiro.
Gerar não é entregar
Gosto muito de pensar que uma IA pode escrever uma funcionalidade em dez minutos. Isso não significa que a funcionalidade ficou pronta em dez minutos.
Acho isso uma excelente exemplificação do momento que estamos vivendo.
Eu mesmo já usei um agente para implementar uma funcionalidade que, olhando apenas para o primeiro resultado, parecia ter ficado pronta em poucos minutos, não parecia ter nenhum problema. O código existia, compilava e parecia coerente. É uma sensação impressionante, acertei de primeira! Mas isso é somente a ponta da história…
Antes da geração, alguém precisou entender o problema, esclarecer requisitos contraditórios, localizar as partes relevantes do sistema e fornecer contexto suficiente.
Depois dela, em algum ponto da jornada, um humano ainda terá de revisar o código, executar testes, avaliar segurança, integrar a mudança aos sistemas existentes, verificar observabilidade, corrigir comportamentos inesperados e assumir responsabilidade pelo que será colocado em produção.
O que normalmente esquecemos é que a geração é apenas uma etapa da entrega, frequentemente a mais visível e, agora, uma das mais baratas.
Essa distinção importa porque boa parte das promessas de produtividade compara o tempo que uma pessoa levava para produzir manualmente uma primeira versão com o tempo que a IA leva para gerar algo. Mas a comparação justa deveria considerar o ciclo completo: da identificação do problema até uma solução correta, segura, integrada e sustentável.
Se uma tarefa levava oito horas e agora a primeira versão surge em vinte minutos, há um ganho real. Porém, se organizar o contexto consome uma hora, revisar e corrigir exige outras três, os testes ocupam mais uma e a manutenção do novo fluxo adiciona trabalho recorrente, não automatizamos 95% da tarefa. Aceleramos uma etapa específica.
Isso continua sendo valioso. Economizar três horas é excelente.
O exagero não torna a tecnologia mais útil; apenas torna nossa avaliação menos confiável.
Produzir palavras, imagens ou código ficou barato. Entregar um resultado no qual podemos confiar não ficou barato na mesma proporção.
O trabalho mudou de lugar
Antes, o profissional executava diretamente uma parte maior da tarefa. Agora, com frequência, precisa preparar o ambiente para que a IA consiga executá-la:
contextualizar → instruir → gerar → avaliar → corrigir → testar → integrar → monitorar
A promessa de automação costuma iluminar apenas o momento da geração. Todo o restante permanece fora do enquadramento.
Em alguns dias, tenho quase certeza de que não escrevi de fato nenhum código. Para um desenvolvedor isso deveria significar que trabalhei menos. Mas, quando olho para o que realmente fiz, encontro horas gastas explicando o projeto, restringindo mudanças, revisando resultados e tentando fazer o agente entender uma regra que parecia muito óbvia para mim.
O tempo que antes era gasto escrevendo pode migrar para a seleção de referências, a organização de informações, a formulação de restrições e a revisão. O esforço de construir uma solução pode se transformar no esforço de decompor o problema em partes que o modelo consiga resolver. A repetição de uma tarefa manual pode dar lugar a outro ciclo: pedir, observar, avaliar, restringir e pedir novamente.
Essa mudança não é necessariamente ruim. Em muitos casos, há menos esforço mecânico e mais julgamento. Um desenvolvedor pode gastar menos tempo escrevendo estruturas repetitivas e mais tempo discutindo arquitetura. Uma analista pode produzir hipóteses rapidamente e dedicar sua atenção a confrontá-las com a realidade.
Mas trabalho diferente ainda é trabalho.
Operar bem esses sistemas exige reconhecer quando fornecer mais contexto, dividir a tarefa, mudar a instrução, corrigir manualmente, recomeçar ou abandonar a IA naquela etapa. Exige perceber respostas plausíveis, mas incorretas; distinguir um erro pontual de um fluxo mal concebido; decidir quando uma nova tentativa custa menos do que uma intervenção direta.
Trocamos parte da repetição de construir pela repetição de instruir, revisar e corrigir. A economia só pode ser medida depois de contabilizar os dois lados.
Para a IA trabalhar “sozinha”, alguém precisa ensinar
Há um paradoxo no centro da adoção corporativa de IA: quanto mais autonomia queremos dar a um sistema, mais precisamos tornar explícito o conhecimento da organização.
Um agente precisa saber como o sistema funciona, quais padrões seguir, quais decisões arquiteturais devem ser respeitadas, o que pode modificar, quais fontes são confiáveis, como validar uma implementação e o que a empresa considera uma entrega correta. Precisa conhecer regras formais e também aquelas exceções que todo mundo pratica, mas ninguém documentou.
Mas ensinar um agente não é apenas escrever documentação. Documentação registra conhecimento; contexto transforma esse conhecimento em algo que pode ser usado para executar uma tarefa. E contexto não aparece sozinho.
Alguém precisa descrever o problema, selecionar o que é relevante, explicar as restrições, fornecer exemplos, definir o resultado esperado e apontar quais informações não são confiáveis. Quando duas fontes entram em conflito, alguém precisa decidir qual delas vale. Quando uma regra muda, alguém precisa atualizar o material antes que o agente continue repetindo uma decisão antiga.
Na engenharia de software, por exemplo, não entregamos ao agente apenas um pedido. Entregamos a descrição da tarefa, trechos da arquitetura, convenções do projeto, mensagens de erro, testes, decisões anteriores e, muitas vezes, uma explicação sobre por que a solução mais óbvia não pode ser usada. Quanto melhor esse contexto, mais autônomo o agente parece. O que desaparece da demonstração é a pessoa que organizou toda essa ambiguidade antes de apertar Enter.
Já trabalhei em projetos nos quais uma regra importante existia apenas porque alguém se lembrava de uma decisão tomada anos antes. Nenhum documento explicava aquilo. Para uma pessoa nova na equipe, ainda era possível perguntar a quem estava por perto. Para um agente, aquele conhecimento simplesmente não existe — até que alguém pare o que está fazendo para produzi-lo.
Durante anos, muitas empresas negligenciaram documentação, gestão de conhecimento e qualidade dos dados. Agora esperam que agentes compreendam sistemas que nem os próprios funcionários conseguem explicar completamente. E não basta conectar um modelo a milhares de arquivos. Informação disponível não é o mesmo que contexto utilizável. Os documentos podem estar desatualizados, se contradizer ou descrever o processo oficial enquanto o trabalho real segue por outro caminho.
Por isso, alimentar um agente é um trabalho contínuo. Alguém precisa registrar decisões, organizar fontes, resolver contradições, definir hierarquias de confiança e traduzir conhecimento disperso para a tarefa que está sendo executada. Também precisa observar os erros do agente e produzir o contexto que faltou para que eles não se repitam.
Esse talvez seja um dos efeitos mais positivos da IA nas empresas: ela expõe não apenas a dívida de documentação, mas todo o trabalho de produção de contexto que antes acontecia informalmente entre as pessoas. O erro está em tratar esse trabalho como se não fizesse parte do custo da automação.
Prompts também viram legado
Prompts, skills, arquivos de instruções e bibliotecas de exemplos não surgem espontaneamente. Alguém precisa criá-los, testá-los, refiná-los, versioná-los, atualizá-los, resolver contradições e verificar se continuam funcionando quando o modelo, as ferramentas ou o processo mudam.
Eu também já criei instruções acreditando que estava resolvendo um problema de uma vez por todas. Pouco tempo depois, o arquivo tinha regras para evitar erros causados por outras regras, exemplos que já não representavam o projeto e observações que ninguém tinha coragem de remover. Se isso parece familiar, é porque já vimos a mesma história acontecer com o código.
À medida que crescem, essas instruções começam a assumir características de software. Acumulam regras, exceções, dependências e comportamentos inesperados. Uma alteração que melhora um cenário piora outro. Duas orientações razoáveis entram em conflito. Um exemplo antigo passa a induzir uma conduta que a empresa já não deseja. Uma instrução escrita para resolver um erro específico permanece meses depois de a causa ter desaparecido.
O prompt deixa de ser apenas uma pergunta. Em muitos sistemas, ele vira código legado escrito em linguagem natural.
Por ser linguagem natural, ele transmite uma falsa sensação de simplicidade. Todos conseguem ler a instrução, mas seu comportamento depende do restante do contexto, dos exemplos, das ferramentas e da entrada recebida. Por isso, sistemas sérios precisam de versões, avaliações, testes de regressão e critérios claros de qualidade.
Fazer um fluxo funcionar uma vez pode exigir um bom prompt. Fazer com que continue funcionando exige engenharia.
A falsa autonomia dos agentes
Um agente pode concluir várias etapas sem intervenção e ainda depender profundamente de trabalho humano.
Alguém selecionou suas ferramentas, definiu permissões, preparou os dados, escreveu instruções, criou exemplos, estabeleceu limites, tratou exceções, configurou monitoramento e decidiu o que fazer quando algo falha. E alguém continuará responsável se o agente apagar a informação errada, enviar uma mensagem inadequada ou tomar uma decisão sem dados suficientes.
Por isso, precisamos separar uma demo de autonomia operacional.
Em uma demonstração, o agente geralmente conclui o fluxo uma vez, em um ambiente controlado, com entradas escolhidas e uma pessoa pronta para intervir.
Agora para isso se converter em autonomia operacional, ele teria que repetir o fluxo todos os dias, diante de casos inesperados, mantendo qualidade, segurança, latência e custos previsíveis.
A distância entre as duas coisas é enorme.
A primeira execução é sedutora. Você escolhe uma tarefa organizada, fornece o contexto certo e acompanha o agente de perto. Quando ele termina, parece que o futuro chegou. O teste verdadeiro começa na décima execução, quando os dados estão incompletos, a documentação está desatualizada e ninguém preparou o caminho feliz.
Na empresa real, requisitos são contraditórios, regras permanecem implícitas, sistemas carregam legado, dados estão incompletos e as pessoas discordam sobre o resultado esperado. Esquecemos que demonstrações são somente protótipos.
Um protótipo responde uma única pergunta: “É possível fazer isso?”.
Um produto precisa responder: “Isso continuará funcionando todos os dias, em escala, com usuários reais e situações imprevisíveis?”.
O problema não começa quando o protótipo falha. Começa quando fingimos que ele já é um produto.
A demonstração vira promessa comercial. A promessa vira meta da liderança. A meta vira pressão sobre as equipes. E, assim, para sustentar a narrativa, pessoas passam a corrigir dados, refazer respostas e contornar falhas nos bastidores enquanto a organização anuncia um fluxo autônomo.
Fazer um agente funcionar uma vez é uma demonstração. Fazer com que ele continue funcionando é engenharia.
O teatro da produtividade
Existe um incentivo social para exagerar tudo isso.
Antes, profissionais sentiam que precisavam demonstrar que trabalhavam mais do que todos. Agora, precisam demonstrar que a IA faz tudo por eles. A empresa quer anunciar dezenas de agentes. O líder precisa apresentar aumento de produtividade. O funcionário precisa provar que domina a nova tecnologia. A startup precisa mostrar uma automação revolucionária. O criador de conteúdo precisa prometer um método que muda tudo.
Nesse ambiente, admitir limitações parece perigoso.
Poucas pessoas querem dizer que passaram três dias configurando um fluxo, que o agente ainda erra, que a automação só funciona nos casos simples ou que, descontada a manutenção, o ganho real foi de vinte minutos por semana.
Cada pessoa exagera um pouco. O exagero coletivo cria uma falsa linha de base em que todos parecem ter descoberto como produzir dez vezes mais. Quem olha de fora conclui que está atrasado. Equipes passam a perseguir metas baseadas em demonstrações cuidadosamente editadas. Lideranças cortam prazos sem compreender quais etapas foram realmente aceleradas. E trabalhadores escondem o esforço necessário para que os resultados pareçam automáticos.
O efeito não é apenas ansiedade. São decisões empresariais baseadas em uma realidade que não existe. Precisamos de uma linguagem mais honesta: dizer que uma ferramenta reduziu pela metade o tempo de rascunho é melhor do que afirmar que automatizou metade de uma função. Explicar que um agente resolve casos simples, mas encaminha exceções, é melhor do que chamá-lo de autônomo.
Precisão não diminui o valor da tecnologia. Ela permite investir no que realmente funciona.
A IA não precisa trabalhar sozinha para ser valiosa
A inteligência artificial está mudando o trabalho. Tarefas ficaram mais rápidas, acessíveis e menos cansativas. Pessoas conseguem explorar ideias antes inviáveis e pequenas equipes conquistaram capacidades que exigiam estruturas muito maiores.
Nada disso depende da fantasia de que o trabalho desapareceu.
A IA não precisa automatizar 80% de uma profissão para transformar uma empresa. Não precisa substituir equipes inteiras. Não precisa acertar na primeira tentativa. E não precisa ser apresentada como um funcionário mágico que nunca dorme, nunca erra e custa alguns centavos por tarefa.
Podemos celebrar uma automação que economiza vinte minutos por dia. Podemos admitir que um agente precisa de supervisão. Podemos apresentar um protótipo como protótipo. Podemos dizer que uma skill ajuda em alguns cenários sem inventar um percentual universal de produtividade.
Uma discussão madura contabiliza tanto o tempo economizado quanto o novo trabalho criado. Mede a geração, mas também a preparação, a validação, a correção, a integração e a manutenção. Reconhece que uma tarefa ficou mais rápida sem concluir que uma profissão inteira foi automatizada. E trata confiabilidade operacional como conquista, não como detalhe posterior à demonstração.
A inteligência artificial já é suficientemente transformadora.
Não precisamos fingir que ela eliminou o trabalho.
Precisamos apenas parar de esconder o trabalho necessário para fazê-la funcionar.