Siddhant Khare entregou mais código no último trimestre de 2025 do que em qualquer outro período de sua carreira. Ele também nunca se sentiu tão exausto. Como mantenedor principal do OpenFGA (CNCF Incubating) e criador de ferramentas de infraestrutura para agentes de IA, Khare não é alguém que apenas experimenta IA casualmente, ele constrói os sistemas que outros engenheiros usam para fazer agentes funcionarem em produção.

E mesmo assim, ele bateu em um muro. O tipo de esgotamento que nenhuma otimização de workflow ou ferramenta consegue resolver.

Se você é engenheiro, gestor de produto ou profissional de tecnologia que usa IA diariamente — para revisões de design, geração de código, debugging, documentação ou decisões de arquitetura — e percebeu que está, paradoxalmente, mais cansado do que antes da IA existir, este não é um sintoma isolado. É uma experiência real que a indústria está agressivamente fingindo que não existe.

Quando a velocidade remove sua autonomia

Um estudo recente da UC Berkeley publicado na Harvard Business Review acompanhou 200 funcionários de uma empresa de tecnologia por oito meses. O que descobriram não foi uma revolução de produtividade foi o risco de empresas se tornarem “máquinas de burnout”.

Ninguém foi pressionado nessa empresa. Ninguém recebeu novas metas. As pessoas simplesmente começaram a fazer mais porque as ferramentas tornaram “mais” possível. E porque podiam fazer essas coisas, o trabalho começou a sangrar para horários de almoço e noites. As listas de tarefas se expandiram para preencher cada hora que a IA libertou e depois continuaram crescendo.

Como um engenheiro disse aos pesquisadores: “Você pensava que talvez, ah, porque você poderia ser mais produtivo com IA, então economizaria tempo, poderia trabalhar menos.” Mas a realidade foi o oposto.

Antes da IA, havia um teto natural de quanto você podia produzir em um dia. Esse teto era definido por velocidade de digitação, velocidade de raciocínio, tempo necessário para pesquisar informações. Era frustrante às vezes, mas também funcionava como um regulador. Você não conseguia se matar de trabalhar porque o próprio trabalho impunha limites.

A IA removeu o regulador. Agora o único limite é sua resistência cognitiva. E a maioria das pessoas não conhece seus limites cognitivos até ultrapassá-los completamente.

Você virou revisor e não assinou contrato para isso

O estudo da UC Berkeley identificou que equipes que implementaram IA para 300 engenheiros viram 93% querendo continuar usando, mas o volume de código enviado aumentou 28%, com 30-40% sendo gerado por IA. A matemática é precisa: mais código para revisar. E é código escrito por algo que não entende contexto, conhecimento de domínio ou implicações de longo prazo.

Fadiga de revisão de código é real e crescente. Desenvolvedores citam exaustão de revisão como principal contribuidor para burnout especialmente mudança de contexto. A troca de seu próprio trabalho para revisar o de outra pessoa custa 20-30% do seu foco por troca.

Antes da IA, o trabalho de um engenheiro era: pensar em um problema, escrever código, testá-lo, enviá-lo. Era criação. Construção. Isso é o que atraiu a maioria de nós para engenharia: o ato de fazer.

Depois da IA, o trabalho se tornou cada vez mais: escrever prompt, esperar, ler saída, avaliar saída, decidir se está correta, decidir se é segura, decidir se combina com a arquitetura, corrigir as partes que não combinam, re-escrever prompt, repetir.

Há pesquisa sobre isso: a diferença psicológica entre tarefas generativas e tarefas avaliativas. Trabalho generativo proporciona estados de fluxo. Trabalho avaliativo gera fadiga de decisão.

Revisão de código gerado por IA é especialmente drena porque cada linha é suspeita. O código parece confiante. Compila. Pode até passar em testes. Mas pode estar sutilmente errado de formas que só aparecem em produção, sob carga, às 3 da manhã.

Um relatório recente da CodeRabbit revelou que código gerado por IA cria 1,7x mais problemas do que código escrito por humanos. As questões vão desde nomenclatura pouco clara, terminologia incompatível e identificadores genéricos que aumentam a carga cognitiva para revisores até falhas mais sérias de lógica de negócio.

O Problema do não-determinismo

Engenheiros são treinados em determinismo. Mesma entrada, mesma saída. Esse é o contrato. É o que torna debugging possível. É o que torna raciocínio sobre sistemas possível. A IA quebrou esse contrato.

