Como saber quem está pensando?

Neste exato momento, no seu time, tem pelo menos um engenheiro entregando um trabalho que ele não saberia reproduzir num quadro branco.

O código compila. Os testes passam. O PR está impecável. Só que o raciocínio não era dele desde o começo, e ele não sabe disso. Por dentro, pegar um pensamento emprestado é igualzinho a ter um.

Você vai descobrir na próxima vez que alguém fizer a pergunta do cache. O diagrama de arquitetura está na tela, o design parece limpo, e um engenheiro staff se inclina para a frente:

Me explica por que você descartou um write-through cache aqui. O que acontece quando este nó específico reinicia sob carga?

A pausa que vem depois deveria ser uma pausa de recuperação: o engenheiro vasculhando o próprio modelo mental atrás da restrição que ele tinha considerado, da alternativa que pesou, do efeito de segunda ordem que estava acompanhando quando tomou a decisão.

Hoje, a pausa é um vazio.

O atrito sustentava a estrutura

Isto não é um elogio fúnebre aos bons tempos de garimpar respostas no Stack Overflow.

A IA é um multiplicador fantástico. É uma revisora incansável de madrugada, que lê o seu design à 1h da manhã sem reclamar. É uma parceira de treino que segura um contra-argumento por tempo suficiente para você montar uma defesa de verdade. Ela aponta aquilo que você tinha passado batido. Os engenheiros que a usam bem estão, por qualquer medida honesta, mais afiados do que há dois anos. Eu uso. Você usa. O texto seria uma fraude se fingisse o contrário.

Mas a gente cometeu um erro de categoria discreto. Achamos que o atrito da engenharia de software era só um limite de velocidade. Não era.

O atrito não só nos atrasava. Ele sustentava a estrutura. Era um mapa topográfico em tempo real mostrando onde moravam os problemas difíceis. Otimizamos o atrito para fora e, sem querer, apagamos o mapa.

Quando um problema era difícil de verdade, você passava três horas encarando a parede, suando diante do quadro branco e questionando suas escolhas de carreira. O atrito era uma bússola. O mesmo atrito que tornava o trabalho miserável era o que obrigava você a montar o modelo na cabeça: a semântica do write-through, os modos de falha, a janela de leitura após escrita. Você segurava tudo isso no crânio até conseguir defender o design sem o documento aberto.

O modelo alucina em doze segundos um documento de arquitetura perfeitamente formatado e sintaticamente doce. Você não ganha atrito. Ganha uma dose de dopamina e uma mentira. Você tem a resposta. Não tem o músculo.

O eixo quebrado

Uma organização de engenharia é um problema de amostragem. Você não consegue vigiar cada tecla digitada, então lê os artefatos e deduz a cognição. Pull requests, design docs, postmortems, uma revisão de incidente de vez em quando. Esses são os instrumentos de amostragem. Avaliações de desempenho, calibração, critérios de promoção e processos seletivos se apoiam na suposição de que o artefato e a cognição vêm do mesmo lugar.

A IA partiu o eixo que ligava essas duas rodas.

O resultado agora é uma função de três variáveis, o engenheiro, o modelo e o prompt, e os artefatos contam sobre as três misturadas, sem jeito de separar o sinal. Um PR polido é compatível com um engenheiro atencioso, com um engenheiro desatento ou com uma aba que alguém deixou aberta no trem. O artefato continua chegando no prazo. Só não carrega mais o sinal que você precisa ler nele.

Isso pesa mais para os engenheiros que você está tentando formar. Um sênior que produz resultado fluente com IA está, no pior caso, alavancado. O músculo já existe, o modelo só está dirigindo o teclado. Um júnior que produz o mesmo resultado o faz sem nunca construir o músculo que o trabalho deveria construir. Ele entrega o write-through cache sem nunca modelar o que acontece quando o nó cai. Entrega a réplica de leitura para analytics sem nunca ter encarado a janela de consistência. O artefato está bom. A intuição de arquitetura que deveria crescer por baixo dele nunca apareceu.

O paradoxo do METR

Aqui está um número que deveria estar na cara dos líderes de engenharia. O METR fez um estudo cuidadoso em 2025. Desenvolvedores experientes usando assistência de IA concluíram tarefas 19% mais devagar do que sem ela, achando que estavam 20% mais rápidos.¹ Já os juniores em código desconhecido, no trabalho separado da McKinsey, andam no sentido oposto: de 26 a 39% mais rápidos.²

O gradiente corre na direção errada para um organograma. Por que os juniores parecem engenheiros 10x enquanto os sêniores parecem estagnados?

