Funcionou. Mas o que isso prova?

Em pesquisa apresentada em fevereiro deste ano, pesquisadores da Universidade da Califórnia em San Diego e da Universidade de Toronto acompanharam 19 estudantes de graduação construindo um aplicativo web na plataforma Replit. Interagir com o protótipo pronto, testando e depurando, respondeu por 63,61% das interações classificadas. Examinar o código ou os registros de execução respondeu por 7,38% (Geng et al., 2026). Os estudantes passaram a maior parte do tempo confirmando que o programa funcionava, raramente checando por que funcionava.

O programa funciona. Mas o que isso prova? Cada vez que a Inteligência Artificial (IA) reduz o custo de produzir um resultado que funciona, o resultado sozinho informa menos sobre o processo que levou até ele.

O padrão se repete em escala menor e mais direta. No experimento de Rahe e Maalej (2025) com 37 estudantes de programação, a maioria dos que recorreram ao chatbot acabou pedindo a ele a solução inteira: vê o erro, cola no chat, obtém o código novo e repete até rodar, sem entender por que algo parou ou voltou a funcionar.

Outro estudo, publicado em abril deste ano, ajuda a explicar por quê. Pesquisadores da ETH Zürich testaram cem estudantes universitários em tarefas de programação assistida por IA e mediram conhecimento prévio de ciência da computação, habilidade de escrita e frequência de uso de modelos de linguagem no dia a dia. O conhecimento prévio de computação foi o melhor preditor de sucesso, mesmo controlando pela capacidade cognitiva geral. Os estudantes que mais usavam modelos de linguagem (LLMs) no cotidiano tiveram desempenho pior, tanto na tarefa de programação quanto num teste de redação aplicado à parte — resultado que os próprios pesquisadores dizem não conseguir explicar com certeza a partir de um estudo correlacional (Thorgeirsson, Weidmann e Su, 2026).

Um grupo diferente, da mesma universidade, testou o problema pelo lado inverso, pedindo a agentes de IA populares que corrigissem código que já estava correto. Em até 70% dos casos, dependendo do modelo testado, o agente “corrigiu” o que não precisava de correção (Mündler et al., 2026). Logo, nem a confiança do estudante, nem a confiança do agente, sozinhas, provam algo.

A Teoria da Carga Cognitiva (Sweller, 1988; 2010), ajuda a separar risco de oportunidade real. O autor distingue a carga extrínseca (esforço gasto em atrito irrelevante para o aprendizado) da carga germana (esforço que de fato constrói entendimento). A automação por IA pode reduzir a primeira e liberar capacidade para a segunda, mas isso só acontece se o desenho da tarefa obrigar o estudante a explicar o que pediu, testar o que recebeu e justificar por que aceitou. Sem essa obrigação, a capacidade liberada vira só mais tempo livre para pedir a próxima geração de código.

A partir desse “só se”, venho propondo um framework que tenta tornar esse processo visível, ancorado, dentre outros fundamentos, na própria Teoria da Carga Cognitiva (de Lima Prestes, 2026).

Nele, uso o esquema Talking To, Through, and About AI (Woo, Guo e Yu, 2025) como ponto de partida classificatório. O esquema deles distingue três posturas diante do modelo: falar para a IA é formular o pedido com intenção e restrição declaradas; falar sobre a IA é examinar criticamente o que voltou; e falar através da IA é decidir o que fica, assumindo a autoria do resultado.

O framework que proponho converte essas três posturas num ciclo de sete etapas nomeadas (Intenção, Prompt, Geração, Análise Crítica, Metacognição, Autoria e Iteração). Cada etapa produz uma evidência mínima, pensada para sustentar a avaliação do professor sobre o processo inteiro, do início ao resultado final:

• Em Intenção, a hipótese e o critério de sucesso antes do primeiro prompt;
• Em Prompt, a restrição declarada;
• Em Geração, o output e as suposições identificadas nele;
• Em Análise Crítica, um checklist de corretude, segurança e viés;
• Em Metacognição, a explicação escrita do que se entendeu e do que não se entendeu; e
• Em Autoria, a decisão de aceitar, rejeitar ou refatorar, justificada.

Framework pedagógico autoral: uso do vibe coding para gerir a carga cognitiva e promover letramento crítico em IA (de Lima Prestes, 2026).

Qualquer etapa pode devolver o processo à Intenção ou ao Prompt. Essa reabertura documentada é o que sustenta o ciclo. Na prática espontânea, a maior parte do uso hoje já para na geração e se valida com um “rodou”, sem deixar rastro de nenhuma das etapas seguintes.

O rastro que cada etapa produz é uma decisão humana registrada (o que a pessoa pretendia, o que recebeu, o que verificou, o que entendeu e por que aceitou ou recusou). Chamo isso de rastro epistêmico, para diferenciar de outro tipo de rastro que também está em falta hoje, num problema vizinho, mas diferente: o rastro operacional, ou seja, o que um sistema autônomo de fato executou, quais permissões usou, em qual ordem, sob qual controle.

