Como resistir à rendição cognitiva diante dos agentes de IA

O texto de Kunal, publicado no knlb.dev, define rendição cognitiva como aceitar o que os agentes produzem sem pensar, explorar ou considerar alternativas. Ele admite que o método é rápido, pouco cansativo e sedutor, mas diz que, com frequência, toma decisões piores, acumula dívida técnica e perde familiaridade com o sistema.

O autor aponta causas concretas: a preguiça típica do bom programador, a pressão dos colegas, o volume aparente de PRs entregues e a confiança excessiva dos modelos, que ele atribui talvez ao RLHF. Para ele, a complexidade gerada sem atenção não dói na hora, cobra depois. Como saída, propõe o conceito de "vibe limit" (a complexidade da mudança que ele consegue fazer com confiança usando agentes) e táticas práticas: dirigir em vez de observar, digitar as mudanças à mão nos projetos importantes, pedir uma visão de PR com quatro colunas (diff, comentário do agente e espaço para suas anotações), usar debugger e mandar o agente explicar flags obscuras. Um sinal de alerta é se pegar clicando "yes, continue" repetidamente. Ele também defende decomposição e design modular, para reduzir o risco de cada mudança, seja de humano ou de agente.

O tema já vinha aparecendo no CEVIU. Em 6 de abril de 2026, o CEVIU noticiou "Mandatos de IA são uma demanda por rendição cognitiva", sobre pessoas que deixam de aplicar julgamento crítico e aceitam resultados da IA como verdade. Em 6 de maio de 2026, "Entrega Cognitiva: O Risco Silencioso da IA no Seu Trabalho" tratou de quando a saída da IA vira silenciosamente a sua. Em 14 de agosto de 2026, "Pensamento Crítico na Era da IA: O Dilema da Delegação e a Busca por Insights Originais" abordou o engenheiro que virou gestor de agentes. A novidade agora é o foco em prática de engenharia: o texto de novembro de 2026 sai do diagnóstico e lista táticas de código, revisão e design para resistir.

Para quem opera sistemas com agentes, a leitura é que velocidade de escrita deixou de ser o gargalo, e a compreensão passou a ser. Decidir conscientemente onde delegar (protótipos, ambientes isolados) e onde dirigir (sistemas frágeis ou críticos) parece um critério útil para times que medem produtividade só por volume de PRs.