Os sêniores não estão piores com IA. O trabalho em que a IA ajuda não é o trabalho que eles faziam. O gargalo deles nunca foi digitar, era decidir o que digitar. Os juniores parecem rápidos porque o gargalo deles era digitar, e agora digitar é de graça. A função de produção não só melhorou. Ela mudou de lugar. Saiu do artefato por completo. Os juniores estão produzindo resultado com cara de sênior. Não estão, por nenhum sinal mensurável, construindo julgamento de sênior.

Os juniores fecham tickets tão rápido que o quadro do Jira parece um caça-níquel pagando prêmio. O dashboard diz que eles estão 39% mais rápidos. O dashboard está em êxtase. O dashboard, no entanto, não vai ter que manter a máquina de estados que eles acabaram de inventar.

Três coisas dando errado dentro da sua cabeça

Três mecanismos psicológicos disparam ao mesmo tempo quando você lê um resultado fluente de IA e o chama de pensamento seu. Estão documentados, têm décadas e não envelheceram.

A ilusão de fluência. As pessoas julgam o quanto entendem uma coisa pela facilidade com que ela vem à mente.³ A saída da IA é facílima. Polida, confiante, estruturada exatamente no nível que você consegue absorver. Lê-la produz a sensação morna de entender, sem o trabalho que normalmente produz essa sensação.

O calorzinho de entender é o bug.

O sinal de esforço perdido. Durante a maior parte da sua carreira, isto foi difícil era um bom indicador de estou fazendo cognição de verdade. O atrito fazia a calibragem por você. Com o modelo no circuito, a cognição foi terceirizada, mas o indicador não foi recalibrado. Você entrega a coisa, pareceu fácil, você assume que era simples, quando talvez só signifique que você não pensou.

A deriva de autoria. A pesquisa sobre monitoramento de fonte tem quarenta anos. As pessoas não conseguem distinguir de forma confiável as ideias que geraram das ideias que receberam por sugestão.⁴ Até quinta-feira, a deriva está completa. O engenheiro olha para um bloco de regex de 400 linhas que ele “fez em par” com o modelo e pensa, sinceramente: Ah, sim, lembro de ter caprichado naquele negative lookbehind. Não caprichou. Você pediu à caixa de prompt para fazer os caracteres ruins sumirem e aceitou o primeiro trecho que não deu erro.

A pergunta do cache cai bem aqui dentro. O engenheiro escreveu a camada de write-through com um modelo no circuito. Pareceu fácil. O código compila. Os testes passam. Mas ele nunca parou para pensar no que acontece com a escrita em andamento quando o nó cai. Nunca pensou no que o banco vê quando o cache volta em manada, nem no que o caminho de leitura devolve durante o aquecimento. Não tem modelo mental de onde recuperar nada quando alguém pergunta. Não há nada de errado com o código. Há nada na cabeça do engenheiro.

A introspecção parou de funcionar

O efeito combinado é a parte que deveria tirar o seu sono.

O engenheiro que passou da extensão para a substituição não está mentindo quando diz que pensou a fundo. Ele se sentiu fluente. O trabalho pareceu fácil do jeito que parece fácil o trabalho bem entendido. Ele lembra do raciocínio como seu.

O relato introspectivo não é confiável. O artefato não é confiável.

Sobra o que ele consegue fazer, a frio, quando você pergunta.

Ceticismo não é desconfiar da IA

Ceticismo, nesse contexto, não é desconfiança da IA. É desconfiança do sinal de fluência. É a disciplina de separar consigo ler isto e sinto que entendo de consigo produzir isto do zero amanhã de manhã. As duas coisas eram mais ou menos a mesma. Não são mais.

Esse é o movimento que precisa acontecer primeiro, na cabeça do próprio engenheiro, antes que qualquer gestor consiga fazer algo útil com ele. Se o engenheiro não consegue aplicá-lo a si mesmo, nenhum processo de revisão vai salvá-lo.

Como é o ceticismo aplicado a você mesmo

Reprodução a frio. Feche o notebook. Vá até o quadro branco. Reproduza o design de memória, incluindo as alternativas que você descartou. A pausa antes de começar é o dado.
Autoquestionamento adversarial. Escolha a suposição que mais incomoda você e tente quebrá-la sem acionar o prompt de novo. Se o seu primeiro movimento é abrir o chat, você já tem a resposta.
O teste do 10x. O que mudaria se a suposição de carga mudasse 10x? Se a sua resposta é eu perguntaria ao modelo, o modelo é o dono do design, não você.

E ainda tem a versão da pergunta do cache que você faz a si mesmo, na sua cabeça, sentado na sua cozinha tarde da noite:

Me explica por que eu descartei uma fila de mensagens aqui. Peraí. Será que eu descartei? Ou o modelo só não mencionou? Peraí, eu sou o modelo?

