Como sabes quem está a pensar?

Neste momento, na tua equipa, há pelo menos um engenheiro a entregar trabalho que não saberia reproduzir num quadro branco.

O código compila. Os testes passam. O PR está impecável. Só que o raciocínio nunca foi dele, e ele não sabe. Por dentro, pedir um pensamento emprestado sente-se exatamente como ter um.

Vais descobri-lo da próxima vez que alguém fizer a pergunta da cache. O diagrama de arquitetura está no ecrã, o desenho parece limpo, e um engenheiro sénior inclina-se para a frente:

Explica-me porque é que descartaste uma cache write-through aqui. O que acontece quando este nó em concreto reinicia sob carga?

A pausa que se segue devia ser uma pausa de recuperação: o engenheiro a ir buscar ao seu próprio modelo mental a restrição que tinha considerado, a alternativa que tinha pesado, o efeito de segunda ordem que acompanhava quando tomou a decisão.

Hoje, a pausa é um vazio.

O atrito era estrutural

Isto não é um elogio fúnebre aos velhos tempos de andar às cavadelas no Stack Overflow.

A IA é um multiplicador fantástico. É um revisor incansável da meia-noite que lê o teu desenho à 1 da manhã sem se queixar. É um parceiro de treino que aguenta um contra-argumento o tempo suficiente para montares uma defesa a sério. Diz-te aquilo que tinhas passado por cima. Os engenheiros que a usam bem estão, por qualquer medida honesta, mais afiados do que há dois anos. Eu uso-a. Tu usas. Este texto seria uma fraude se fingisse o contrário.

Mas cometemos um erro de categoria discreto. Assumimos que o atrito da engenharia de software era só um limite de velocidade. Não era.

O atrito não nos fazia só andar mais devagar. Era estrutural. Era um mapa topográfico em tempo real a dizer-te onde viviam os problemas difíceis. Otimizámos o atrito e apagámos o mapa sem querer.

Quando um problema era mesmo difícil, passavas três horas a olhar para uma parede, a suar sobre um quadro branco e a questionar a tua carreira. O atrito era uma bússola. O mesmo atrito que tornava o trabalho miserável era o que te obrigava a construir o modelo na cabeça: a semântica do write-through, os modos de falha, a janela de leitura depois da escrita. Guardavas tudo isso no crânio até conseguires defender o desenho sem o documento aberto.

O modelo alucina em doze segundos um documento de arquitetura perfeitamente formatado e sintaticamente doce. Não recebes atrito. Recebes uma dose de dopamina e uma mentira. Tens a resposta. Não tens o músculo.

O eixo partido

Uma organização de engenharia é um problema de amostragem. Não podes vigiar cada tecla, por isso lês os artefactos e deduzes a cognição. Pull requests, documentos de desenho, post-mortems, a revisão de incidente ocasional. Estes são os instrumentos de amostragem. As avaliações de desempenho, a calibração, os critérios de promoção e os processos de contratação assentam todos no pressuposto de que o artefacto e a cognição vêm do mesmo sítio.

A IA partiu o eixo que ligava essas duas rodas.

O resultado é agora função de três variáveis (o engenheiro, o modelo e o prompt) e os artefactos falam-te das três ao mesmo tempo, misturadas, sem maneira de separar o sinal. Um PR polido é compatível com um engenheiro ponderado, com um engenheiro pouco ponderado ou com um separador que alguém deixou aberto no comboio. O artefacto continua a chegar a horas. Só que já não traz o sinal que precisas de ler nele.

Isto pesa mais nos engenheiros que estás a tentar fazer crescer. Um sénior que produz resultado fluente com IA está, na pior das hipóteses, alavancado. O músculo já está construído e o modelo só conduz o teclado. Um júnior que produz o mesmo resultado produz-no sem nunca ter construído o músculo que o trabalho devia construir. Entrega a cache write-through sem nunca ter modelado o que acontece quando o nó cai. Entrega a réplica de leitura para análise sem nunca ter estado com a janela de consistência. O artefacto está bem. A intuição de arquitetura que devia crescer por baixo dele nunca apareceu.

O paradoxo da METR

Aqui está um número que devia estar a olhar de frente para os líderes de engenharia. A METR fez um estudo cuidadoso em 2025. Programadores experientes que usaram assistência de IA concluíram as tarefas 19% mais devagar do que sem ela, convencidos de que eram 20% mais rápidos.¹ Os júniores em código que não conhecem, no trabalho independente da McKinsey, vão no sentido oposto: 26 a 39% mais rápidos.²