Khare relata ter tido um prompt que funcionou perfeitamente na segunda-feira. Gerou código limpo e bem estruturado para um endpoint de API. Ele usou o mesmo prompt na terça-feira para um endpoint similar. A saída era estruturalmente diferente, usava padrão diferente de tratamento de erros e introduziu uma dependência que ele não pediu.

Por quê? Sem razão acessível. Não há stack trace para “o modelo decidiu ir em direção diferente hoje”. Não há log dizendo “amostragem de temperatura escolheu caminho B em vez de A”. Simplesmente… aconteceu diferente.

Para alguém cuja carreira inteira é construída sobre “se quebrou, posso descobrir por quê”, isso é profundamente perturbador. Não de forma dramática. De forma lenta, constante, com ansiedade de fundo. Você nunca pode confiar totalmente na saída. Você nunca pode relaxar completamente. Cada interação exige vigilância.

A Esteira de FOMO

Tente absorver apenas os últimos meses: Claude Code lança sub-agentes, depois skills, depois Agent SDK, depois Claude Cowork. OpenAI lança Codex CLI, depois GPT-5.3-Codex — um modelo que literalmente ajudou a se programar. Novos agentes de codificação anunciam modo background com centenas de sessões autônomas simultâneas. Google lança Gemini CLI. GitHub adiciona MCP Registry. Aquisições acontecem semanalmente.

CrewAI, AutoGen, LangGraph, MetaGPT — escolha seu framework de agente, há um novo toda semana. Google anuncia A2A (protocolo Agent-to-Agent) para competir com MCP da Anthropic. OpenAI lança seu próprio framework Swarm. Kimi K2.5 aparece com arquitetura de enxame de agentes orquestrando 100 agentes paralelos.

Isso não é um ano. São alguns meses. E estou deixando coisas de fora.

Pesquisadores da UC Berkeley observaram que quando trabalhadores descobriram que cada um deles estava fazendo mais trabalho com ajuda de tecnologia, isso criou pressão implícita que pesou mentalmente.

O pior é a decadência do conhecimento. Khare passou duas semanas construindo workflow sofisticado de engenharia de prompt no início de 2025. Prompts de sistema cuidadosamente elaborados, exemplos few-shot, templates chain-of-thought. Funcionou bem. Três meses depois, o modelo atualizou, as melhores práticas de prompt mudaram, e metade dos templates produziram resultados piores que um simples one-liner. Aquelas duas semanas se foram. Não investidas. Gastas.

Carga cognitiva e sobrecarga de multitarefa

Estudos sobre carga cognitiva revelam que alta imersão em IA intensificou o impacto negativo da tensão cognitiva, sugerindo que super dependência de IA pode amplificar fardo mental em vez de reduzi-lo.

Antes da IA, Khare passava um dia inteiro em um problema de design. Esboçava no papel, pensava no chuveiro, dava uma caminhada, voltava com clareza. O ritmo era lento, mas a carga cognitiva era gerenciável. Um problema. Um dia. Foco profundo.

Agora? Ele pode tocar seis problemas diferentes em um dia. Cada um “leva apenas uma hora com IA”. Mas mudança de contexto entre seis problemas é brutalmente cara para o cérebro humano. A IA não fica cansada entre problemas. Ele fica.

Esse é o paradoxo: IA reduz o custo de produção mas aumenta o custo de coordenação, revisão e tomada de decisão. E esses custos recaem inteiramente sobre o humano.

Uma análise da BayTech Consulting identificou os “impostos ocultos” da adoção de IA: a carga cognitiva de mudança de contexto entre codificar e escrever prompts, o “fardo do revisor” de verificar código plausível mas incorreto, e introdução de defeitos sutis de alta severidade como condições de corrida e vulnerabilidades de segurança.

A atrofia do pensamento

Esse é o que mais assusta engenheiros experientes.

Khare notou durante reunião de revisão de design. Alguém pediu que ele raciocinasse sobre problema de concorrência no quadro branco. Sem laptop. Sem IA. Apenas ele e uma caneta. E ele teve dificuldade. Não porque não conhecesse os conceitos — conhecia. Mas porque não havia exercitado esse músculo em meses. Havia terceirizado seu pensamento de primeiro rascunho para IA por tanto tempo que sua capacidade de pensar do zero havia degradado.

É como GPS e navegação. Antes do GPS, você construía mapas mentais. Conhecia sua cidade. Conseguia raciocinar sobre rotas. Depois de anos de GPS, você não consegue navegar sem ele. A habilidade atrofiou porque parou de usá-la.