Uma vez por semana, anote as decisões que você tomou em três colunas: suas, do modelo e impossíveis de separar. A terceira é a interessante. Ela não deveria ser a maior.

A versão do gestor

O trabalho do gerente de engenharia não é mais acompanhar velocidade. É sondar profundidade.

A revisão por conversa é o instrumento que falta. O dado de que a organização realmente precisa, três momentos por trimestre em que esse engenheiro defendeu uma decisão não trivial sob questionamento ao vivo, não está na agenda de ninguém, no template de avaliação de ninguém, em nenhum dashboard. Ele só existe na sala, e só se alguém na sala pensou em perguntar.

A troca que você deve procurar ouvir:

“Me explica por que você escolheu esta estratégia específica de indexação do banco.”

Silêncio.

“Tá, então me explica o que é um índice.”

Silêncio mais longo.

Se um engenheiro não consegue defender o design com o notebook fechado, ele não escreveu o design.

A contratação mudou

A terceira superfície que isso atinge é a contratação, e é onde as consequências chegam mais rápido.

Eu presumo que todo candidato usa IA. O currículo está ótimo, o desafio para fazer em casa está limpo, e nada disso é sinal hoje em dia. Parei de sondar perfeição de sintaxe ou habilidade de depuração: o modelo faz as duas coisas, e o candidato sabe que eu sei.

O que eu sondo agora é a tomada de decisão à frente do modelo. O candidato que, ao ser pedido para desenhar algo, diz “preciso disso, mas sei que isso vai acontecer, e se o tráfego dobrar isto aqui cai, então eu faria aquilo” é o candidato que construiu o músculo. O candidato que reproduz um design limpo mas não sabe me dizer o que quebra a 10x é o candidato que o modelo carregou pelo desafio.

A outra coisa que eu sondo é a parte do sistema que o modelo não enxerga. O cluster que escala na horizontal por trás do serviço. O cache que mora no repositório de outro time. O consumidor downstream que vai engolir em silêncio um evento malformado durante seis semanas antes de acionar alguém. O modelo é brilhante dentro do código que está à frente dele. É cego para o sistema em volta. O candidato que só trabalhou em par com o modelo também é.

Não adianta fingir: eles vão usar IA. A entrevista deixou de ser sobre saber se o candidato consegue produzir uma função. É sobre saber se ele consegue manter o sistema na cabeça.

O problema de três anos

Se o sistema não enxerga, não consegue avaliar. Se não consegue avaliar, não consegue promover por isso. Se não consegue promover por isso, para de selecionar por isso.

Então vamos promover por velocidade. Vamos formar uma geração inteira de engenheiros staff que entregam qualquer coisa e não defendem nada. Os gráficos de burndown vão ser lindos. Os gráficos de burndown vão ser a única coisa que não está pegando fogo.

Os engenheiros sêniores capazes de defender um design sob questionamento não terão sumido, mas nunca foram contratados. Os sucessores deles parecem iguais no dashboard. Só não conseguem responder à pergunta.

Agora vire isso contra este texto

Você está concordando com a cabeça. O argumento parece certo. A lógica se encaixou.

Mas lembre do bug: o calorzinho não é prova de que o argumento está certo.

Este texto começou como uma discordância de AI should elevate your thinking, not replace it, de Koshy John, que faz a versão de virtude pessoal deste argumento. Ele está quase todo certo. Partes deste ensaio foram levantadas num brainstorm com um modelo. Alguns trechos vieram fácil demais. Há frases aqui que eu, perguntado a frio amanhã, teria dificuldade de reproduzir do mesmo jeito.

Eu sou um gênio por ter articulado isto, ou só apertei Regenerate até o robô soar cínico o bastante?

Amanhã de manhã, feche o notebook e tente reproduzir esta tese de memória. Percorra as três variáveis que partiram o eixo. Percorra a diferença entre o argumento de Koshy John e este.

Se não conseguir, você não pensou. Só leu.

Mas o cache

Daqui a três anos, os nossos dashboards de engenharia vão estar todos verdes. A velocidade vai estar nas alturas. A organização vai parecer impecável no papel.

O cache, no entanto, vai estar pegando fogo.

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, julho de 2025. ↩
McKinsey, Unleashing developer productivity with generative AI, 2023. Relata ganhos na conclusão de tarefas para desenvolvedores menos experientes na faixa de 26 a 39%, dependendo do tipo de tarefa. ↩
Ver Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. O efeito de tratar fluência como indicador de entendimento se sustenta em décadas de pesquisa. ↩
Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. A síntese fundadora. O resultado foi replicado e estendido a contextos de coautoria entre humano e IA nos últimos anos. ↩