O gradiente vai ao contrário do que um organigrama pede. Porque é que os júniores parecem engenheiros 10x e os séniores parecem iguais?

Os séniores não são piores com a IA. O trabalho em que a IA ajuda não é o trabalho que eles estavam a fazer. O gargalo deles nunca foi escrever, foi decidir o que escrever. Os júniores parecem rápidos porque o gargalo deles era escrever, e agora escrever é grátis. A função de produção não melhorou apenas. Mudou de sítio. Saiu por completo do artefacto. Os júniores produzem resultado com ar de sénior. Não estão, por nenhum sinal mensurável, a construir juízo de sénior.

Os júniores fecham tarefas tão depressa que o quadro do Jira parece uma slot machine a pagar prémios. O painel diz que são 39% mais rápidos. O painel está encantado. O painel, no entanto, não tem de manter a máquina de estados que eles acabaram de inventar.

Três coisas a correr mal dentro da tua cabeça

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

A ilusão da fluência. As pessoas julgam o quanto percebem de uma coisa pela facilidade com que ela lhes vem à cabeça.³ O resultado da IA é facílimo. Polido, confiante, estruturado exatamente ao nível que consegues absorver. Lê-lo dá-te a sensação cálida de perceber, sem o trabalho que costuma produzir essa sensação.

O calor de perceber é o bug.

O sinal de esforço perdido. Durante a maior parte da tua carreira, isto custou-me servia de indicador útil de estou a fazer cognição a sério. O atrito fazia a calibração por ti. Com o modelo no ciclo, a cognição é delegada mas o indicador não é recalibrado. Entregas a coisa, foi fácil, assumes que isso quer dizer que era simples, quando pode querer dizer que não pensaste.

A deriva de autoria. A investigação sobre monitorização da fonte tem quarenta anos. As pessoas não conseguem distinguir de forma fiável as ideias que geraram das ideias que lhes foram sugeridas.⁴ Na quinta-feira, a deriva está completa. O engenheiro olha para um bloco de 400 linhas de regex que “fez em par” com o modelo e pensa, sinceramente, Ah pois, lembro-me de ter trabalhado com tanto cuidado naquele lookbehind negativo. Não trabalhaste. Pediste à caixa de prompt que fizesse desaparecer os caracteres maus e aceitaste o primeiro excerto que não deu erro.

A pergunta da cache cai aqui dentro. O engenheiro escreveu a camada write-through com um modelo no ciclo. Foi fácil. O código compila. Os testes passam. Mas nunca esteve com o que acontece à escrita em curso quando o nó cai. Nunca esteve com o que a base de dados vê quando a cache volta em debandada, nem com o que o caminho de leitura devolve durante o aquecimento. Não tem um modelo mental de onde ir buscar a resposta quando alguém pergunta. Não há nada de errado com o código. Não há nada na cabeça do engenheiro.

A introspeção deixou de funcionar

O efeito combinado é a parte que devia tirar-te o sono.

O engenheiro que passou da extensão para a substituição não está a mentir quando diz que pensou nisto. Sentiu-se fluente. O trabalho pareceu fácil da maneira como o trabalho bem compreendido parece fácil. Lembra-se do raciocínio como seu.

O relato introspetivo não é fiável. O artefacto não é fiável.

Resta o que ele consegue fazer, a frio, quando lhe perguntas.

Ceticismo não é desconfiar da IA

O ceticismo, neste contexto, não é desconfiança da IA. É desconfiança do sinal de fluência. É a disciplina de separar consigo ler isto e sinto que percebo de consigo produzir isto do zero amanhã de manhã. Isto costumava ser quase a mesma coisa. Já não é.

Este é o passo que tem de acontecer primeiro, na cabeça do próprio engenheiro, antes de qualquer gestor poder fazer algo útil com ele. Se o engenheiro não o consegue aplicar a si mesmo, nenhum processo de revisão o vai salvar.

O ceticismo, aplicado a ti

Reprodução a frio. Fecha o portátil. Vai ao quadro branco. Reproduz o desenho de memória, incluindo as alternativas que descartaste. A pausa antes de começares é o dado.
Autoquestionamento adversarial. Escolhe o pressuposto com que te sentes menos à vontade e tenta parti-lo sem voltar a fazer prompt. Se o teu primeiro gesto é abrir o chat, já tens a tua resposta.
O teste dos 10x. O que mudaria se o pressuposto de carga se alterasse 10 vezes? Se a tua resposta é perguntava ao modelo, o desenho é do modelo, não teu.

E depois há a versão da pergunta da cache que fazes a ti próprio, na tua cabeça, sentado na tua cozinha a altas horas:

