O Estagiário Que Nunca Diz Que Não Sabe

01O Estagiário Que Nunca Diz Que Não Sabe

Um estagiário decente, mais cedo ou mais tarde, diz "não tenho a certeza, deixa-me confirmar". É um dos sinais mais fiáveis de que se pode confiar nele: sabe onde está o limite do que sabe. A IA raramente faz isso sem lhe ser pedido explicitamente. Entrega uma função, uma explicação de porque funciona, e seis alíneas a justificar a escolha, com o mesmo tom seguro quer o código esteja certo quer esteja completamente errado.

Isto não é uma falha pontual que a próxima versão do modelo resolve. É uma característica de como estas ferramentas respondem: o texto mais provável, dado o que já foi escrito, não é o mesmo que o texto correto. Às vezes coincidem. Confundir as duas coisas é o erro que este guia tenta evitar.

O resto deste guia é sobre como construir esse hábito sem ele consumir mais tempo do que aquele que a IA te poupou.

02Construir Ficou Fácil. Verificar Não.

Nos últimos anos passei de escrever scripts para automatizar tarefas repetitivas a construir software em produção: protocolos de blockchain, infraestrutura de pagamentos, sistemas com IA. O que mudou não foi só a minha capacidade de escrever código. Foi a rapidez com que consigo produzi-lo, e é aí que está a armadilha.

Quando escrever era lento, o próprio ritmo obrigava a pensar em cada linha. Quando escrever fica rápido, o gargalo desloca-se: já não é produzir código, é decidir se o código que acabaste de receber está certo. Se a forma de decidir isso não mudar ao mesmo ritmo que a forma de o produzir, o resultado é mais código a chegar a produção sem ter sido pensado por ninguém, humano ou não.

Os capítulos seguintes são sobre como fechar essa distância: primeiro o princípio (nunca confiar num avaliador só), depois o método (um teste que prova, não uma explicação que convence), depois dois casos reais onde isso apanhou algo que ia passar.

03Um Avaliador Sozinho Não Chega (Nem Quando É Só Um Agente)

A ideia de que código não devia ser confiado só porque a pessoa que o escreveu acredita nele não é nova. Já em 1971, Gerald Weinberg descrevia, no livro que viria a popularizar a ideia de "programação sem ego", como um programador convencido da própria correção é sistematicamente pior a encontrar os próprios erros do que uma segunda pessoa a rever o mesmo código de fora. Não é falta de competência, é estrutural: quem escreveu o código já decidiu, ao escrevê-lo, que aquele era o caminho certo.

Pedir a um agente de IA para rever o código que outro agente escreveu tem exatamente o mesmo ponto cego, só que mais difícil de notar. Parece revisão independente porque é outra conversa, outro pedido, por vezes outro modelo. Mas se os dois herdam a mesma lacuna, seja no treino, seja no contexto que lhes deste, os dois vão validar o mesmo erro com a mesma confiança.

Na prática, aplico três coisas: peço a mais do que um agente para atacar o mesmo código, com instruções deliberadamente diferentes ("tenta partir isto" em vez de "isto está correto?"), reviso eu próprio o que os agentes concordam entre si com mais desconfiança do que aquilo em que discordam, e trato qualquer aprovação unânime e imediata como um sinal para olhar com mais cuidado, não menos.

04O Teste Que Prova, Não a Explicação Que Convence

Uma boa explicação de porque um código funciona é fácil de produzir e fácil de aceitar, e não prova nada. Michael Feathers, no livro sobre trabalhar com código legado que ficou como referência da área, populariza a ideia do "teste de caracterização": em vez de perguntar se o comportamento está certo, escreve-se primeiro um teste que capta o comportamento real, tal como é, e só depois se decide se esse comportamento devia mudar.

Aplicado a código de IA, o princípio fica assim: antes de aceitares uma correção, escreve um teste que reproduza o problema original, falha com o código antigo, e só o marca como resolvido quando esse mesmo teste passa. Não perguntes à IA se corrigiu. Faz o teste perguntar.

É a mesma regra que uso em produção: uma falha só é considerada corrigida quando existe um teste que a reproduz. Não é burocracia extra, é a diferença entre saber e confiar que se sabe.

05Falhas Reais Numa Ponte Entre Duas Blockchains

Um dos sistemas que construí move valor entre duas blockchains diferentes, com uma prova criptográfica a garantir que nada é criado do nada. Antes de qualquer avanço sério, submeti-o a uma auditoria adversarial com vários agentes de IA independentes, cada um instruído para tentar ativamente encontrar uma forma de quebrar o sistema, não para confirmar que estava bem feito.

