Sou um Engenheiro Sênior e a IA Está Fritando Meu Cérebro

Um relato honesto sobre dívida cognitiva, burnout de orquestração de agentes, e por que fundamentos importam mais do que nunca.

Preciso ser honesto sobre uma coisa.

Nos últimos meses, tenho rodado múltiplos agentes de IA em paralelo — todos os dias. Agentes fazendo pesquisa. Agentes gerando PBIs e PRPs. Agentes criando RFCs e documentos de arquitetura. Meu trabalho se tornou revisar, orquestrar, trocar contexto entre dezenas de entregas que eu não escrevi, mas pelas quais sou totalmente responsável.

E estou esgotado.

Não o tipo "trabalhei horas demais". Um tipo diferente. Meu cérebro está frito no final do dia — não porque codei demais, mas porque supervisionei demais. Me sinto produtivo. O output é real. Mas o estresse está acumulando de uma forma que nunca experimentei em mais de 10 anos de engenharia de software.

Se você é um desenvolvedor usando ferramentas de IA diariamente, desconfio que sabe exatamente do que estou falando.

A Promessa vs. A Realidade

A promessa era clara: a IA faria o trabalho pesado e o desenvolvedor ganharia tempo.

Alguns anos depois, a realidade é diferente. A IA não reduziu nosso trabalho — ela mudou o tipo de trabalho. Passamos de construtores a supervisores. De engenheiros a gerentes de agentes autônomos. E ninguém nos avisou sobre o que essa mudança faria com nossas mentes.

Já existe nome pra isso: AI Brain Fry — a fritura cerebral causada pela IA. O uso excessivo de IA está esgotando mentalmente programadores e engenheiros de software. E o mecanismo por trás disso também tem nome — dívida cognitiva.

O Que É Dívida Cognitiva?

Se você conhece dívida técnica, pense na dívida cognitiva como sua prima — mas aplicada ao seu cérebro.

Uma linha recente de pesquisa vem mapeando exatamente esse fenômeno: o que acontece com times de engenharia quando a IA assume uma fatia significativa da criação de código e das decisões de design, e como o custo aparece não no código, mas na cabeça das pessoas que mantêm o sistema. O foco do trabalho é justamente aquilo que métricas tradicionais não capturam — a erosão do entendimento compartilhado dentro de times que entregam rápido com IA.

Essa pesquisa é conduzida por Margaret Story, e ela descreveu a dívida cognitiva perfeitamente: é o acúmulo de esforço mental e falta de entendimento que acontece quando delegamos uma parte significativa da criação de código e das decisões para a IA.

Quando você escreve código do zero, você constrói um modelo mental do sistema na sua cabeça. Mas quando a IA gera centenas de linhas em segundos — e na maioria das vezes a gente só aprova — a distância entre a velocidade de geração da IA e a nossa capacidade real humana de compreensão e revisão é a nossa dívida cognitiva.

E os juros dessa dívida são brutais. Quando um bug estoura em produção ou você precisa alterar uma arquitetura que foi "gerada magicamente", o esforço para debugar e entender aquele labirinto de código é gigantesco. É aí que a mente quebra.

Story ilustrou isso de forma vívida com um experimento em sala de aula. Equipes de alunos estavam desenvolvendo produtos de software ao longo do semestre, entregando features rápido para cumprir prazos. Por volta da sétima ou oitava semana, uma equipe bateu num muro. Não conseguiam fazer nem alterações simples sem quebrar algo inesperado.

Inicialmente, culparam a dívida técnica — código confuso, arquitetura ruim. Mas o verdadeiro problema era mais profundo: ninguém na equipe conseguia explicar por que certas decisões de design haviam sido tomadas ou como as diferentes partes do sistema deveriam funcionar juntas. O entendimento compartilhado havia se fragmentado. Eles acumularam dívida cognitiva mais rápido que dívida técnica, e foi isso que os paralisou.

Como Elemar Junior colocou: "Velocidade sem compreensão é adiantamento de problema. Estamos acelerando a entrega e desacelerando a formação."

Story também referencia o insight clássico de Peter Naur: um programa é uma teoria — ele vive na mente dos desenvolvedores, capturando o que o programa faz, como as intenções foram implementadas, e como ele pode ser alterado ao longo do tempo. Geralmente essa teoria não está na mente de uma pessoa só, mas distribuída entre muitos desenvolvedores.

