Modelos de IA abertos esbarram em um duro obstáculo na programação

Modelos abertos, incluindo Kimi, GLM, DeepSeek e Qwen, frequentemente apresentam pontuações impressionantes em benchmarks, chegando por vezes a igualar ou superar modelos de fronteira como o Claude Opus, da Anthropic, e o Project Project Astra, da OpenAI. Essas vitórias, no entanto, muitas vezes dependem do contexto, refletindo o desempenho em desafios de programação específicos e autocontidos, e não todo o espectro do desenvolvimento de software.

Uma distinção crucial está na complexidade e na duração da tarefa. Os modelos abertos se destacam em tarefas curtas e pontuais, nas quais um raciocínio sólido pode ser aplicado a problemas isolados. Isso os torna muito eficazes para diversas automações de negócios e etapas individuais de fluxos de trabalho.

A engenharia de software no mundo real, por outro lado, exige que o agente seja capaz de manter o contexto, seguir instruções em evolução e preservar decisões arquiteturais ao longo de numerosas chamadas de ferramentas e refinamentos iterativos. Essa consistência de longo horizonte é onde os modelos abertos atualmente ficam aquém.

Embora os benchmarks ofereçam sinais valiosos, eles não captam totalmente a proficiência de programação de ponta a ponta. Recursos como o SWE-bench oferecem uma avaliação mais abrangente das capacidades de engenharia de software de um modelo, evidenciando a lacuna entre o desempenho em tarefas isoladas e o trabalho sustentado em projetos.

Os modelos abertos, no entanto, justificam seu uso em contextos mais delimitados. Em tarefas específicas e contidas, como redigir uma função, transformar um esquema ou gerar testes unitários, esses modelos podem oferecer qualidade comparável à dos modelos de fronteira, segundo a experiência prática de Medin. Essa paridade se estende a muitas etapas rotineiras dentro de automações de negócios.

As empresas frequentemente utilizam modelos abertos para controlar gastos e manter a privacidade dos dados, executando-os localmente ou por meio de APIs de baixo custo. Um modelo de primeira linha, como o Project Project Astra ou o Claude Opus 5.5, nem sempre é necessário para tarefas como:

• Validação de dados
• Geração simples de conteúdo
• Lógica interna de roteamento de API

É fundamental notar que o custo não é uma simples comparação por token. O preço real de um resultado bem-sucedido inclui a confiabilidade, a frequência de novas tentativas, o esforço humano necessário para a revisão e o custo potencial de uma alteração malsucedida. Embora os modelos abertos possam parecer mais baratos pela contagem bruta de tokens, suas limitações de contexto em tarefas complexas de longo horizonte podem levar a despesas totais mais altas devido ao aumento de iterações e correções. Essa nuance é essencial para uma alocação eficaz de recursos.

Os modelos abertos falham de forma drástica quando os fluxos de trabalho de programação ampliam o escopo. Medin observa que eles frequentemente perdem de vista as convenções do repositório, ignoram restrições estabelecidas e se enredam em ciclos custosos de revisão e correção. Essa "falha de longa duração" decorre da incapacidade de manter a atenção sobre um conjunto crescente de regras e contexto.

Para quantificar isso, Medin conduziu um experimento controlado construindo um jogo Northstar. Ele atribuiu 12 tickets de funcionalidades a três modelos: Claude, OpenAI e Kimi. O Claude concluiu os 12 tickets em aproximadamente 14 horas. A OpenAI finalizou 11 tickets, mas precisou de cerca de 28 horas. O Kimi, por outro lado, conseguiu concluir apenas 5 tickets em 44 horas.

Essa comparação, embora seja o teste de um único criador e não um ranking universal, ilustra de forma contundente como a aderência às instruções e a sobrecarga de iterações podem moldar os resultados de um projeto. Os modelos abertos muitas vezes geram custos totais mais altos devido ao gasto repetido de tokens em correções e novas tentativas, apesar do preço menor por token. Para explorar melhor as metodologias de benchmark, consulte o SWE-bench Official Benchmark and Leaderboard.

Essa diferença de desempenho sugere uma distinção fundamental na forma como os modelos lidam com tarefas de longo horizonte. Embora os modelos abertos possam se destacar na geração de código isolado, eles têm dificuldade com a consciência contextual sustentada necessária para o desenvolvimento de software complexo, no qual o modelo precisa integrar mudanças em uma grande base de código respeitando restrições e princípios de design em evolução.

Em vez de uma aposta de tudo ou nada, um fluxo de trabalho híbrido oferece utilidade imediata. Encaminhe tarefas pontuais e bem delimitadas, como redigir uma função ou transformar um esquema, para modelos abertos, aproveitando sua eficiência de custo e seu desempenho competitivo em problemas delimitados. Reserve sistemas de fronteira, como o Claude Opus, para planejamento arquitetural complexo, revisões de alto risco e mudanças que abrangem uma grande base de código.

Mantenha a estrutura de execução (harness) explícita e robusta. Divida o trabalho em tickets menores, imponha convenções de código com testes automatizados e linting, e meça continuamente as principais métricas. Acompanhe as taxas de conclusão, o número de novas tentativas, as falhas de revisão e o custo por alteração integrada para avaliar de forma objetiva o desempenho e a eficiência dos modelos.

Os modelos abertos já são práticos, mas a paridade em benchmarks não garante que consigam operar uma fábrica de software inteira. As equipes devem testar os modelos com rigor em seus próprios fluxos de trabalho, transferindo responsabilidades à medida que a confiabilidade melhorar de forma comprovada. Essa abordagem pragmática e orientada por dados permite integrar de forma estratégica a inovação de código aberto, mitigando os riscos de desvio em longo horizonte e de execução inconsistente.

Por que os modelos abertos podem ter boas pontuações em benchmarks de programação, mas enfrentar dificuldades em projetos reais?

Os benchmarks costumam testar tarefas delimitadas, enquanto projetos reais exigem que os agentes sigam regras, mantenham o contexto e tomem decisões consistentes ao longo de muitas etapas.

Os modelos de pesos abertos são úteis para programação com IA?

Sim. Eles podem ter bom desempenho em tarefas pontuais e curtas e em etapas rotineiras de fluxos de trabalho, especialmente quando a tarefa tem um escopo bem definido.

O que é uma tarefa de programação de longo horizonte?

É um trabalho que abrange muitas etapas, como planejar, editar arquivos, executar testes, responder a revisões e manter a consistência em toda uma base de código.

Como as equipes podem usar modelos abertos sem depender deles para tudo?

Use modelos abertos para tarefas bem definidas e de menor risco, e reserve os modelos de fronteira para planejamento complexo, revisão e trabalhos que exigem contexto sustentado.