Versão breve
- Mesmo repositório → Mesmos testes → Alterações revistas.
- Guarde as fontes e reveja o resultado antes de o utilizar.
Compare GPT-6 Sol e Claude Opus 5.5 para programação numa versão fixa do repositório. Dê a cada modelo a mesma tarefa, acesso às ferramentas e verificações de aceitação. Guarde as alterações, o registo de comandos e as notas do revisor para poder explicar o resultado.
Este artigo fornece um protocolo de teste. A Thrive não realizou esta experiência direta e não publica pontuações fabricadas. As especificações oficiais fornecem informação inicial; o seu trabalho fornece as provas para escolher.
Prepare uma comparação justa
Escolha um repositório que tenha autorização para utilizar e retire segredos do ambiente de teste. Registe o hash do commit e restaure o estado inicial antes de cada execução. Mantenha uma reprodução que falha disponível para tarefas de correção de erros.
Forneça as mesmas instruções, ficheiros relevantes e comandos autorizados. Defina um limite de tempo ou tentativas e explique os critérios de revisão antes da execução. Se um produto receber ferramentas adicionais de recuperação de informação, registe a diferença e descreva o teste como comparação de fluxos de trabalho.
Utilize um ramo de teste. Mantenha as credenciais de produção e as ações de publicação fora do teste. O assistente não deve precisar de enviar mensagens, publicar um pacote ou alterar uma base de dados em produção para demonstrar uma correção local.
Utilize cinco tipos de tarefas
Tarefa | Material inicial | Critério de aceitação | Campo de resultado |
|---|---|---|---|
Depuração | Uma reprodução que falha | Corrige a causa e acrescenta uma verificação de regressão relevante | Registar após a execução |
Refatorização | Código funcional e interfaces estáveis | Preserva o comportamento e os contratos públicos | Registar após a execução |
Testes | Um requisito com casos limite conhecidos | Testa o comportamento e expõe uma falha relevante | Registar após a execução |
Análise do repositório | Uma pergunta de arquitetura delimitada | Cita ficheiros relevantes e segue o percurso real das chamadas | Registar após a execução |
Documentação | Uma API ou comando atual | Os exemplos executam na versão indicada | Registar após a execução |
«Registar após a execução» é uma etiqueta da folha de trabalho, não um resultado de desempenho. Pode acrescentar tarefas relevantes para o repositório, como verificações de autorização ou revisão de uma migração.
Defina requisitos concretos para a tarefa
Escreva as entradas, o comportamento esperado, as restrições e o comando de verificação. Um pedido útil de correção descreve o que o utilizador fez, o que aconteceu e o que deveria acontecer. Inclua uma mensagem de erro ou reprodução quando disponível.
Numa aplicação fictícia, a tarefa pode ser: «Quando um visitante sem sessão iniciada abrir o espaço privado de currículos, encaminhe-o para iniciar sessão e preserve o destino pedido. Visitantes com sessão iniciada devem abrir o espaço. Mantenha acessíveis as orientações públicas sobre currículos.» Isto define dois estados e um limite que o revisor consegue testar.
Peça ao assistente que explique os ficheiros que pretende alterar antes de ampliar o âmbito. Uma refatorização do repositório deve ter um motivo ligado ao comportamento pedido.
Utilize o prompt de auditoria de TypeScript para uma tarefa de revisão e a skill de depuração para uma tarefa baseada em reprodução.
Reveja sem conhecer o modelo utilizado
Sempre que possível, dê ao revisor as alterações com etiquetas neutras. Peça uma avaliação da correção, do âmbito, da manutenção e da verificação. Preserve um empate se ambas cumprirem os requisitos com esforço de revisão semelhante.
Execute os testes num ambiente limpo. Verifique se o assistente enfraqueceu um teste, suprimiu um erro ou mudou uma definição para obter aprovação. Registe a falha e a correção proposta como provas distintas.
Examine dependências e alterações de permissões. Uma correção que resolve o erro visível alargando o acesso pode criar um problema mais grave. O revisor deve compreender por que cada alteração sensível pertence à solução.
Calcule o custo a partir da utilização real
Registe tokens de entrada e saída, novas tentativas, custos de ferramentas e tempo do revisor. Utilize o preço do fornecedor aplicável ao pedido. A comparação geral de modelos explica as especificações base e um exemplo aritmético delimitado.
Compare o custo por tarefa aceite, não apenas o preço por token. Um modelo pode utilizar mais contexto ou exigir mais tentativas. Os tokenizadores e os níveis de serviço podem alterar a fatura de sessões aparentemente semelhantes.
Apresente o resultado e os seus limites
Indique os IDs dos modelos, as definições, a versão do repositório, o número de tarefas, a política de tentativas, a data e o método de revisão. Explique falhas e sucessos. Apresente o resultado como provas das tarefas testadas, sem afirmar que representa todo o trabalho de programação.
Guarde o registo original. Quem ler a comparação deve conseguir repetir as verificações ou compreender por que um caso falhou. Volte a executar os casos principais após alterações do modelo ou das ferramentas do agente.
O fluxo de avaliação de modelos e a grelha de avaliação por pares podem ajudar a organizar a revisão. Uma versão sem dados identificáveis pode apoiar uma conversa de portefólio sobre as suas decisões de teste.
Fontes e notas de revisão
A equipa editorial da Thrive consultou estas fontes em 28 de setembro de 2026. Concebemos a folha de trabalho; não a preenchemos com resultados medidos dos modelos.
Ponha em prática
O seu próximo passo
Tem uma pergunta ou uma correção?
Contactar a Thrive