É exatamente isso que a dívida cognitiva corrói. Quando agentes de IA geram código em escala, a teoria se fragmenta. Ninguém mais detém completamente o "porquê". Como Story coloca: "Dívida técnica vive no código; dívida cognitiva vive na mente dos desenvolvedores."

E o princípio de Kent Beck se torna mais relevante do que nunca: a relutância em desacelerar e fazer o trabalho de "tornar a mudança difícil em fácil" é precisamente o que leva a dívida cognitiva a se acumular silenciosamente — até que o time bate num muro.

A Armadilha do Context Switching Agêntico

Assim é meu dia típico agora:

Num momento sou arquiteto revisando design de sistema. No seguinte sou QA validando um PRP. Depois sou tech lead revisando um RFC. Depois volto a revisar código gerado por um agente. Cada agente entrega um artefato que exige um modo mental diferente para revisar adequadamente.

Isso não é context switching tradicional. Isso é context switching agêntico — e é significativamente mais pesado porque você não está apenas trocando entre tarefas, está trocando entre papéis.

No final do dia, "produzi" mais do que jamais conseguiria manualmente. Mas o resíduo mental é pesado. A ansiedade é real. E o pior — começo a perder o controle de revisar todas aquelas entregas adequadamente. Desconfio que muitos desenvolvedores estão fazendo o mesmo: aprovando coisas que não entenderam completamente porque o ritmo é implacável.

Meu Despertar com o Vibe Coding

Recentemente, decidi experimentar o vibe coding num projeto pessoal. Eu tinha uma vantagem que a maioria não tem: venho construindo uma metodologia chamada FORGE que trabalha com conceitos como PRDs (Product Requirements Documents) e User Stories para manter estrutura e rastreabilidade ao trabalhar com agentes de IA.

Então entrei com guardrails. E inicialmente funcionou. A metodologia me deu controle sobre as features sendo criadas. Conseguia rastrear decisões, revisar incrementalmente, manter a carga cognitiva gerenciável.

Mas aí bati num muro.

Tinha uma decisão técnica específica que precisava tomar — algo que eu não dominava profundamente. Tinha duas opções: parar e estudar adequadamente, ou delegar para a IA e manter o momentum.

Escolhi a segunda opção.

O resultado foi previsível em retrospecto. Perdi o controle total. Quando as coisas quebraram, precisei gastar mais horas que o normal para consertar porque precisei estudar a ferramenta e entender o problema por baixo. Sou um programador experiente, mas a linguagem e a stack mudaram completamente o paradigma — meus modelos mentais sólidos de Java/Spring Boot não se transferiram limpos para esse novo contexto.

A metodologia segurou o barco, mas não substituiu o entendimento profundo. Quando o conhecimento fundamental faltou naquele contexto específico, a IA amplificou o problema em vez de resolver.

E o que mais me impactou: durante aquele projeto, me senti mais como um Product Owner do que um Engenheiro de Software. Estava gerenciando requisitos e aprovando entregas em vez de construir e entender sistemas. O craft desapareceu. O estresse aumentou.

Os Dados Confirmam

Isso não é só minha experiência. A pesquisa está alcançando a realidade:

• Trabalhadores que reportaram altos níveis de supervisão de IA gastaram 14% mais esforço mental no trabalho
• Alta supervisão de IA previu 12% mais fadiga mental
• Supervisão mais intensa de IA previu 19% mais sobrecarga de informações
• Na pesquisa salarial de desenvolvedores brasileiros, 29% reportaram burnout, com 73% experimentando ansiedade e estresse

Como a pesquisa do CDF aponta: a IA não está reduzindo trabalho — está intensificando. Estamos sendo empurrados a produzir numa velocidade praticamente inumana, e não conseguimos acompanhar o entendimento do que está sendo criado.

A Verdade Desconfortável

As ferramentas são genuinamente transformativas. A capacidade é real. Os ganhos de produtividade são reais. Não vou voltar a escrever tudo na mão.

Mas produtividade nunca foi o gargalo real.

O gargalo real é coerência, foco, finalização, julgamento — e saber o que você está construindo e por que está construindo. Isso é o que está se perdendo no loop agêntico.

A parte mais desgastante da interação com IA não é o prompting — é a supervisão. Aquele momento em que você está vendo o agente gerar uma árvore de código e sente que não pode simplesmente ficar parado. Então começa outra tarefa. E outra. Uma hora depois tem cinco coisas pela metade e não lembra qual era a tarefa principal. Você se sente produtivo, mas não está. Está apenas ocupado.

O Que Estou Fazendo a Respeito