Até aqui, o que descrevo é avaliação educacional. Mas a insuficiência do resultado como prova do processo não desaparece quando o estudante vira profissional; ela muda de natureza.

Cito um exemplo. Em meados de dezembro de 2025, a AWS Cost Explorer — ferramenta que ajuda clientes da Amazon a monitorar gastos na nuvem — ficou fora do ar por cerca de 13 horas numa região da China continental. De acordo com reportagem do Financial Times (2026), a causa foi o Kiro, agente de IA interno usado para tarefas de programação. Autorizado a mexer no ambiente para corrigir um problema, o agente teria decidido, por conta própria, que a saída mais eficiente era apagar parte daquele ambiente e recriá-lo, sem que ninguém revisasse a decisão antes.

Segundo a própria Amazon (2026), o problema foi um erro de configuração humana nas permissões de acesso (ou seja, não teria havido uma decisão autônoma da IA) e o incidente afetou só um serviço, sem impacto em computação, armazenamento ou banco de dados. A Amazon também negou que tivesse havido um segundo evento, como a reportagem original sugeria. Porém, quase oito meses depois do incidente, tanto a empresa que constrói o agente quanto a imprensa ainda continuam descrevendo versões incompatíveis do que aconteceu. Nenhuma das partes publicou o registro técnico que permitiria a um terceiro avaliar quem está certo.

Outro exemplo resolve uma disputa sobre autoria, mas não sobre confiabilidade. Em abril de 2026, um agente de IA rodando sobre o modelo Claude Opus 4.6 da Anthropic, operando dentro do editor Cursor, apagou, em apenas nove segundos, o banco de dados de produção da PocketOS, plataforma usada por empresas de aluguel de carros para gerir suas operações. O agente encontrou, num arquivo criado para outra finalidade, um token de API com permissão irrestrita sobre toda a infraestrutura, utilizando-o para apagar o volume de produção e os backups que, por erro de arquitetura do provedor de nuvem, estavam guardados no mesmo volume. Perguntado depois acerca do que tinha feito, o agente escreveu uma confissão detalhada, reconhecendo ter violado cada uma das instruções de segurança do próprio prompt do sistema (Hughes, 2026). Essa confissão é, até hoje, o único registro do que aconteceu. Ninguém verificou, de forma independente, se ela é completa.

Imagem gerada com apoio de IA Generativa (ChatGPT 5.6 Sol).

Kiro e a PocketOS não validam o framework que descrevi acima. As situações relatadas em que ambos figuram nasceram de um problema vizinho, com lógica própria. No caso do Kiro, o que está em disputa é atribuição causal e auditabilidade operacional (o que o agente executou, com quais permissões, em que sequência, sob qual controle etc). No caso do PocketOS, trata-se de controle de acesso e arquitetura de segurança. Em ambos os casos faltou rastro operacional (o log que diria o que a máquina fez). No ensino de programação, falta rastro epistêmico, o registro que diria o que a pessoa entendeu. São problemas diferentes que compartilham a mesma lacuna, pois em nenhum dos dois planos existe um padrão de reconstruir, depois, o caminho que levou ao resultado.

Isso não isenta as empresas de tentar preencher o rastro operacional. Frameworks como o NIST AI Risk Management Framework (2023) e a ISO/IEC 42001 (2023) tentam fazer isso de fora para dentro, com política e auditoria ao longo de todo o ciclo de vida do sistema, tratando o problema no nível organizacional que é distinto da instanciação pedagógica que venho descrevendo. O que decide se essa camada externa funciona é o que a organização registra sobre a fronteira entre o que ficou a cargo do sistema e o que permaneceu sob julgamento humano explícito, antes de precisar justificar essa fronteira a um auditor.

Política sem rastro documentado não sobrevive a uma auditoria, cujo objetivo é verificar se a organização consegue mostrar o que fez, com qual dado e quando. Em termos gerais, é o mesmo tipo de exigência que está chegando agora para os agentes autônomos, embora boa parte das organizações ainda esteja descobrindo isso incidente por incidente.

Esse é o fio que atravessa a minha pesquisa sobre Letramento em IA desde 2025. Num primeiro trabalho, sobre ensino inclusivo e humanizado, descrevi o vibe coding como uma expansão da relação entre quem programa e o código (de Lima Prestes, 2025). Neste texto, retomo o mesmo fio sob outro ângulo — o da evidência (de Lima Prestes, 2026). O framework de sete etapas que descrevi é a tentativa de exigir essa evidência, passo a passo, num contexto pequeno o bastante para caber numa disciplina.

O padrão que atravessa este texto, do laboratório de programação ao data center, é o mesmo: a IA baixou o custo de produzir um resultado que funciona, e por isso ficou mais valiosa a prova de que alguém (estudante, profissional, organização) entendeu, verificou e assumiu o caminho até ele. É essa prova que este framework, e o texto que o descreve, tentam colocar de volta em cena.