Cline refaz núcleo de agente migrando 11 milhões de usuários

A necessidade da migração

O Cline, extensão de código agentic lançada em 2024 logo após o Claude 3.5 Sonnet, tinha seu produto original - a extensão VS Code, com mais de 11 milhões de desenvolvedores - rodando sobre um núcleo monolítico de cerca de 76.000 linhas, separado do Cline SDK usado pelos produtos mais novos (JetBrains, CLI, SDK). Cada melhoria de agente, provedor ou modelo exigia trabalho manual e uma nova release. A empresa decidiu substituir o monolito pelo SDK, que automatiza boa parte desse trabalho e traz melhorias de desempenho, especialmente em modelos open-weights. Uma primeira tentativa levou meses e falhou de forma grave o suficiente para exigir rollback imediato, forçando a equipe a repensar tanto a migração quanto o processo de distribuição segura.

Limitações do VS Code Marketplace

O Marketplace só permite publicar para 100% dos usuários, sem lançamento gradual, grupo de teste ou reversão para versão inferior - as versões são estritamente monotônicas, e corrigir uma release problemática significa publicar outra mais alta e esperar horas ou dias. A solução foi transformar a própria extensão no mecanismo de rollout: uma instalação passa a incluir um script carregador de ~46 KB, a extensão legada (pasta legacy/) e a nova baseada no SDK (pasta next/). A cada abertura de janela, o loader decide qual pacote ativar com base em um feature flag do PostHog com percentual gradual. Se a versão nova falha na ativação, o loader cai automaticamente para a legada e fixa a máquina nesse grupo. O flag funciona como kill switch, permitindo reduzir o rollout a 0%. Os dois pacotes compartilham as mesmas configurações, credenciais e armazenamento de tarefas, e o build gera um manifest unificado com verificação que impede divergência de views e schemas entre os dois ramos.

Teste A/B e instrumentação

Cada evento de telemetria das builds de rollout carrega a variante (next ou legacy). A equipe recomenda instrumentar o sistema antigo antes de compará-lo com o novo - o que exigiu adicionar eventos e métricas ao harness antigo com semântica idêntica. O indicador central foi task.mistake_limit_reached, comportamento em que o agente para após três erros consecutivos e pede orientação humana, historicamente a reclamação mais frequente do harness antigo, muitas vezes por falhas de chamadas de ferramenta causadas pelo próprio harness. O rollout gradual durou quase um mês, com divisão próxima de 50/50 por mais de uma semana como janela mais limpa de A/B, antes de ir a 100%.

Resultados

Com os grupos próximos de 50/50 e um dia inteiro de tráfego de produção cada, 6,34% das tarefas no harness antigo atingiram o limite de erros, contra 0,62% no novo - 10x menos. Por modelo: claude-sonnet-5 caiu de 6,7% para 0,63% (11x), deepseek-v4-flash de 13,4% para 1,30% (10x), deepseek-v4-pro de 11,5% para 1,14% (10x), claude-sonnet-4-6 de 4,0% para 0,62% (6x) e gpt-5.6-sol de 4,1% para 0,70% (6x). A nota metodológica indica que a atribuição de eventos é ligeiramente enviesada contra o motor novo, tornando os múltiplos conservadores. O ganho é maior em modelos open-weights.

Por que o harness antigo envelheceu

O harness original foi desenhado em meados de 2024 em torno do Claude 3.5 Sonnet, quando as ferramentas eram descritas no prompt de sistema e invocadas por tags XML parseadas do fluxo de texto do modelo. Modelos de 2026 são treinados com RL para chamar ferramentas nativamente; envolvê-los em um harness de formato 2024 gera um imposto por turno: problemas de formato, falhas de parse, repetições e o limite de erros.

Conclusão

Em 23 de agosto o rollout atingiu 100%: toda janela do Cline atualizada roda a extensão SDK, no mesmo motor do CLI e do SDK. A migração exigiu descontinuar alguns recursos pouco usados, mas a empresa afirma que agora melhorias de agente, ferramentas, provedores e capacidades de modelos chegam mais rápido a todos os produtos, com melhor eficiência de tokens, custos reduzidos e melhores resultados.