Ferramentas de linha de comando Agentic: Codex vs Claude Code
As ferramentas CLI Agentic são ferramentas de codificação com IA que podem criar e excluir arquivos, executar comandos, planejar e executar a codificação de todo o projeto. Avaliamos as principais ferramentas em 10 cenários reais de desenvolvimento web, realizando cerca de 600 verificações de validação atômica por agente e mais de 5.000 execuções de testes automatizados no total, incluindo lógica de backend, funcionalidade de frontend e verificação de consistência em múltiplas execuções.
Resultados do benchmark Agentic CLI
Análises de desempenho das ferramentas de linha de comando Agentic
Codex tem a pontuação geral mais alta (67,7%) e o melhor desempenho de backend (58,5%). Sua pontuação de backend supera em mais de 5 pontos percentuais a do segundo colocado, Junie (54,3%).
Junie ocupa o segundo lugar geral (63,5%), combinando uma sólida correção no backend (54,3%) com um forte desempenho no frontend (85,0%). Sua diferença entre backend e frontend (30,7 pontos percentuais) é moderada em comparação com outros agentes, e ela concluiu todas as 10 tarefas com a infraestrutura de backend pronta em 9 delas.
Claude Code tem a maior pontuação de front-end (95,0%), mas sua pontuação de back-end (38,6%) reduz seu resultado geral (55,5%). Isso ilustra a principal dinâmica do gráfico: o desempenho do front-end é relativamente alto para vários agentes, enquanto a correção do back-end e a disciplina contratual são os principais fatores que influenciam a classificação.
A maior diferença entre interface do usuário e backend aparece no Claude Code (95,0% frontend vs 38,6% backend). Em contraste, o Codex combina uma alta pontuação de frontend (89,2%) com a melhor pontuação de backend, razão pela qual lidera no geral com a ponderação de 0,7 backend / 0,3 frontend.
Os agentes com classificação inferior falham por diferentes motivos. O Goose apresenta pontuações próximas de zero tanto no backend (3,1%) quanto no frontend (10,0%), indicando problemas básicos de execução e completude. O Forge e o Cline apresentam pontuações moderadas no frontend (45,8% e 33,3%), mas baixas no backend (20,1% e 26,7%), o que condiz com problemas de contrato e roteamento no backend, que dominam seus resultados.
Velocidade versus pontuação e uso de fichas versus pontuação
Avaliamos a eficiência de tempo de execução usando o tempo médio de execução (em segundos), o uso efetivo de tokens (entrada + saída) e a pontuação de precisão combinada:
O agente Aider ocupa a região mais equilibrada do gráfico. Com uma pontuação combinada de 52,7%, ele conclui tarefas em 257 segundos e consome 126 mil tokens. É o único agente que combina precisão média a alta com tempo de execução relativamente baixo e consumo moderado de tokens.
Codex alcança a pontuação geral mais alta (67,7%), mas a um custo maior. Seu tempo médio de execução é de 426 segundos e o uso de tokens é de 258 mil. A compensação em termos de eficiência parece ser proporcional ao ganho em precisão.
Junie ocupa o segundo lugar em precisão (63,5%), com um tempo médio de execução de 483 segundos e 370 mil tokens efetivos. Comparado ao Codex, consome 43% mais tokens, resultando em uma queda de 4,2 pontos percentuais na pontuação. Sua relação token/precisão é menos favorável do que a de Aider ou Codex, mas supera o Claude Code tanto em precisão quanto em eficiência de tokens.
Claude Code é o agente mais caro entre os de melhor desempenho. Ele ocupa o terceiro lugar em precisão (55,5%), mas requer 745 segundos e 397 mil tokens. Comparado a Aider, Claude consome mais de 3 vezes mais tokens para um aumento de 2,8 pontos percentuais na pontuação.
O Kiro CLI é o agente mais rápido, concluindo em 168 segundos e atingindo uma pontuação combinada de 58,1%. No entanto, o Kiro não divulgou o uso de tokens. Em vez disso, medimos o consumo de créditos (46,1 créditos). Uma comparação completa de eficiência ainda não está completa para o Kiro, mas, considerando seu consumo de créditos, ele é um dos mais baratos.
Na extremidade inferior, o algoritmo Goose demonstra baixa eficiência. Ele consome 300 mil tokens e leva 587 segundos para ser executado, obtendo uma pontuação de apenas 5,2%. Alto consumo de tokens não se traduz em acerto neste caso.
De modo geral, um maior consumo de tokens não se correlaciona consistentemente com maior precisão. O comportamento de repetição da arquitetura e a estratégia de validação parecem influenciar o uso de tokens mais do que a profundidade bruta da resolução do problema.
Você pode conferir nossa metodologia abaixo.
Como funcionam as ferramentas CLI agéticas
As ferramentas CLI agéticas são agentes autônomos que operam dentro do terminal. Embora a maioria dos usuários as utilize para tarefas de programação, elas podem executar qualquer fluxo de trabalho que possa ser realizado por meio de comandos do shell.
Esses agentes normalmente operam em um ciclo composto por três fases:
- Reúna o contexto.
- Tome uma atitude
- Verificar resultados
Após a verificação, o agente coleta o contexto atualizado e repete o loop até concluir a tarefa ou atingir uma condição de parada.
O loop é influenciado por duas fontes:
- O usuário humano, que fornece a tarefa inicial e pode interromper a execução.
- O modelo realiza planejamento, raciocínio e seleção de ações.
A estrutura do agente fornece a base para o modelo. Ela define como o modelo deve planejar, quando deve executar comandos, como deve validar os resultados e quais ferramentas estão disponíveis. Essas ferramentas podem incluir execução de shell, acesso ao sistema de arquivos, controle do navegador , uso do computador , integrações com o MCP ou "habilidades" reutilizáveis.
Diferentes arquiteturas de agentes impõem diferentes estratégias de planejamento, políticas de repetição e lógica de verificação. Alguns agentes priorizam a precisão e o raciocínio mais profundo, mesmo que isso signifique maior uso de tokens e latência. Outros priorizam a velocidade e o menor custo, com menor robustez comportamental.
Inteligência de modelo versus arquitetura de agentes
As diferenças de desempenho entre ferramentas CLI com agentes não provêm de uma única fonte. Elas emergem de duas camadas: o modelo de base e a estrutura de orquestração que o envolve.
O modelo fundamental determina o quão bem o sistema entende os requisitos, planeja tarefas de várias etapas e gera código correto. Se o modelo interpretar erroneamente uma restrição ou produzir lógica incorreta, nenhuma orquestração poderá compensar totalmente esse erro.
A arquitetura do agente, no entanto, determina como esse modelo é usado. Ela decide como o contexto é coletado do espaço de trabalho, quando os comandos do shell são executados, como as saídas são validadas e se o sistema tenta novamente após uma falha. Essas decisões moldam o comportamento em tempo de execução, o custo e a confiabilidade.
Dois agentes, equipados com modelos igualmente capazes, podem se comportar de maneira diferente. Um pode tentar novamente de forma agressiva após uma falha parcial, consumindo mais tokens, mas se recuperando de erros iniciais. Outro pode encerrar rapidamente após a primeira inconsistência. Um pode impor uma validação rigorosa antes de prosseguir, enquanto o outro pode continuar com suposições não verificadas.
Este teste avalia o sistema completo. Ele não isola a inteligência bruta do modelo da lógica de orquestração. Quando um agente consome tokens em excesso ou falha em um contrato de backend, a causa pode estar na qualidade do planejamento, na política de repetição, no gerenciamento de contexto ou na rigidez da validação.
Compreender essa distinção é essencial. O uso elevado de tokens não indica necessariamente um raciocínio mais profundo, e uma pontuação mais baixa não implica automaticamente uma capacidade inferior do modelo subjacente. Em ambientes autônomos, a arquitetura e o raciocínio do modelo interagem continuamente.
Comportamentos dos agentes na tarefa 6
Avaliamos os agentes em 10 tarefas. Abaixo, apresentamos uma análise detalhada da Tarefa 6 para ilustrar como diferentes arquiteturas de agentes se comportam sob as mesmas restrições.
Tarefa 6: Sistema de tickets de suporte (Web)
A tarefa 6 exigia a construção de um sistema completo de tickets de suporte técnico com:
- Duas funções de usuário (cliente e agente)
- Autenticação baseada em JWT
- Transições de fluxo de trabalho de status rígido
- Isolamento de dados (404 em vez de 403 para acesso entre usuários)
- Backend FastAPI
- Interface React/Vue/Svelte + Vite
- Comandos de execução determinísticos
O teste de fumaça comprovou:
- Exame de saúde
- Autenticação de dupla função
- Operações CRUD de tickets
- Tarefa e respostas
- Transições de status
- Aplicação de funções
- Isolamento de dados
- Comportamento de login e pós-login na interface do usuário
Esta tarefa enfatiza o gerenciamento de estado, a correção da autenticação, a disciplina de contratos REST e a integração entre front-end e back-end. Visite o GitHub para ver os detalhes da tarefa.
Códice
Instalação
Instale globalmente com:
- npm install -g @openai/codex
Alternativamente, instale globalmente com o Homebrew (macOS/Linux)
- instalação do brew –cask codex
Autenticação
Após configurar o Codex, você pode continuar com sua conta ChatGPT ou com sua chave de API OpenAI. Nenhuma opção de provedor disponível.
Relatório de Tarefas
A Codex construiu um sistema funcionalmente correto, mas divergiu do contrato REST especificado. A escolha de um método reduziu a conformidade estrita, apesar da lógica de negócios estar correta.
Comportamento do backend
A autenticação, as operações CRUD de tickets, as respostas e as transições de status funcionaram corretamente. A aplicação de funções e o isolamento de dados foram implementados adequadamente.
O principal problema era a incompatibilidade do método HTTP. O Codex implementou /tickets/{id}/assign e /tickets/{id}/status como endpoints PATCH, enquanto o teste básico exigia PUT.
O modo adaptativo recuperou algumas funcionalidades ao tentar métodos alternativos. O modo estrito falhou em todas as etapas relacionadas a esses pontos finais.
Comportamento da interface do usuário
O frontend passou por todas as etapas de validação da interface do usuário. O fluxo de login e o estado pós-login se comportaram corretamente.
Junie
Instalação
Junie está disponível através do JetBrains Toolbox ou como uma CLI independente:
- curl -fsSL https://junie.jetbrains.com/install | bash
Autenticação
Continue com sua conta JetBrains ou gere uma chave JUNIE_API_KEY em junie.jetbrains.com/cli, ou exporte sua própria chave de API de Anthropic, OpenAI, Google ou outros provedores compatíveis. Diversas opções de provedores disponíveis.
Relatório de Tarefas
Junie criou um sistema completo full-stack em 327 segundos. Autenticação, CRUD e isolamento de dados funcionaram corretamente. Duas escolhas de design de endpoint causaram seis falhas no backend. O frontend passou em todas as etapas de validação funcional, mas renderizou uma interface somente de texto, sem estilo visual ou identidade visual.
Comportamento do backend
Junie gerou um backend FastAPI com 8 arquivos e um frontend React + Vite com Tailwind CSS. Os dados iniciais incluíam 2 usuários e 3 tickets com diferentes status.
A autenticação, as operações CRUD de tickets, as respostas, a visualização de detalhes e o isolamento de dados funcionaram corretamente. Nove das 16 etapas da API foram concluídas com sucesso.
As seis etapas com falha decorreram de dois problemas. Primeiro, /tickets/{id}/assign foi implementado como POST em vez do esperado PUT, causando a falha na etapa de atribuição. Segundo, não existia um endpoint dedicado para /tickets/{id}/status. As transições de status eram tratadas por meio de um endpoint PUT unificado em /tickets/{id} com um campo no corpo da requisição. O teste de fumaça teve como alvo /tickets/{id}/status diretamente, retornando um erro 404.
A lógica de transição em si foi implementada corretamente. O mapa de transição válido impôs a transição de aberto para em andamento, de em andamento para aguardando atendimento do cliente ou resolvido, de resolvido para reaberto e de reaberto para em andamento. Restrições de função para resolução (somente para o agente) e reabertura (somente para o cliente) estavam presentes no manipulador de atualização unificado. O endpoint de atribuição também fez a transição automática de tickets abertos para em andamento.
Comportamento da interface do usuário
O frontend passou por todas as 8 etapas de validação. O formulário de login foi renderizado corretamente, a autenticação foi mantida e o comportamento pós-login funcionou conforme o esperado. Não houve travamentos em tempo de execução nem erros no console.
Kiro CLI
Instalação
Para macOS/Linux/WSL:
- curl -fsSL https://cli.kiro.dev/install | bash
AppImage alternativo para Linux (opção portátil):
- Faça o download em: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage
Em seguida, execute:
- chmod +x kiro-cli.appimage && ./kiro-cli.appimage
Autenticação
Você pode continuar com seu plano Kiro-Code. Nenhuma opção de provedor disponível.
Relatório de Tarefas
A Kiro produziu a implementação mais rápida e compacta. Transições de status, imposição de funções e isolamento de dados foram implementados corretamente no nível lógico.
No entanto, o mesmo padrão de design de endpoint de atualização unificada visto no Aider causou seis falhas de contrato. Um problema no ciclo de vida do frontend reduziu ainda mais a pontuação da interface do usuário. O sistema é estruturalmente sólido, mas diverge do design de API especificado.
Comportamento do backend
O Kiro gerou uma implementação compacta de pilha completa em aproximadamente 97 segundos. O backend consistia em um arquivo main.py de 324 linhas, e o frontend era um aplicativo React de arquivo único com 276 linhas. No total, foram gerados apenas 9 arquivos. Os dados iniciais incluíam 4 tickets de exemplo com diferentes status.
A autenticação, as operações CRUD de tickets, as respostas, a visualização de detalhes e o isolamento de dados funcionaram corretamente. Nove das 16 etapas da API foram concluídas com sucesso.
Os seis passos com falha correspondem a /tickets/{id}/assign e /tickets/{id}/status. A Kiro implementou um endpoint PATCH unificado em /tickets/{id} que atualiza o status, a prioridade e a atribuição por meio de campos JSON no corpo da requisição. A lógica de negócios está correta, mas a estrutura do endpoint não corresponde ao contrato esperado, resultando em respostas 404.
Comportamento da interface do usuário
A verificação prévia do backend foi bem-sucedida e o frontend iniciou com êxito. O Vite foi executado sem falhas em tempo de execução.
No entanto, o formulário de login não foi exibido. O Playwright atingiu o tempo limite de 7 segundos aguardando o campo de entrada de e-mail. O diagnóstico do console mostrou um erro 422 durante o carregamento inicial da página, provavelmente causado por uma chamada /auth/me executada na montagem sem um token válido. Isso impediu a renderização do componente de login e bloqueou as etapas restantes da interface do usuário.
Código Claude
Instalação
Para macOS/Linux/WSL, dependendo do seu gerenciador de pacotes preferido, você pode instalar o Claude Code com um dos seguintes métodos:
- curl -fsSL https://claude.ai/install.sh | bash
- instalação do brew –cask codex
Autenticação
Após configurar o Código Claude, você pode continuar usando sua Conta Claude. Nenhuma opção de provedor disponível.
Relatório de Tarefas
Claude Code produziu uma das bases de código mais estruturadas nesta tarefa. No entanto, um problema fundamental na validação do JWT tornou o backend inutilizável.
Isso destaca uma distinção fundamental na avaliação de agentes: a completude estrutural não compensa a correção da autenticação.
Além disso, consumiu o maior volume de tokens entre os agentes avaliados na Tarefa 6.
Comportamento do backend
Os endpoints de login retornaram 200 e emitiram tokens JWT com sucesso. No entanto, todas as solicitações autenticadas subsequentes retornaram 401 "Não foi possível validar as credenciais".
A causa raiz parece ser uma incompatibilidade entre OAuth2PasswordBearer(tokenUrl=”auth/login”) e o prefixo da rota /auth. O adaptador smoke descobriu corretamente o endpoint de login, mas os tokens emitidos não foram aceitos pelo middleware.
Como resultado, 13 das 16 etapas de processamento no backend falharam.
Além disso, Claude Code implementou um único endpoint PATCH /tickets/{id} para atualizações em vez de endpoints dedicados /assign e /status. No entanto, essa escolha de design tornou-se irrelevante devido à falha de autenticação.
Comportamento da interface do usuário
O formulário de login foi exibido corretamente. O envio do formulário retornou o código 200. No entanto, após o login, o Playwright detectou uma falha de navegação:
“O contexto da execução foi destruído.”
Os registros do navegador mostraram respostas 401 em chamadas de API autenticadas, o que causou a quebra do estado pós-login.
Auxiliar
Instalação
Se você já tiver o Python 3.8-3.13 instalado, primeiro instale o Aider:
- python -m pip instalar auxiliar-instalar
- auxiliar-instalar
Autenticação
Faça login na sua conta OpenRouter e autorize, ou exporte sua chave de API no seu ambiente com:
- export OPENROUTER_API_KEY=”sk-or-v1-…”
Relatório de Tarefas
O Aider foi o construtor mais rápido e com melhor aproveitamento de tokens. No entanto, o design da sua API divergiu da especificação e a interface de login não foi renderizada corretamente.
Comportamento do backend
A autenticação, as operações CRUD de tickets, as respostas, a visualização de detalhes e o isolamento de dados foram implementados corretamente.
Em vez de endpoints dedicados para /assign e /status, o Aider usou um endpoint PUT unificado /tickets/{id} para todas as atualizações. O teste de fumaça esperava endpoints separados, causando falhas 404 nas etapas de atribuição e status.
Comportamento da interface do usuário
O conteúdo foi renderizado na interface, mas o formulário de login não apareceu. O Playwright atingiu o tempo limite de espera pelo campo de entrada de e-mail. As etapas subsequentes da interface do usuário foram bloqueadas.
OpenCode
Instalação
Para macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Instale globalmente com:
- npm i -g opencode-ai
Para macOS/Linux, considere o gerenciador de pacotes de sua preferência:
- bun add -g opencode-ai
- brew install anomalyco/tap/opencode
- paru -S opencode
Autenticação
Existem várias opções de provedores; selecione o provedor desejado e autentique-se com /connect.
Relatório de Tarefas
O OpenCode produziu a implementação mais compatível com a especificação, com apenas uma pequena exceção. Além disso, consumiu o menor volume de tokens entre todos os agentes nesta tarefa.
Comportamento do backend
A autenticação, as operações CRUD, as respostas, a atribuição, as transições de status, a aplicação de funções e o isolamento de dados foram implementados corretamente.
Os endpoints /tickets/{id}/assign e /tickets/{id}/status foram implementados conforme o esperado.
A única falha ocorreu quando o agente tentou definir o status como "em andamento" após a atribuição. Como a operação de atribuição já havia alterado o status do ticket para "em andamento", a segunda transição retornou o código 400 devido à aplicação estrita da política de não operação (no-op).
O comportamento do servidor estava logicamente correto, mas o teste de fumaça esperava sucesso idempotente para transições repetidas.
Comportamento da interface do usuário
O frontend passou por todas as 8 etapas de validação. O login foi exibido corretamente, a autenticação foi mantida e o comportamento pós-login funcionou conforme o esperado.
Forja
Instalação
Para macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Autenticação
Configure suas credenciais de provedor interativamente por meio de:
- login do provedor forge
E escolha seu provedor.
Relatório de Tarefas
Uma única configuração incorreta de roteamento desencadeou falhas em cascata no backend. A quantidade relativamente baixa de tokens de saída sugere uma implementação com profundidade limitada.
Comportamento do backend
O login foi bem-sucedido e os tokens foram emitidos.
A criação do ticket retornou redirecionamentos 307 em vez de 200/201. Como a criação do ticket falhou, as etapas subsequentes que faziam referência a $created_ticket.id falharam com erros 422.
As respostas 307 provavelmente decorrem do comportamento de redirecionamento da barra invertida final no FastAPI.
Os endpoints /assign e /status retornaram 404.
Comportamento da interface do usuário
O frontend exibia o conteúdo, mas os componentes de login não eram renderizados corretamente devido a erros de tempo de execução no arquivo AuthContext.tsx. As etapas subsequentes da interface do usuário eram bloqueadas.
Gemini CLI
Instalação
Execute instantaneamente com:
- npx @google/gemini-cli
Instale globalmente com:
- npm install -g @google/gemini-cli
Instale globalmente com o Homebrew (macOS/Linux):
- brew install gemini-cli
Instale globalmente com o MacPorts (macOS):
- sudo port install gemini-cli
Instale com o Anaconda (para ambientes restritos):
- conda create -y -n gemini_env -c conda-forge nodejs
- conda activate gemini_env
Autenticação
Opção 1: Entrar com Google (login OAuth usando sua conta Google):
Comece com Gêmeos e escreva:
- export GOOGLE_CLOUD_PROJECT=”SEU_ID_DO_PROJETO”
Em seguida, inicie o Gemini.
Opção 2: Chave da API Gemini
Comece com Gêmeos e escreva:
- export GEMINI_API_KEY=”SUA_CHAVE_DE_API”
Em seguida, inicie o Gemini.
Opção 3: IA de vértices
Comece com Gêmeos e escreva:
- export GOOGLE_API_KEY=”SUA_CHAVE_DE_API”
- exportar GOOGLE_GENAI_USE_VERTEXAI=true
Relatório de Tarefas
O Gemini CLI gerou um backend robusto, mas falhou devido à incompatibilidade com o conjunto de ferramentas do frontend. Além disso, consumiu o maior volume de tokens entre as implementações de backend bem-sucedidas.
Comportamento do backend
Autenticação, operações CRUD, respostas, atribuição, imposição de funções e isolamento de dados foram implementados corretamente.
No entanto, o endpoint /tickets/{id}/status estava completamente ausente, fazendo com que todas as etapas de transição de status retornassem 404.
Comportamento da interface do usuário
A interface não pôde ser iniciada. O Vite 7.3.1 estava instalado, o qual requer o Node.js 20.19 ou superior, enquanto o ambiente de teste executa o Node.js 18.18.0. A API crypto.hash, necessária para o Vite, estava indisponível.
Como resultado, a interface do usuário nunca foi lançada e obteve a pontuação de 0/8.
Cline
Instalação
Instale globalmente com:
- npm install -g cline
Autenticação
Ao digitar `cline auth`, você pode selecionar sua conta Cline ou continuar com o provedor desejado.
Relatório de Tarefas
O mecanismo de limite de erros do Cline interrompeu a compilação antes da conclusão. A estrutura do backend demonstra a intenção arquitetônica correta, mas problemas no registro de rotas e uma implementação incompleta impediram a validação funcional.
A ausência de uma interface de usuário e as falhas em cascata no backend colocam este resultado entre os mais fracos da Tarefa 6.
Comportamento do backend
Cline gerou um backend com cinco arquivos: main.py, models.py, schemas.py, auth.py e database.py, juntamente com um arquivo requirements.txt. A estrutura incluía modelos adequados, estrutura de autenticação JWT e stubs de endpoint.
No entanto, o agente atingiu seu limite de oito erros durante o desenvolvimento do backend e foi encerrado antes de concluir o sistema.
Apenas os endpoints de login funcionaram corretamente. Três das 16 etapas da API foram concluídas com sucesso.
A criação do ticket retornou redirecionamentos 307 em vez de 200 ou 201, provavelmente devido a incompatibilidades de rotas com barra invertida no final. Como a criação do ticket falhou, o valor de `$created_ticket.id` nunca foi capturado. Todas as etapas subsequentes que faziam referência ao ID do ticket passaram o valor literal da string, resultando em erros 422.
Os endpoints /tickets/{id}/assign e /tickets/{id}/status não foram implementados, resultando em respostas 404.
Isso produziu um padrão de falha em cascata semelhante ao do Forge, onde um problema inicial de roteamento invalidou as etapas subsequentes.
Comportamento da interface do usuário
O servidor foi iniciado com sucesso. No entanto, o diretório frontend/ estava vazio e não havia nenhum arquivo package.json.
Apenas a etapa de verificação prévia no backend foi aprovada. Todas as demais etapas da interface do usuário foram bloqueadas.
Ganso
Instalação
Para macOS/Linux/WSL:
- curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
Modelo: Gemini 3 Pro Preview (via OpenRouter)
Tempo: 1.297s
Tokens: 17 mil de entrada / 752 de saída
Pontuação da API: 60%
Pontuação da interface do usuário: 0%
Goose demonstrou capacidade limitada de autocorreção, mas não conseguiu cumprir o requisito de pilha completa. Problemas de confiabilidade durante novas execuções levantam preocupações quanto à estabilidade.
Comportamento do backend
Autenticação, operações CRUD em tickets, respostas, visualização de detalhes e isolamento de dados funcionaram corretamente.
No entanto, os endpoints /assign e /status não foram implementados, causando respostas 404 para todas as etapas relacionadas.
Em uma versão anterior, o Goose encontrou erros de compatibilidade com o bcrypt, que foram corrigidos automaticamente ao fixar a versão da dependência, e finalmente o backend foi iniciado.
Uma nova execução posterior apresentou falha devido a um erro de decodificação de fluxo após a geração mínima de arquivos.
Comportamento da interface do usuário
Nenhum frontend foi criado. O diretório do frontend estava vazio e não existia o arquivo package.json. O teste de interface do usuário falhou imediatamente.
ferramentas de codificação de IA
As ferramentas de codificação de IA podem ser agrupadas em três categorias:
- Agentic CLI: Ferramentas para fluxos de trabalho de desenvolvimento baseados em terminal, que permitem gerar, editar e refatorar código por meio de prompts e interações na linha de comando.
- Exemplos: Aider, Junie, Opencode, Claude Code, Codex
- Editores de código com IA : Também conhecidos como IDEs agéticos, essas ferramentas fornecem uma interface gráfica semelhante ao VS Code (a maioria delas é baseada no VS Code).
- Exemplos: Antigravidade, Cursor, Código Kiro, Windsurf
- Construtores de aplicativos baseados em prompts : Plataformas de baixo código/sem código para criar aplicativos usando prompts em linguagem natural e fluxos de trabalho visuais.
- Exemplos: Bolt, Lovable, v0.dev, Firebase Studio, Dazl
ferramentas de revisão de código de IA
Com a crescente popularidade do código gerado por IA, as ferramentas de revisão de código tornam-se essenciais para detectar bugs e vulnerabilidades. Avaliamos as principais ferramentas em 309 Pull Requests em nosso benchmark RevEval .
O que as ferramentas CLI agéticas podem fazer?
Em ferramentas como Codex, Junie, Kiro e Claude Code, as funcionalidades comuns incluem:
- Desenvolvimento de código de ponta a ponta: Criar e modificar arquivos, corrigir erros, refatorar código e executar testes ou linters diretamente do terminal.
- Fluxos de trabalho agéticos: Executam tarefas de várias etapas, como encadeamento de tarefas, resolução de problemas, pesquisa e depuração iterativa.
- Git e gerenciamento de projetos: revise o histórico, resolva merges, gerencie branches e crie commits ou pull requests.
- Command Execução e automação: Execute comandos de shell, automatize análises e traduza linguagem natural em operações complexas de CLI.
- Gerenciamento de contexto profundo: Opera em repositórios completos com conhecimento de dependências e estrutura do projeto.
- Flexibilidade de modelo: Suporte a múltiplos modelos de nuvem e, em alguns casos, modelos locais; algumas ferramentas permitem o uso de sua própria chave de API ou a escolha entre planos.
- Acesso controlado ou em sandbox: Ofereça modos que variam de somente leitura à automação completa, frequentemente com ambientes isolados para maior segurança.
Metodologia
Avaliamos os agentes em um cenário de execução única para medir suas capacidades autônomas sem intervenção humana. Em seguida, os agentes foram avaliados usando nossos testes de fumaça de backend e frontend para medir a prontidão da infraestrutura e a correção de comportamento.
As pontuações refletem a confiabilidade com que cada agente produziu sistemas executáveis e quantos requisitos funcionais foram validados.
Configuração do modelo
Nosso objetivo era usar o recurso Google devido à sua grande janela de contexto , adequada para orquestração de múltiplos arquivos e prompts de tarefas longos. No entanto, algumas CLIs agenticas são fortemente acopladas a provedores específicos:
- O código Claude foi avaliado usando claude-opus-4-5-20251101 através da API oficial de Anthropic.
- O Codex foi avaliado usando gpt-5.2-codex-medium através da configuração nativa de OpenAI.
Para esses agentes, provedores de modelos alternativos não são suportados em sua arquitetura de CLI atual. Cada agente foi avaliado usando sua configuração padrão. Não ajustamos a temperatura, as políticas de repetição ou os parâmetros de raciocínio.
Nosso objetivo de avaliação era separar e medir:
- Capacidade de construção (o agente consegue gerar código executável?)
- Correção do comportamento do backend
- Correção do comportamento do frontend
- Confiabilidade da orquestração autônoma
Versões da CLI (meados de fevereiro de 2026)
- Opencode: v1.2.10
- Cline: v3.41
- Aider: v0.86.0
- CLI Gemini: v0.29.0
- Forge: v1.28.0
- Codex: 0.104.0
- Ganso: v1.25.0
- Código Claude: v2.1.62
- Junie: 888.212
- Kiro CLI: 1.26.0
Para obter informações sobre a metodologia de avaliação, visite: Metodologia de avaliação comparativa de codificação de IA
Leia mais
Para quem está explorando o ecossistema mais amplo de ferramentas de desenvolvimento baseadas em agentes, aqui estão nossos benchmarks mais recentes:
- Análise comparativa do MCP : Uma comparação dos melhores servidores MCP para acesso à web.
- Navegadores remotos : como a infraestrutura de navegadores emergente permite que agentes de IA interajam com a web de forma segura.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.