Não vou fingir que tenho todas as respostas. Mas eis o que aprendi até agora:

1. Fundamentos são seu escudo. Meu conhecimento de arquitetura e system design é o que me salvou de problemas maiores. Quando as coisas quebraram, eu tinha os modelos mentais para diagnosticar e recuperar. Desenvolvedores que pulam fundamentos na era da IA estão construindo sobre areia.

2. Metodologia é seu guardrail, não substituto para entendimento. Por isso estou construindo o FORGE — uma metodologia desenhada especificamente para a era dos agentes de IA. Um dos seus conceitos centrais é o Blueprint: antes de qualquer código ser gerado, o FORGE produz um documento que captura como o código será implementado e por que cada decisão foi tomada. Isso endereça diretamente o que Peter Naur chamou de "teoria do sistema" — o Blueprint garante que o "porquê" nunca se perca, me ajudando a manter controle, prever erros antes da implementação, e preservar o entendimento compartilhado que Margaret Story nos alerta estar se erodindo. Ajudou. Mas não é bala de prata quando o conhecimento profundo está faltando.

3. Saiba quando parar e aprender. No momento em que escolhi velocidade ao invés de entendimento no projeto CrewAI, assinei um contrato de mais dor depois. O instinto de "só delega" é a armadilha da dívida cognitiva.

4. Single-thread sua supervisão. Estou ativamente resistindo à vontade de rodar 5 agentes em paralelo. Uma tarefa, um ciclo de revisão, compreensão completa antes de seguir em frente. Parece mais lento. Na verdade é mais rápido.

5. O craft importa. Se você sente que virou P.O. em vez de engenheiro, isso é um sinal. Dê um passo atrás. Escreva código você mesmo. Construa o modelo mental. Os agentes não vão embora — mas seu entendimento pode ir.

Uma Mensagem para Desenvolvedores Juniores

Se você está no início da carreira e lendo isso: por favor, invista em fundamentos.

Aprenda arquitetura. Aprenda system design. Entenda por que padrões existem, não apenas como promptar uma IA para gerá-los. Porque quando as coisas quebrarem — e vão quebrar — nenhum agente vai te salvar. Seu modelo mental do sistema é a única coisa que vai.

Os desenvolvedores na sala de aula da Margaret Story estavam se movendo rápido com IA — entregando features, cumprindo milestones — até que o entendimento compartilhado colapsou. Agora escale essa dinâmica para cada time adotando workflows agênticos, gerando 10x mais código, 10x mais rápido, com 10x menos compreensão.

Dívida cognitiva é real. E diferente de dívida técnica, você não consegue refatorar um cérebro que nunca aprendeu como o sistema funciona.

Pensamento Final

A questão não é usar IA ou não. O mercado mudou. As ferramentas vieram pra ficar.

A questão é: você está usando a IA, ou a IA está usando você?

Se você termina todo dia com o cérebro frito, produzindo muito mas entendendo menos, se sentindo produtivo mas ansioso — é hora de desacelerar e recalibrar.

O código pode esperar. Sua mente não.

Se você se reconheceu em alguma parte deste artigo, estou construindo o FORGE exatamente para endereçar isso — uma metodologia e CLI para desenvolvimento de software com assistência de IA que mantém o "porquê" intacto. O FORGE captura a intenção antes do código ser escrito, para que o workflow agêntico rode contra um blueprint explícito em vez de acumular dívida cognitiva. Veja como o FORGE funciona e entre no early access →

Referências

• Margaret Storey — Cognitive Debt. Pesquisa sobre dívida cognitiva, entendimento compartilhado e a erosão da "teoria do sistema" em times assistidos por IA.
• Harvard Business Review — When Using AI Leads to Brain Fry. A peça da HBR que cunhou o fenômeno do AI Brain Fry.
• Código Fonte TV (CDF) — discussão sobre carga cognitiva da IA e burnout em devs, trazendo os estudos por trás dos +14% de esforço mental, +12% de fadiga e +19% de sobrecarga de informação sob alta supervisão de IA.
• Peter Naur — Programming as Theory Building (1985). O ensaio fundacional que defende que um programa é uma teoria que vive na mente dos desenvolvedores.
• Kent Beck — "For each desired change, make the change easy (warning: this may be hard), then make the easy change."
• Elemar Junior — comentário sobre velocidade sem compreensão como custo adiado ("acelerando a entrega e desacelerando a formação").
• Pesquisa de salários da comunidade dev brasileira — 29% relatando burnout, 73% relatando ansiedade e estresse.