Explica-me porque é que descartei uma fila de mensagens aqui. Espera. Descartei mesmo? Ou o modelo é que não a mencionou? Espera, eu sou o modelo?

Uma vez por semana, escreve as decisões que tomaste em três colunas: tuas, do modelo, e não consigo separar. O terceiro balde é o interessante. Não devia ser o maior.

A versão do gestor

O trabalho do gestor de engenharia já não é acompanhar a velocidade. É sondar a profundidade.

A revisão por conversa é o instrumento em falta. Os dados de que a organização precisa a sério, três momentos por trimestre em que este engenheiro defendeu uma decisão não trivial sob questionamento ao vivo, não estão na agenda de ninguém, no modelo de avaliação de ninguém, em nenhum painel. Existem só na sala, e só se alguém na sala se lembrou de perguntar.

A troca a que deves estar atento:

“Explica-me porque escolheste esta estratégia de indexação da base de dados.”

Silêncio.

“Está bem, explica-me o que é um índice.”

Silêncio mais longo.

Se um engenheiro não consegue defender o desenho com o portátil fechado, não foi ele que o escreveu.

A contratação mudou

A terceira superfície onde isto aterra é a contratação, e é onde as consequências chegam mais depressa.

Parto do princípio de que todos os candidatos usam IA. O CV é ótimo, o exercício para casa está limpo, e nada disso é já um sinal. Deixei de sondar a perfeição da sintaxe ou a capacidade de depurar: o modelo faz as duas coisas, e o candidato sabe que eu sei.

Agora sondo a tomada de decisão à frente do modelo. O candidato que, a quem se pede que desenhe algo, diz “preciso disto, mas sei que vai acontecer aquilo, e se o tráfego duplicar isto cai aqui, por isso na verdade faria assim” é o candidato que construiu o músculo. O candidato que reproduz um desenho limpo mas não me sabe dizer o que parte aos 10x é o candidato que o modelo levou ao colo durante o exercício para casa.

A outra coisa que sondo é a parte do sistema que o modelo não vê. O cluster de escala horizontal por trás do serviço. A cache que vive no repositório de outra equipa. O consumidor a jusante que engole em silêncio um evento malformado durante seis semanas antes de alguém ser chamado. O modelo é brilhante dentro do código que tem à frente. É cego ao sistema à volta. O candidato que só alguma vez trabalhou em par com o modelo também.

Não vale fingir: vão usar IA. A entrevista já não é sobre se conseguem produzir uma função. É sobre se conseguem ter o sistema na cabeça.

O problema dos três anos

Se o sistema não o consegue ver, não o consegue avaliar. Se não o consegue avaliar, não pode promover por isso. Se não pode promover por isso, deixa de o selecionar.

Por isso vamos promover pela velocidade. Vamos construir uma geração inteira de engenheiros staff que conseguem entregar 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á neste momento a arder.

Os engenheiros séniores que sabem defender um desenho sob questionamento não terão desaparecido: nunca chegaram a ser contratados. Os sucessores deles são iguais no painel. Só não sabem responder à pergunta.

Vira isto contra o texto

Estás a acenar que sim. O argumento parece certo. A lógica encaixou.

Mas lembra-te do bug: o calor não é prova de que o argumento está certo.

Este texto começou como uma discordância do AI should elevate your thinking, not replace it, de Koshy John, que faz a versão de virtude pessoal deste argumento. Ele tem quase toda a razão. Partes deste ensaio foram pensadas com um modelo. Algumas formulações chegaram fáceis demais. Há aqui frases que eu, se me perguntassem a frio amanhã, teria dificuldade em reproduzir da mesma forma.

Serei um génio por ter articulado isto, ou limitei-me a carregar em Regenerar até o robô soar cínico o suficiente?

Amanhã de manhã, fecha o portátil e tenta reproduzir esta tese de memória. Percorre as três variáveis que partiram o eixo. Percorre a diferença entre o argumento de Koshy John e este.

Se não consegues, não a pensaste. Só a leste.

A cache, no entanto

Daqui a três anos, os nossos painéis de engenharia vão estar todos verdes. A velocidade vai estar pelos ares. A organização vai parecer impecável no papel.

A cache, no entanto, vai estar a arder.

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. Reporta ganhos na conclusão de tarefas para programadores menos experientes na ordem dos 26 a 39%, consoante o tipo de tarefa. ↩
Ver Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. O efeito da fluência como indicador de compreensão é robusto ao longo de décadas de trabalho. ↩
Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. A síntese fundacional. O resultado foi replicado e estendido a contextos de coautoria entre humanos e IA nos últimos anos. ↩