Nota do autor: a partir das ideias de Addy Osmani sobre “rendição cognitiva” e “dívida de compreensão”, reuni uma lista de verificação e um modelo de comando para usar antes de fazer o merge de um PR. Também comparo essa abordagem com a revisão baseada em relatórios de aceitação de dependências do LobeHub, para ajudar você a escolher a intensidade da revisão conforme o risco.
Se você entrega código todos os dias usando Claude Code, Cursor ou Cline, talvez já tenha passado por isso: um agente entrega em poucos minutos um PR com centenas de linhas, nomes padronizados, estrutura clara e todos os testes passando. Então você clica em “Aprovar”. Algumas semanas depois, alguém pergunta por que aquela lógica foi escrita daquela forma, e você não sabe responder. Este artigo traz ações práticas de verificação, como pedir à IA que faça perguntas para testar seu entendimento, para ajudar você a se responsabilizar por cada alteração aprovada, sem precisar revisar linha por linha.
Este artigo não é um convite para você voltar a escrever código à mão. O próprio engenheiro do Claude Code Addy Osmani deixa claro que ninguém espera que uma pessoa engenheira memorize toda a base de código. A questão não é ler ou não cada linha, mas saber o que você entende e o que não entende.
O que você vai aprender: ao final, você entenderá a progressão entre “terceirização cognitiva”, “cessão de julgamento” e “rendição cognitiva”, terá uma lista de perguntas e um modelo de comando para copiar e usar antes do merge e saberá escolher a intensidade da revisão conforme o risco da alteração.
Não dê aval automático ao agente: os pontos centrais da dívida de compreensão
Segundo uma reportagem do QbitAI, reproduzida pelo 36Kr, Addy Osmani, ex-engenheiro do Google que hoje trabalha no Claude Code, abordou uma questão incômoda: quanto mais confiável parece o que a IA gera, menos atenção as pessoas dedicam à revisão. Ele divide esse processo em estágios progressivos e apresenta dois novos tipos de “dívida”. Vale lembrar que os conceitos abaixo vêm da cobertura da imprensa; para a formulação exata, consulte o texto original de Addy.
| Conceito | Significado | Exemplo típico |
|---|---|---|
| Terceirização cognitiva | Delegar uma tarefa específica à IA, mas continuar entendendo o trabalho e sabendo avaliar o resultado | Pedir ao agente que escreva código repetitivo, sabendo exatamente o que ele faz |
| Transferência de julgamento | As respostas da IA passam a ser a base padrão para as próximas etapas do trabalho | Na segunda vez, você só passa os olhos e segue o que o agente sugeriu |
| Rendição cognitiva | Delegar até mesmo decisões que deveriam ser suas | “Se a IA disse, deve estar certo”: todos os testes passaram, então é só fazer o merge |
| Dívida de compreensão | A complexidade do código e do sistema cresce, mas o entendimento dos desenvolvedores não acompanha | Na hora de alterar uma funcionalidade, ninguém entende direito a estrutura interna |
| Dívida de intenção | A IA decide por você objetivos, restrições e compromissos que não ficaram claros nos requisitos | Você não sabe exatamente o que quer, mas o agente entrega um produto aparentemente convincente |
Como a rendição cognitiva evolui até gerar dívida de compreensão
A rendição cognitiva não acontece da noite para o dia. No começo, você apenas delega tarefas específicas, e isso não é um problema em si — assim como usar um compilador em vez de escrever assembly à mão. O perigo está no segundo estágio: depois que o agente entrega resultados confiáveis algumas vezes seguidas, suas conclusões passam, silenciosamente, a ser aceitas como premissas, e você começa a pular a verificação. No terceiro estágio, o botão de “aprovar” vira um carimbo: seu papel deixa de ser o de engenheiro e passa a ser o de alguém que só dá o aval.
Addy deu um exemplo bem típico: o agente entrega 600 linhas de código de uma vez, com uma estrutura clara e todos os testes passando. O desenvolvedor fica tranquilo e faz o merge. Mas o agente pode ter alterado discretamente a ordem de processamento de transações ou ajustado alguma condição de contorno. Essas mudanças não causam erros naquele momento. Só quando o sistema apresenta um problema de verdade é que o desenvolvedor percebe que não consegue explicar por que o código funciona daquela maneira. Esses são os “juros” da dívida de compreensão, que sempre vencem na pior hora.
A dívida de intenção surge ainda mais cedo no processo. Os agentes atuais são tão bons em preencher lacunas nos requisitos que, mesmo quando você não pensou tudo até o fim, conseguem entregar algo que parece bastante razoável. O problema é que os objetivos, o escopo e as concessões que você não definiu claramente já foram decididos pela IA, sem alarde. As dívidas de intenção e de compreensão costumam se acumular: você não sabe ao certo o que queria no início nem entende o que o agente acabou fazendo.
6 maneiras de quitar a dívida de compreensão
Addy compartilhou várias sugestões práticas em seu artigo. Abaixo, elas estão organizadas em 6 métodos, com o tipo de dívida que cada um ajuda a quitar e a etapa do fluxo de trabalho em que deve ser usado.
| Método | Quando usar | Principal dívida | Ação em uma frase |
|---|---|---|---|
| 1. Peça ao agente para testar você | Depois de uma grande alteração, antes de fazer o merge | Dívida de compreensão | Peça um resumo das alterações e dos motivos, depois responda às perguntas; só faça o merge se acertar todas |
| 2. Escreva uma lista de requisitos antes de começar | Antes de escrever o comando | Dívida de intenção | Deixe claro para quem é, qual problema resolve, o que não fará e quais são os critérios de conclusão |
| 3. Questione decisões não autorizadas | Ao final de tarefas longas | Dívida de compreensão, dívida de intenção | Pergunte quais decisões ele tomou sem sua autorização e em quais suposições se baseou |
| 4. Pergunte o que não foi testado | Ao analisar os resultados dos testes | Dívida de compreensão | Veja primeiro os testes executados e seus resultados, depois leia o resumo da IA |
| 5. Guarde os materiais originais | Quando vários agentes trabalham em paralelo | Dívida de compreensão | Em tarefas importantes, guarde os materiais originais e as evidências de validação; se não der conta de revisar, reduza o paralelismo |
| 6. Pratique offline regularmente | Toda semana e todo mês | Deterioração de habilidades | Programe sem depender de agentes uma vez por semana e avalie mensalmente quais habilidades você terceirizou |
Peça à IA para testar você: a principal forma de verificar sua dívida de compreensão
Esta é a estratégia mais interessante do conjunto. Depois que o agente concluir uma grande alteração, não se apresse em aprová-la. Peça que ele faça o papel de avaliador: resuma o que mudou e por quê, e depois crie algumas perguntas sobre as alterações. Estabeleça uma regra: o merge só acontece se você acertar todas. A vantagem é transformar aquela sensação vaga de “acho que entendi” em algo verificável. As perguntas que você não conseguir responder mostram exatamente onde está sua dívida de compreensão.
Questione decisões não autorizadas e o que não foi testado
Em tarefas longas, o agente pode escolher parâmetros padrão, ajustar o escopo da implementação e até fazer escolhas quando há conflitos entre requisitos. Essas decisões nem sempre aparecem no resumo final, porque parecem “naturais demais”. Por isso, em vez de perguntar apenas “terminou?”, é mais eficaz ir além: quais decisões você tomou sem minha autorização explícita? Em quais pontos você se baseou em suas próprias suposições? O que ainda não foi verificado? Quais alterações podem afetar outras funcionalidades?
O mesmo vale para os testes. Addy lembra que testes passando só comprovam que as condições cobertas foram atendidas. Se os casos de borda não estiverem nos testes, o relatório ainda pode parecer ótimo. A ordem certa é verificar primeiro quais testes foram executados e quais resultados retornaram, para só depois ler o resumo gerado pela IA. Em alterações de alto risco, você também pode pedir a outro agente que procure problemas de forma independente e sob outra perspectiva.
Guia rápido de verificação antes do merge: 5 passos para não aprovar tudo que o Agent faz
Juntando os métodos anteriores, temos um processo que pode ser seguido antes do merge de cada PR. Ele não exige uma revisão linha por linha, mas pede que você pense ativamente em cada etapa.
- Escreva suas expectativas antes de começar: descreva com suas próprias palavras os requisitos e o que você espera que aconteça. Se, depois de duas rodadas de ajustes no comando, o resultado ainda não for satisfatório, volte a organizar os requisitos em vez de continuar adicionando instruções.
- Peça uma explicação das decisões: ao fim da tarefa, peça ao Agent que liste as decisões não autorizadas, as suposições e os pontos que não foram verificados.
- Confira os testes reais: veja os comandos de teste executados e seus resultados. Pergunte quais casos-limite ficaram de fora.
- Peça ao Agent que faça perguntas: faça um teste com perguntas baseadas no diff e volte ao código para entender os pontos em que errar.
- Procure algo que tenha passado despercebido: depois que o Agent entregar o trabalho, identifique pelo menos um ponto que ele talvez não tenha verificado.
Exemplo simples de comando para avaliar a dívida de compreensão
Este é o comando mais usado para pedir um teste. Você pode colá-lo diretamente na conversa com o Claude Code, Cursor ou Cline:
在我合并这次改动之前，请先做两件事：
1. 用不超过 10 条要点总结本次改了哪些文件、每处改动的原因。
2. 根据本次 diff 给我出 5 道题，重点覆盖：事务/调用顺序、
边界条件、错误处理、对其他模块的影响。
先只给题目，等我作答后再批改，并指出我答错的地方对应哪段代码。
规则：我没有全部答对之前，不要建议合并。
Veja o modelo completo de comando para perguntas antes do merge
# 阶段 A：开工前（偿还意图债，由我先填写）
需求说明：
- 面向谁：
- 要解决的问题：
- 明确不做的事：
- 完成标准（做到什么程度算完成）：
- 我预期的改动范围和结果：
# 阶段 B：任务结束后（请 Agent 逐条回答）
1. 你做了哪些我没有明确授权的决定？请列出决定内容和理由。
2. 哪些地方依赖了你自己的假设？假设不成立时会发生什么？
3. 还有哪些内容没有验证？
4. 哪些改动可能影响其他功能或模块？
5. 你实际运行了哪些测试命令？请贴出原始输出，而不是总结。
6. 哪些边界情况没有写进测试？
# 阶段 C：出题考核（偿还理解债）
请根据本次 diff 出 5 道题，先只给题目。
我作答后请批改，答错的题请定位到具体代码行。
我未全部答对前，不要建议合并。
# 阶段 D：高风险改动追加（可交给另一个独立会话）
请你作为独立审查者，不参考上一个会话的总结，
只基于原始需求和 diff，找出最可能出问题的 3 个地方。
🎯 Dica de uso: preencha a etapa A você mesmo antes de começar, em vez de pedir ao Agent que faça isso. Para a etapa D, abra uma nova sessão para evitar que o revisor independente seja influenciado pelo resumo do Agent anterior. Isso também reforça o alerta de Addy sobre a perda de informações na comunicação entre vários Agents.
Checklist rápido de perguntas antes do merge
| Etapa | Perguntas essenciais | Sinais de alerta |
|---|---|---|
| Antes de começar | Consigo explicar o requisito e os critérios de conclusão com minhas próprias palavras? | Não consegue definir o que está fora do escopo |
| Após a entrega | Quais decisões o agente tomou sem autorização? | Responde “nenhuma”, mas o diff claramente ultrapassa o escopo |
| Testes | Quais testes foram executados? O que não foi testado? | Há apenas um resumo, sem a saída original |
| Avaliação | Se alguém me fizer perguntas, consigo acertar todas? | Erra perguntas sobre a ordem das transações ou condições de contorno |
| Finalização | Consigo identificar algo que o agente deixou de verificar? | Não consegue pensar em nada |
AI faz perguntas para testar você versus revisão por relatório de aceitação
Uma abordagem bem diferente vem da LobeHub, plataforma open source de colaboração entre agentes com cerca de 84 mil estrelas no GitHub. Segundo o laboratório Baijing, a equipe afirma que “quase não olha mais o código” e se concentra nos relatórios multimodais de aceitação dos agentes. Para isso, usa o Acceptance, uma ferramenta própria que teve o código aberto em setembro deste ano. Antes da entrega, o agente divide os requisitos em itens de verificação diretamente observáveis, testa cada um no produto real e reúne capturas de tela, gravações e logs em um relatório online. A pessoa pode aprovar tudo de uma vez ou devolver itens específicos para correção.
| Dimensão | AI faz perguntas para testar você | Revisão por relatório de aceitação |
|---|---|---|
| Foco | Lógica interna do código, decisões não autorizadas e pressupostos | Comportamento externo observável do produto |
| Forma das evidências | Perguntas, respostas e resultados da correção | Capturas de tela, gravações, logs e registros de comandos |
| Problemas que pode identificar | Ordem das transações, condições de contorno e escolhas implícitas | Se a interface, as interações e as funcionalidades atendem aos requisitos |
| Problemas que podem passar despercebidos | Questões que você não pensou em formular | Lógica interna não visível e riscos arquiteturais |
| Pré-requisitos | Disposição do desenvolvedor para dedicar tempo à compreensão | Requisitos divisíveis em itens de verificação observáveis e um ambiente de execução automatizada |
| Papel da pessoa | Entender e assumir a responsabilidade pelas mudanças específicas | Definir os critérios de aceitação e tomar a decisão final |
Comparação das duas abordagens de revisão
Revisão por relatório de aceitação: o relatório é muito eficiente para verificar comportamentos observáveis, e o feedback de devolução pode apontar um único item. No teste descrito pela reportagem, a pessoa responsável pela revisão devolveu apenas o item do fundo escuro. O agente alterou uma única linha de CSS, sem modificar os outros arquivos. A abordagem, porém, depende de requisitos que possam ser divididos em itens de verificação observáveis. A reportagem também ressalta que, em tarefas mais complexas, segurança, arquitetura e qualidade final ainda exigem julgamento humano, e que algumas etapas do envio de feedback ainda precisam de intervenção manual. A afirmação de que a equipe “quase não olha mais o código” é um relato da própria equipe, sem verificação independente.
Perguntas para testar você: essa abordagem é mais eficaz para expor problemas que “não aparecem na interface”, como a ordem das transações e as condições de contorno, cobrindo justamente um ponto cego dos relatórios de aceitação. Seu alcance, porém, depende da qualidade das perguntas, e ela exige que o desenvolvedor realmente dedique tempo para entender o código. As duas abordagens não se excluem: faz mais sentido usar o relatório de aceitação para confirmar “foi feito corretamente?” e as perguntas para confirmar “eu entendo por que isso foi feito assim?”.
Escolha a intensidade da revisão da dívida de compreensão conforme o risco da mudança
Nem todo PR precisa passar pelo processo completo. Addy também lembra que, quando o volume de conteúdo gerado é maior do que você consegue acompanhar com responsabilidade, você já não está revisando: está apostando que não há problemas. A tabela abaixo traz uma referência por nível de risco; ajuste os limites à realidade da equipe.
| Nível de risco | Mudanças típicas | Intensidade de revisão recomendada |
|---|---|---|
| Baixo | Textos, estilos, scripts independentes, protótipos | Basta um relatório de validação ou uma verificação manual; registre o resultado esperado |
| Médio | Funcionalidades comuns de negócio, novas interfaces | Questione decisões não autorizadas + confira os resultados reais dos testes |
| Alto | Transações, permissões, pagamentos, migração de dados | Processo completo de 5 etapas + avaliação com perguntas + revisão por um agente independente |
| Acima da capacidade | Produção paralela por vários agentes, sem capacidade de revisar tudo | Adicione verificações automatizadas ou reduza o paralelismo |
💡 Como escolher: se sua equipe já tem um processo maduro de validação automatizada, concentre a avaliação com perguntas nas mudanças de alto risco. Caso contrário, mantenha a regra “só faça o merge se acertar as respostas” pelo menos nos PRs que envolvem consistência de dados e permissões.
Perguntas frequentes FAQ
Q1: O que é dívida de compreensão? Qual é a diferença em relação à dívida técnica?
A dívida de compreensão surge quando a complexidade do código e dos sistemas aumenta, mas o entendimento dos desenvolvedores não acompanha esse crescimento. A dívida técnica geralmente está ligada à baixa qualidade do código. Já a dívida de compreensão pode existir mesmo quando o código é bom: o problema é que as pessoas não o entendem, e isso só fica evidente quando precisam modificá-lo.
Q2: Qual é a diferença entre pedir à IA que faça perguntas para testar seu conhecimento e pedir que ela explique o código?
Quando a IA explica, você recebe a informação passivamente e pode acabar com a falsa impressão de que entendeu. Ao responder perguntas, você precisa participar ativamente. Os erros podem ser relacionados a trechos específicos do código, transformando uma compreensão vaga em algo verificável.
Q3: Não aprovar o trabalho do agente sem questionar significa revisar o código da IA linha por linha?
Não. Segundo relatos, a equipe do Claude Code não exige que os engenheiros memorizem toda a base de código. Quando precisam alterar alguma parte, eles usam o Claude para entender novamente a lógica relevante. O essencial é saber o que você entende e o que não entende, definindo a profundidade da revisão de acordo com o risco.
Q4: Para quais cenários de desenvolvimento esse método é adequado?
Principalmente para estes cenários:
– **Tarefas de longa duração com agentes**: podem gerar decisões não autorizadas; vale usar uma lista de perguntas de acompanhamento
– **Alterações de backend que envolvem transações e condições de contorno**: vale usar perguntas para testar o entendimento
– **Desenvolvimento paralelo com vários agentes**: vale preservar os materiais originais e controlar o número de tarefas paralelas
– **Revisão de código em equipe**: a lista de perguntas pode ser incluída no modelo de PR
Q5: Como colocar esse processo de autoavaliação da dívida de compreensão em prática no Claude Code, Cursor e Cline?
O método independe da ferramenta. O essencial são os comandos e o processo:
1. Salve o modelo completo de comando deste artigo como um trecho reutilizável pela equipe
2. Antes de começar, escreva a etapa A à mão; ao terminar a tarefa, cole as etapas B e C
3. Para alterações de alto risco, abra uma sessão independente para executar a etapa D
Você também pode incluir a regra “só fazer o merge após responder corretamente” nas verificações de PR da equipe.
Q6: Quais são as limitações conhecidas desses métodos?
É importante ser realista:
– **Dados sobre eficácia**: ainda não há dados públicos que comprovem quanto esses métodos reduzem a taxa de defeitos ou aumentam a eficiência
– **Custo de tempo**: o processo completo prolonga o ciclo de merge e não é adequado para todos os PRs
– **Pontos cegos nas perguntas**: o agente pode deixar de abordar problemas que ele mesmo não percebeu. Por isso, a etapa de “encontrar algo que passou despercebido” não deve ser omitida
– **Sobre a fonte**: as opiniões de Addy foram transmitidas pela mídia; é preciso conferir por conta própria a formulação original
Q7: É mesmo necessário praticar programação offline toda semana?
O argumento de Addy é que habilidades pouco usadas podem se deteriorar com o tempo. De vez em quando, concluir uma tarefa sem a ajuda de um agente pode ajudar você a avaliar seu nível real. Fazer um balanço mensal das habilidades que você delegou à IA e das que precisa continuar dominando também custa pouco e pode evitar que a rendição cognitiva aconteça sem você perceber.
Não dê aval automático ao Agent: principais pontos sobre a dívida de compreensão
- A rendição cognitiva é gradual: começa com a terceirização do esforço cognitivo, passa pela delegação do julgamento e termina com a entrega completa das decisões
- A dívida de compreensão cobra juros depois: quanto mais rápido o código é escrito, mais as partes que você não entende se acumulam e vêm à tona na hora de fazer alterações
- A dívida de intenção surge antes da implementação: escreva sua própria lista de requisitos antes de começar e, se duas rodadas de comandos não trouxerem um resultado satisfatório, reorganize os requisitos
- O passo central é deixar que o Agent teste você: peça um resumo das alterações e algumas perguntas; só faça o merge quando acertar todas
- Todos os testes passarem não significa que não há problemas: primeiro, confira os resultados dos testes que realmente foram executados; depois, pergunte o que ficou sem teste
- Relatório de aceite e perguntas se complementam: o primeiro valida o comportamento externo; as segundas avaliam sua compreensão da lógica interna
- Revise de acordo com o risco: se não der conta das revisões, aumente a automação ou reduza o trabalho em paralelo, em vez de contar com a sorte
Resumo
Os pontos centrais para não dar aval automático ao Agent são:
- Identifique o estágio: fique atento à transição de “deixar a IA trabalhar” para “deixar a IA decidir”; a dívida de compreensão e a dívida de intenção são subprodutos desse processo
- Coloque em prática: registre suas expectativas antes de começar, pergunte sobre decisões não autorizadas e pontos não testados na entrega e peça à IA que teste seu entendimento antes do merge
- Ajuste a revisão ao risco: para alterações de baixo risco, use um relatório de aceite ou uma verificação pontual; para alterações de alto risco, siga o processo completo e acrescente uma revisão independente
A velocidade com que a IA escreve código vai continuar aumentando, mas a responsabilidade pelas alterações sempre será de quem as aprova. Antes de clicar em “Aprovar” na próxima vez, peça ao Agent que faça 5 perguntas e veja quantas você consegue acertar.
📚 Referências
- QbitAI: guia completo de agentes para engenheiros com Claude (republicado no 36Kr): apresenta as ideias de Addy Osmani sobre rendição cognitiva, dívida de compreensão e dívida de intenção, além de métodos para colocá-las em prática.
- Link:
36kr.com/p/4056027738116995 -
Observação: fonte principal da metodologia deste artigo; trata-se de uma reportagem que relata as ideias do autor.
-
Publicação original de Addy Osmani: fonte original citada na reportagem.
- Link:
x.com/addyosmani/status/2117512471930167377 -
Observação: consulte o texto original para conferir a redação exata e verifique o link por conta própria.
-
Baleia Branca Lab: empresa de IA com 80 mil estrelas decide deixar que a IA assuma o controle (republicado no 36Kr): apresenta a arquitetura de agente supervisor do LobeHub e a prática de relatórios de aceite (Acceptance).
- Link:
36kr.com/p/4056040123945860 - Observação: fonte comparativa para a revisão baseada em relatórios de aceite; a afirmação de que a equipe “quase não olha o código” foi feita pela própria equipe.
Autor: Equipe técnica da APIYI
