Estou completamente apaixonado pelo Opus 4.5 neste momento. É tão inteligente quanto o Gemini 3, mas com um estilo de código muito melhor, instruções mais claras, experiência de usuário na linha de comando superior e, o mais importante, velocidade quando você só precisa fazer algo simples. Além disso, tive uma interação super legal em que o Claude Code estava com dificuldades e andando em círculos, então o interrompi e deixei que ele pedisse esclarecimentos. Ele fez ótimas perguntas, expliquei alguns conceitos até que ele entendeu. Então, ele completou a tarefa (que não era fácil!) e passou em todos os testes. Eis a interação (resumida pela própria Opus): (Código Claude interrompido) Eu: Você está passando bastante tempo aqui, por que não me faz perguntas? Eu sempre posso responder perguntas. Você não precisa ficar chutando e tentando coisas aleatórias, isso só vai levar ao fracasso. IA: Você tem razão, peço desculpas. Pergunta: quando distribuo a lambda pelo SUP, como deve funcionar o redirecionamento de variáveis? Devo configurar HEAP[lam_loc] para redirecionar as variáveis originais para as novas lambdas? Eu: Não tenho certeza do que sua notação significa, mas... [explica a semântica de dup-lam]. Observe que precisamos absolutamente de uma função clone_many() que receba um Term* e clone cada elemento em dois Term*. Temos isso? Isso responde à sua pergunta? - IA: Obrigado, isso esclareceu muita coisa! Minha dúvida sobre `clone_many`: no meu `inject` em C, eu clono o template uma vez e clono cada argumento restante. Isso está correto? - Eu: O que é args0[16]? O que é args0[0] e por que sup_a está lá? Não tenho certeza se entendi. IA: Você tem razão, deixe-me reler o Haskell com mais atenção... Então, a e b (os ramos SUP) não são clonados — eles vão diretamente como o primeiro elemento das novas listas de argumentos. Somente os argumentos restantes são clonados. Meu código em C confirma isso. O problema deve estar em outro lugar. - Eu: Ah, entendi. Sim, sua lógica de clonagem parece mais ou menos correta, mas eu ainda insistiria que você usasse uma função auxiliar `clone_many` em vez de inseri-la manualmente dessa forma. IA: Ok, vou adicionar clone_many primeiro. [adiciona, os testes ainda falham] Ainda estou obtendo resultados incorretos. Pergunta: O collapse deve avaliar/resolver os nós CO0/CO1? Ou eles devem permanecer como CO0/CO1 e serem resolvidos posteriormente? - Eu: em Haskell, CO0/CO1 caem no caso padrão de colapso... [explica a cadeia de redução completa com interação de mesmo rótulo dup-sup] IA: Isso é muito útil! Então, a interação duplicada-substituída com os mesmos rótulos é o que faz com que CO0/CO1 se resolvam corretamente. O problema deve estar na minha estrutura de modelo. Será que minha estrutura de modelo está errada? Eu: Você só precisa passar o modelo para injeção, ele clonará tudo se necessário. Sua construção parece errada, você está alocando duas lambdas? Por que duas alocações de memória na heap? Você deveria criar uma variável para a lambda externa, parece que você está criando uma variável em um local não utilizado? - IA: Você tem razão! A variável `fV_loc` deve apontar para a localização do corpo da lambda externa (`outer_loc`), e não para alguma `fV_loc` separada. Está correto? - Eu: Parece mais ou menos bom, mas por favor, verifique novamente, você é a máquina aqui. IA: Você tem razão, deixe-me analisar cuidadosamente... [analisa, verifica e corrige o código] collapse_4 aprovado! [continua corrigindo os casos APP, DRY, MAT e CTR com o mesmo padrão] Todos os 35 testes foram aprovados!
este loop: Você dá uma tarefa à IA. > explora o problema Isso levanta uma questão Você o alimenta com conhecimento. > explora o problema > ... etc ... É uma maneira muito poderosa e eficiente em termos de tempo para construir software. Você ainda é mais inteligente que isso (espero), mas consegue levantar muita coisa sozinho.