Distorções cognitivas para engenheiros: como pensar melhor sob pressão
Distorções cognitivas afetam decisões técnicas. Aprenda a identificar padrões comuns e trocar reação automática por análise verificável no trabalho.

Distorções cognitivas são padrões de pensamento que fazem uma situação parecer mais certa, pior ou mais pessoal do que as evidências permitem. Para engenheiros, elas aparecem em incidentes, code reviews, planejamento, carreira e trabalho com inteligência artificial (IA). O ganho prático é simples: separar fato, interpretação, emoção e próxima ação antes de decidir.
Este texto foi inspirado pelo artigo da Terapia Cognitiva sobre tipos de distorções cognitivas e pela explicação sobre como funciona a Terapia Cognitivo-Comportamental. Também conversa com a ideia central da Terapia Cognitivo-Comportamental (TCC), descrita pelo Beck Institute: pensamentos e percepções influenciam como sentimos e agimos.
Não é aconselhamento clínico. Se o padrão de pensamento está afetando sono, saúde, trabalho, relações ou segurança, procure uma pessoa profissional de saúde mental. Aqui o foco é tomada de decisão no trabalho.
O que são distorções cognitivas no trabalho técnico?
Uma distorção cognitiva é uma interpretação automática que parece fato, mas ainda não foi testada. Ela pode nascer de estresse, medo, pressa, histórico ruim, perfeccionismo ou excesso de responsabilidade.
No trabalho técnico, a sequência costuma ser esta:
| Camada | Exemplo |
|---|---|
| Fato | O deploy falhou em produção |
| Interpretação | "Eu quebrei tudo" |
| Emoção | Vergonha, ansiedade, irritação |
| Ação automática | Esconder, culpar alguém, reverter sem investigar |
| Ação melhor | Ler logs, reduzir impacto, comunicar estado, achar causa |
O problema não é sentir algo. O problema é deixar a primeira interpretação comandar a próxima ação.
Por que isso importa para engenheiros?
Engenharia de software é decisão sob incerteza. Quase nunca temos todos os dados, todo o contexto e todo o tempo. Distorções cognitivas aumentam ruído nessa decisão.
Elas aparecem quando você:
- Superestima o risco de uma mudança pequena.
- Subestima um bug porque "sempre foi assim".
- Lê um comentário de review como ataque pessoal.
- Trata um incidente como prova de incompetência.
- Acredita que uma ferramenta de IA resolveu tudo sem validar.
- Acha que se não foi perfeito, foi inútil.
O resultado é previsível: mais ansiedade, decisões defensivas, PRs grandes demais, reviews tensos, menos aprendizado e menos evidência.
Quais distorções aparecem mais em times de software?
Estas não são categorias clínicas para autodiagnóstico. São rótulos úteis para perceber padrões no trabalho.
Personalização aparece quando você chama para si uma causa que era sistêmica. Um incidente não nasce só da pessoa que clicou em deploy. Ele também envolve revisão, testes, alerta, feature flag, rollback, observabilidade e pressão de prazo. A pergunta útil é: quais fatores do sistema contribuíram além da minha ação?
Maximização e minimização aparece quando seus erros ficam enormes e seus acertos somem. Você lembra do bug que escapou, mas ignora a feature entregue, o teste que preveniu regressão e a ajuda que deu ao time. A pergunta útil é: estou aumentando a falha e diminuindo a evidência de progresso?
Catastrofização aparece quando um risco vira desastre certo. "Se esse PR quebrar, acabou minha confiança no time" ou "se houve layoff em uma empresa, ninguém mais precisa de engenheiro". A pergunta útil é: qual é o pior caso realista, qual é a probabilidade e qual é o plano de resposta?
Leitura da mente aparece quando você acha que sabe o que outra pessoa pensa. "O reviewer acha que sou ruim", "a liderança percebeu que não sou sênior de verdade" ou "o entrevistador já me reprovou". A pergunta útil é: que evidência tenho além do meu medo?
Rótulos aparecem quando um comportamento específico vira identidade. "Sou péssimo em backend", "sou dev de tutorial", "sou júnior demais para esse mercado". A pergunta útil é: qual habilidade concreta precisa melhorar, sem transformar isso em sentença sobre quem eu sou?
Emocionalização aparece quando a emoção vira prova. "Estou inseguro, então a arquitetura deve estar errada" ou "estou ansioso, então vou ser demitido". A pergunta útil é: que teste, conversa ou evidência pode validar a interpretação?
Polarização aparece no pensamento tudo ou nada. A IA é salvação ou ameaça total. O PR está perfeito ou inútil. A carreira está indo muito bem ou acabou. A pergunta útil é: qual parte é boa, qual parte está fraca e qual próximo ajuste é suficiente?
Abstração seletiva aparece quando você escolhe um detalhe negativo e ignora o resto do quadro. Uma pergunta que você não soube responder na entrevista vira "fui horrível", mesmo que tenha ido bem em arquitetura, comunicação e experiência. A pergunta útil é: o que estou deixando fora da análise?
Adivinhação aparece quando você trata uma previsão como fato. "O mercado não vai contratar pleno", "IA vai eliminar minha função", "essa candidatura não vai dar em nada". A pergunta útil é: isso é dado, hipótese ou medo?
Desqualificação do positivo aparece quando uma entrega boa perde valor porque teve apoio. "Só entreguei porque usei IA", "só passei porque me indicaram", "só resolvi porque alguém explicou". A pergunta útil é: o que eu decidi, revisei, testei, comuniquei e assumi?
Hipergeneralização aparece quando um evento vira regra universal. Uma entrevista ruim vira "sempre vou mal". Um feedback duro vira "ninguém confia em mim". Uma stack nova difícil vira "não aprendo mais rápido como antes". A pergunta útil é: quantas vezes isso aconteceu de fato?
Pensamento imperativo aparece nos "eu deveria". "Eu deveria saber tudo de IA", "eu deveria dar conta sem pedir ajuda", "eu deveria ser sênior em toda tecnologia". A pergunta útil é: essa expectativa é realista para meu nível, contexto e tempo disponível?
Vitimização aparece quando todo poder sai da sua mão. "O mercado está impossível, então não adianta fazer nada" ou "a IA estragou a carreira de dev". Às vezes o contexto é realmente duro. Mesmo assim, a pergunta útil é: qual pequena ação ainda está sob meu controle?
Questionalização aparece quando a mente fica presa em perguntas sem saída. "Por que eu não aprendi isso antes?", "por que aceitei esse emprego?", "por que não comecei com IA em 2023?". A pergunta útil é: que pergunta me leva para uma ação agora?
O rótulo não resolve o problema. Ele só cria um intervalo entre reação e escolha.
Como identificar uma distorção antes de decidir?
Use um protocolo curto. O NHS resume uma prática de TCC como capturar, checar e mudar pensamentos inúteis. Para engenharia, eu adaptaria assim:
- Capture a frase automática.
- Separe fato de interpretação.
- Nomeie a distorção provável.
- Procure evidência a favor e contra.
- Escolha uma ação pequena e verificável.
Exemplo:
| Passo | Resposta |
|---|---|
| Frase automática | "Esse comentário prova que não sei programar" |
| Fato | O reviewer pediu teste para um edge case |
| Interpretação | "Ele acha que sou incompetente" |
| Distorção | Leitura da mente, rotulação |
| Evidência contra | O comentário aponta um caso específico e tem sugestão concreta |
| Próxima ação | Adicionar o teste, responder com o racional e seguir |
Essa prática não pede otimismo forçado. Ela pede precisão.
Como usar isso em code review?
Code review é um dos lugares onde distorções cognitivas ficam visíveis, porque o trabalho de uma pessoa vira objeto público de crítica.
Para o autor:
- Leia o comentário como informação sobre o diff, não como sentença sobre você.
- Peça exemplo quando o comentário estiver vago.
- Separe bloqueio, sugestão, pergunta e preferência.
- Responda com evidência: teste, log, screenshot, benchmark ou decisão de produto.
Para o reviewer:
- Critique o comportamento do código, não a pessoa.
- Diga se o comentário bloqueia ou sugere.
- Explique o risco concreto.
- Evite transformar gosto pessoal em regra universal.
Um comentário como "isso está errado" convida defesa. Um comentário como "Blocker: esta mutation não valida orgId, então um usuário pode alterar dados de outra organização" convida correção.
Como usar isso durante incidentes?
Em incidente, catastrofização e personalização costumam aparecer rápido. A mente quer fechar a história antes dos logs.
Troque a narrativa por um loop operacional:
| Pergunta | Objetivo |
|---|---|
| O que sabemos? | Separar fato de suposição |
| Qual é o impacto atual? | Priorizar mitigação |
| O que mudou recentemente? | Reduzir espaço de busca |
| Qual é a ação reversível mais segura? | Evitar correção impulsiva |
| Quem precisa saber o quê? | Comunicar sem dramatizar |
Depois do incidente, uma pergunta melhor do que "quem errou?" é: "qual barreira faltou?". Pode ser teste, feature flag, rollback, alerta, runbook, limite de permissão, revisão ou observabilidade.
Como isso muda o trabalho com IA?
IA generativa amplifica pensamento automático. Ela pode acelerar análise, mas também pode dar uma resposta fluente para uma interpretação ruim.
Três distorções aparecem muito:
| Distorção | Prompt ruim | Prompt melhor |
|---|---|---|
| Confirmação | "Prove que essa lib é ruim" | "Compare riscos, benefícios e cenários onde essa lib faz sentido" |
| Catastrofização | "Esse erro é grave?" | "Liste hipóteses por probabilidade, impacto e evidência necessária" |
| Tudo ou nada | "Essa arquitetura é certa ou errada?" | "Quais trade-offs essa arquitetura assume e quais sinais invalidam a escolha?" |
O agente deve ajudar a testar pensamento, não só obedecer ao medo. Peça contraexemplos, hipóteses alternativas, matriz de risco e evidência mínima para decidir.
Como isso aparece em IA, mercado e senioridade?
Mercado de trabalho em tecnologia ficou mais ruidoso com IA, layoffs e mudanças rápidas no desenvolvimento de software. Esse ruído não afeta todo mundo do mesmo jeito. Júnior, pleno e sênior costumam distorcer situações diferentes.
| Contexto | Distorção comum | Pensamento automático | Pergunta melhor |
|---|---|---|---|
| IA no desenvolvimento de software | Tudo ou nada | "Se a IA escreve código, meu trabalho acabou" | Qual parte do meu trabalho ainda exige contexto, julgamento, validação e responsabilidade? |
| Ferramentas de IA | Desqualificação do positivo | "Só entreguei porque usei IA" | O que eu decidi, revisei, testei e assumi como responsabilidade? |
| Layoffs | Catastrofização | "Se uma empresa cortou devs, ninguém mais precisa de engenheiros" | Qual é o sinal real do mercado e qual é o meu próximo passo verificável? |
| Vagas mais exigentes | Generalização | "Todas as vagas pedem tudo, então não tenho chance" | Quais requisitos são obrigatórios e quais são lista de desejo? |
| Salário e senioridade | Leitura da mente | "Eles vão perceber que não sou tão bom" | Que evidências do meu trabalho posso mostrar com clareza? |
Para júnior, a distorção mais comum é transformar falta de experiência em identidade. "Ainda não sei debugar produção" vira "não sirvo para programação". A pergunta melhor é: qual habilidade específica preciso treinar nesta semana?
Para pleno, o risco é comparar a própria entrega com o melhor recorte público de outras pessoas. Um vídeo de alguém usando IA para criar uma aplicação inteira em minutos pode virar vergonha, quando deveria virar análise: o que era demo, o que era produto, o que foi validado e o que ficou escondido?
Para sênior, a distorção pode aparecer como responsabilidade total. "Se o time errou, eu falhei como referência técnica." Às vezes há responsabilidade real. Mas a pergunta precisa ser operacional: qual sistema faltou para prevenir, detectar ou corrigir o erro mais cedo?
IA e mercado não pedem pensamento positivo. Pedem pensamento verificável. O ponto não é negar risco. É não deixar o medo escolher sozinho a interpretação.
Qual checklist usar antes de reagir?
Use este checklist quando perceber tensão, pressa ou defesa:
- Qual é o fato observável?
- Qual é minha interpretação?
- Que emoção está aumentando o volume dessa interpretação?
- Qual distorção pode estar ativa?
- Que evidência falta?
- Qual ação pequena reduz incerteza?
- Quem precisa de contexto agora?
- O que pode esperar até eu esfriar?
Se a resposta exige urgência, aja no impacto. Se não exige urgência, compre tempo para pensar.
Que dicas do Dale Carnegie ajudam aqui?
Em Como evitar preocupações e começar a viver, Dale Carnegie volta várias vezes para uma ideia simples: preocupação cresce quando a mente fica presa em futuros vagos, culpas antigas e problemas sem ação definida. Para engenharia, isso combina bem com o combate às distorções cognitivas.
Algumas adaptações práticas:
| Dica | Como usar no trabalho técnico |
|---|---|
| Viva em unidades menores de tempo | Em vez de tentar resolver a carreira inteira hoje, resolva o próximo bloco: estudar um conceito, revisar um PR, mandar uma candidatura, escrever uma nota de aprendizado |
| Encare o pior caso realista | Se o deploy falhar, qual é o rollback? Se a entrevista der errado, o que você aprende? Se a vaga não vier, qual é o próximo contato? |
| Transforme preocupação em ação | Troque "e se eu for demitido?" por "vou atualizar meu CV, revisar meu portfólio e falar com três pessoas esta semana" |
| Não serrar serragem | Depois que uma decisão já passou, faça post-mortem e ajuste o processo. Ficar revivendo a culpa não melhora o sistema |
| Conte as evidências, não só os medos | Mantenha registro de bugs resolvidos, feedbacks, entregas, estudos e problemas que você já atravessou |
Isso conversa com meu post sobre síndrome do impostor na tecnologia. Lá eu escrevi que a síndrome do impostor distorce a forma como você interpreta a própria competência: falhas ficam gigantes e vitórias ficam pequenas. A resposta prática é parecida: medir progresso, buscar pessoas confiáveis, registrar evidências e agir mesmo antes de se sentir 100% confiante.
Carnegie não elimina incerteza. A utilidade dele é mais humilde: reduzir a preocupação até ela caber em uma próxima ação.
Como transformar isso em hábito?
Pensamento claro melhora quando vira processo, não quando depende de força de vontade.
Algumas práticas simples:
- Em incidentes, use template de status com fatos, impacto, ação e próximo update.
- Em PRs, escreva intenção, escopo, evidência e risco antes de pedir review.
- Em decisões técnicas, registre trade-offs e sinais de invalidação.
- Em prompts para IA, peça evidência contra sua hipótese inicial.
- Em feedback difícil, espere alguns minutos antes de responder.
- Em post-mortems, procure barreiras ausentes antes de procurar culpados.
O objetivo não é virar uma pessoa perfeitamente racional. É diminuir decisões tomadas por impulso.
Resumo
Distorções cognitivas são padrões de interpretação que podem deformar decisões técnicas. Em engenharia, elas incluem personalização, maximização e minimização, catastrofização, leitura da mente, rótulos, emocionalização, polarização, abstração seletiva, adivinhação, desqualificação do positivo, hipergeneralização, pensamento imperativo, vitimização e questionalização.
O antídoto prático é separar fato, interpretação, emoção e ação. Depois, buscar evidência e escolher o menor próximo passo verificável. Isso melhora code review, incidentes, planejamento e uso de IA, porque troca reação automática por julgamento mais claro.
Fontes
Este texto parte destas referências e adapta os conceitos para o contexto de engenharia de software:
- Distorções cognitivas: entenda o que é e quais os seus tipos, Terapia Cognitiva.
- Como funciona a Terapia Cognitivo Comportamental?, Terapia Cognitiva.
- Understanding CBT, Beck Institute.
- Reframing unhelpful thoughts, NHS.
- Como evitar preocupações e começar a viver, Dale Carnegie.
- Síndrome do impostor na tecnologia, Thiago Marinho.
Recomendação de cuidado
Se você se identificou com estes padrões e sente que eles estão afetando sua saúde mental, trabalho ou relações, considere buscar acompanhamento profissional.
Recomendo o trabalho da Carla Suzana Marinho, psicóloga clínica com atendimento online para adultos, com foco em TDAH, ansiedade, depressão e saúde mental e emocional. Agendamento pelo WhatsApp: wa.me/5567996882030.
Versículo para meditar
Filipenses 4:8 é um bom fechamento para este tema: ele chama a mente para o que é verdadeiro, justo, puro, amável, de boa fama, virtuoso e digno de louvor. Depois de identificar pensamentos distorcidos, o próximo passo é alimentar pensamentos mais verdadeiros e saudáveis.
Escrito por IA, revisado por Thiago Marinho
21 de junho de 2026 · Brazil