A camada principal de segurança foi confirmada sólida. Mas a auditoria encontrou falhas reais, coisas que eu, sozinho, tinha deixado passar por estarem fora do caminho óbvio que eu próprio tinha desenhado:

• Uma forma de forjar um certificado singleton que devia ser único, sem passar pela verificação normal.
• Uma janela demasiado curta contra reorganizações da cadeia, que podia deixar valor a ser movido sobre um bloco que ainda podia desaparecer.
• Falta de uma etiqueta de domínio por perna da operação, que em teoria permitia reutilizar uma prova destinada a um sentido no sentido contrário.
• Uma chave de verificação de reserva (placeholder) que, se esquecida em produção, aceitava provas que não deviam ser aceites.

As quatro foram corrigidas, cada correção com um teste próprio a reproduzir o ataque original e a confirmar que deixa de funcionar. Nenhuma delas era visível a olhar para o caminho feliz, o caso em que tudo corre como esperado. Todas viviam no caminho que só aparece quando alguém pergunta ativamente "como é que eu quebrava isto de propósito?", que é exactamente a pergunta que sozinho raramente fazes ao teu próprio trabalho.

06Quando o Bug Impede o Próprio Criador de Vender

Noutro projeto meu, uma plataforma onde artistas criam e vendem coleções digitais, apareceu um bug com uma assinatura muito específica: o próprio criador de uma coleção não conseguia comprar a sua própria peça. A transação era rejeitada com um erro genérico de saldo insuficiente, mesmo com fundos de sobra. Uma carteira de terceiros comprava sem problema nenhum. Só o dono ficava bloqueado.

A causa era simples de encontrar depois de encontrada: a lógica de pagamento assumia sempre que comprador e vendedor eram entidades diferentes, e nunca tinha sido testada para o caso, óbvio em retrospetiva, de um criador a comprar de si próprio. É o tipo de caso que ninguém pensa em testar porque parece marginal, mas que na prática é quase sempre o primeiro caminho que alguém percorre a sério: o próprio criador, a confirmar que o que construiu funciona.

Um segundo bug, na mesma plataforma, era mais silencioso. O sistema reservava um número de série assim que um pagamento começava, antes de confirmado. Se o pagamento falhasse a meio, por qualquer razão, esse número ficava queimado na mesma: nunca voltava a ficar disponível. Depois de falhas suficientes, uma coleção com peças por vender aparecia como esgotada. Não havia erro visível, nem alerta. Havia só uma contagem que descia e nunca voltava a subir.

A correção foi um mecanismo de libertação: percorrer os números reservados do mais recente para o mais antigo e devolver à coleção os que nunca tiveram pagamento confirmado. Nenhum dos dois bugs foi apanhado por eu ler o código com atenção. Foram apanhados por alguém a tentar de facto usar o sistema como um utilizador real usaria, e não como o caminho feliz que eu tinha em mente quando o escrevi.

07As Perguntas Que Furam Código Bonito

Código gerado por IA tende a estar bem formatado, bem comentado e a seguir convenções, o que o faz parecer mais confiável do que é. Formatação não é correção. As perguntas que valem a pena fazer, ao código ou ao próprio agente, não são sobre estilo:

• "O que acontece se isto for chamado duas vezes seguidas com o mesmo pedido?"
• "O que acontece se a operação falhar a meio, depois do primeiro passo mas antes do último?"
• "Quem mais, além de quem eu tinha em mente, pode chegar a este código, e o que acontece se for essa pessoa?"
• "Se eu tentasse ativamente partir isto, por onde é que começava?"

Nenhuma destas perguntas exige saber mais do que quem as faz já sabe. Exige só perguntá-las antes de aceitar a resposta seguinte.

08O Que Fazer Quando Não Tens Tempo Para Isto Tudo

Nem tudo o que se constrói merece uma auditoria com vários agentes e um teste de caracterização para cada correção. Um protótipo de fim de semana não é uma ponte que move valor entre duas blockchains, e tratá-los da mesma forma é desperdiçar disciplina onde ela não compensa.

A versão mínima, para quando o tempo é curto, é uma pergunta só, feita a sério antes de aceitares qualquer código que decida algo em nome de outra pessoa (dinheiro, acesso, dados): "se isto correr mal, quem é que sofre, e eu saberia?" Se a resposta for alguém que não és tu, e não saberias, isso é o sinal de que compensa parar mais dois minutos e fazer as perguntas do capítulo anterior.

O registo no fim deste guia é para isso: não uma checklist de vinte pontos, uma entrada por coisa que decidiste confiar, com o risco que identificaste e como o testaste. Se o campo do teste ficar em branco outra vez e outra vez para o mesmo tipo de risco, é aí que sabes onde a tua disciplina ainda não chegou.