Fadiga mental é condição psicobiológica produzida por trabalho cognitivo prolongado, resultando em habilidades cognitivas diminuídas como memória e atenção.

O que realmente ajudou a enfrentar essa questão?

Khare desenvolveu protocolos específicos que transformaram sua relação com IA de adversarial para sustentável:

1. Time-boxing de sessões com IA: Não usar IA de forma aberta. Definir timer. 30 minutos para esta tarefa com IA. Quando o timer tocar, enviar o que tiver ou mudar para escrever manualmente. Isso previne tanto a espiral de prompts quanto a armadilha do perfeccionismo.

2. Separar tempo de IA de tempo de pensamento: Manhã para pensar. Tarde para execução assistida por IA. Não é rígido, mas ter estrutura padrão significa que o cérebro recebe tanto exercício quanto assistência nas proporções certas.

3. Aceitar 70% da IA: Parar de tentar obter saída perfeita. 70% utilizável é a barra. O restante será corrigido manualmente. Essa aceitação foi o maior redutor de frustração relacionada a IA.

4. Ser estratégico sobre o ciclo de hype: Parar de adotar toda nova ferramenta na semana de lançamento. Usar um assistente de código principal e conhecê-lo profundamente. Avaliar novas ferramentas quando provaram-se ao longo de meses, não dias.

5. Não revisar tudo que IA produz: Se você está usando IA para gerar grandes quantidades de código, fisicamente não pode revisar cada linha com o mesmo rigor. Focar energia de revisão nas partes que importam mais — limites de segurança, manipulação de dados, caminhos de erro — e confiar em testes automatizados e análise estática para o resto.

A questão da sustentabilidade

A indústria tech tem problema de burnout que antecede IA. IA está tornando pior, não melhor. Não porque IA é ruim, mas porque IA remove limites naturais de velocidade que costumavam nos proteger.

Um estudo de 2025 revelou que 68% de trabalhadores tech reportaram experimentar sintomas de burnout, acima de 49% apenas três anos antes. Uma análise da Glassdoor mostra aumento de 41% ano a ano em menções de “fadiga” em avaliações de empresas.

Os pesquisadores de Berkeley alertam que essas mudanças podem ser insustentáveis, levando a aumento de carga de trabalho, fadiga cognitiva, burnout e tomada de decisão enfraquecida. O surto de produtividade desfrutado no começo pode dar lugar a trabalho de menor qualidade, rotatividade e outros problemas.

Khare queimou no final de 2025. Não dramaticamente — ele não pediu demissão nem teve colapso. Simplesmente parou de se importar. Revisões de código viraram carimbos de borracha. Decisões de design viraram “o que quer que IA sugira”. Estava fazendo movimento mecânico, produzindo mais do que nunca, sentindo menos do que nunca.

Ironicamente, o período de burnout foi quando parte de seu melhor trabalho aconteceu. Quando parou de tentar usar toda ferramenta de IA e começou a pensar sobre o que estava realmente quebrado, viu os problemas claramente pela primeira vez. Context windows enchendo de lixo — isso virou Distill. Agentes com acesso API tudo-ou-nada — isso virou agentic-authz.

A Habilidade Real da Era IA

Um estudo da Human Clarity Institute com 503 adultos revelou experiências variadas. Enquanto 81% usam ferramentas com IA no trabalho ou vida diária, as experiências de esforço mental são diversas. Alguns respondentes acham escrever prompts e verificar confiança em informação de IA esgotante, enquanto outros reportam pouca tensão.

Para Khare, a habilidade real da era IA não é engenharia de prompt. Não é saber qual modelo usar. Não é ter workflow perfeito.

É saber quando parar. Saber quando a saída de IA é boa o suficiente. Saber quando escrever você mesmo. Saber quando fechar o laptop. Saber que seu cérebro é recurso finito e que protegê-lo não é preguiça — é engenharia.

Otimizamos nossos sistemas para sustentabilidade. Adicionamos circuit breakers. Implementamos backpressure. Projetamos para degradação graciosa. Deveríamos fazer o mesmo por nós mesmos.

IA é a ferramenta mais poderosa que muitos engenheiros já usaram. Também é a mais drenante. Ambas as coisas são verdadeiras. Os engenheiros que prosperam nesta era não serão aqueles que usam IA mais. Serão aqueles que a usam com mais sabedoria.

Se você está cansado, não é porque está fazendo errado. É porque isso é genuinamente difícil. A ferramenta é nova, os padrões ainda estão se formando, e a indústria está fingindo que mais output equivale a mais valor.