Como usar o SWE-2 para escrever testes que pegam regressões e casos extremos

Fala aí, beleza? A Cognition soltou o SWE-2 no dia 10 de setembro de 2026 e o ponto que ela mais bateu no anúncio não foi "escreve código bonito": foi escrever teste que checa a implementação de ponta a ponta e pega regressão

Teste que nunca pode falhar não é teste, é enfeite 🙂

Então este post vai direto nisso: COMO formular o pedido de testes pro SWE-2, o que dá pra esperar da resposta e onde o modelo já mostrou que não é o melhor da turma. Sem fórmula mágica, e sem eu fingir que rodei bateria de teste aqui: o que é afirmação da Cognition, eu digo que é afirmação da Cognition

O que é o SWE-2 e por que ele mira testes end to end

O SWE-2 é o novo modelo de engenharia de software da linha SWE, da Cognition

A base dele é curiosa: ele é pós-treinado a partir do Kimi K3, o modelo base da Moonshot AI com 2,8 trilhões de parâmetros

"Que pós-treinado?" Pega um modelo base que já sabe muita coisa e treina em cima dele pra ele ficar bom numa tarefa específica. É como pegar um dev generalista muito bom e botar ele seis meses só mexendo em suíte de teste

No blog oficial da Cognition a frase é essa, sem meio termo: "SWE-2 is better at writing tests that check an implementation end-to-end, catching regressions and edge cases more reliably"

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Ou seja: melhor em escrever testes que checam a implementação de ponta a ponta, pegando regressões e casos extremos de forma mais confiável

A Cognition aponta três mudanças de comportamento em relação à geração anterior, o SWE-1.7:

• Cobertura de testes end to end mais ampla, não só a função isolada
• Mais jeito pra achar alternativas quando o caminho óbvio não está disponível
• Verificação mais forte quando o modelo é contestado, ou seja, quando tu empurra de volta e pergunta "tem certeza?"

Guarda esse terceiro ponto, porque ele vira um passo do tutorial lá embaixo 😀

O que você precisa antes de começar

Primeiro, onde o bicho roda hoje: Devin Desktop e Devin CLI

No Devin Desktop, a seleção de modelo fica num menu suspenso logo abaixo da caixa de texto do prompt

Agora a parte que quase ninguém fala no hype de lançamento, e que muda teu planejamento: até 11/09/2026 não existe API avulsa do SWE-2, não existe tabela de preços por token publicada e os pesos não são abertos

Repara que uma coisa não anula a outra: a Cognition divulgou comparações relativas de custo (aquelas porcentagens que eu mostro na seção mais pra baixo), mas isso não é o mesmo que um preço por token que tu consegue calcular na planilha

Traduzindo pro teu dia a dia: não dá pra plugar ele direto no teu pipeline de CI por API e sair chamando o modelo a cada pull request. O uso é dentro dos produtos da Devin, ponto

Do lado do teu projeto, o mínimo pra esse tutorial fazer sentido:

• o código da feature alvo acessível pro agente
• uma suíte de testes que já roda antes de tu pedir qualquer coisa
• saber qual comando roda essa suíte no teu projeto

Esse segundo item não é frescura. Se o agente não consegue executar o que escreveu, tu não tem teste: tu tem texto com cara de teste

Passo a passo: pedindo testes que pegam regressões e casos extremos

1. Escolha o SWE-2 no seletor de modelo

No Devin Desktop isso é o menu suspenso embaixo da caixa de prompt

O erro comum deste passo: começar a conversa, pedir tudo e só depois lembrar de trocar de modelo. Troca primeiro, pede depois

2. Aponte a implementação alvo E o caminho de ponta a ponta

Aqui é onde a maior parte dos pedidos morre. "Escreva testes pra esse arquivo" gera teste de unidade genérico, daquele que mocka tudo e prova nada

Descreve o trajeto: entrada, efeito no sistema, saída observável

Contexto: módulo de checkout (pasta da feature aberta no projeto)

Caminho end to end que o teste precisa percorrer:
requisição de compra -> reserva de estoque -> gravação do pedido -> resposta com status

Quero o fluxo completo, não teste da função isolada

O erro comum deste passo: pedir "escreva testes" e aceitar o que vier. Pedido vago, teste vago

3. Nomeie a regressão que você teme

O modelo não sabe qual bug já te fez virar a madrugada. Ele não tem memória persistente entre sessões do histórico do teu projeto, então o bug antigo precisa entrar no prompt escrito por você

Regressão que não pode voltar:
quando duas compras chegavam juntas, o estoque ficava negativo
e o pedido era gravado mesmo assim

O erro comum deste passo: descrever o sintoma sem a condição ("dava erro no checkout"). Sem a condição, o teste não reproduz nada

4. Liste os casos extremos que importam no SEU domínio

Caso extremo genérico é null e string vazia. Caso extremo que salva produção é outro

Casos extremos obrigatórios:
- carrinho vazio
- quantidade exatamente igual ao estoque disponível
- duas requisições concorrentes pro mesmo item
- gateway de pagamento fora do ar no meio do fluxo

O erro comum deste passo: deixar a lista por conta do modelo. Ele cobre o óbvio, tu conhece o esquisito

5. Escolha o nível de esforço de raciocínio

O SWE-2 tem três: medium, high e max, treinados numa única rodada de RL com objetivo sensível a custo

Na prática eles se comportam diferente: o medium parte pra ação mais rápido, o que serve bem em tarefa simples e intermediária. Já o high e o max planejam mais, exploram mais o código e lidam com incerteza usando verificação mais complexa

Então: teste de um fluxo pequeno e bem descrito? medium. Área legada, código espalhado, ninguém sabe direito onde aquilo é chamado? aí sobe o nível

O erro comum deste passo: jogar max em tudo porque "é o mais forte". Tu paga mais e espera mais pra ganhar um teste que o medium já entregava

6. Conteste o resultado e peça justificativa

Esse passo existe por causa daquela terceira mudança de comportamento: a Cognition diz que o SWE-2 verifica com mais força quando é contestado

Então contesta mesmo:

Esse teste realmente falha se a reserva de estoque parar de funcionar?
Me mostre qual linha da implementação faz ele quebrar

O erro comum deste passo: aceitar a primeira leva de testes porque "passou tudo verde". Verde de primeira é suspeito, não é vitória

7. Rode a suíte e quebre o código de propósito

Esse é o único jeito honesto de saber se o teste presta. Roda a suíte, vê passar, depois sabota a implementação e roda de novo

// implementação original
if (quantidade > estoque) {
  throw new Error('estoque insuficiente')
}

// sabotagem proposital pra validar o teste
if (quantidade > estoque + 1) {
  throw new Error('estoque insuficiente')
}

Se o teste continuar verde com o código sabotado, ele não testa nada. Volta pro passo 2 e descreve melhor o caminho

O erro comum deste passo: pular ele. É o passo mais chato e o mais importante, sério

Esse ritual de descrever fluxo, nomear regressão e sabotar o código depois não é exclusividade de um modelo só. Vale igual se tu preferir escrever testes automatizados com o Claude Code, a mecânica do pedido é a mesma

Quando vale chamar o SWE-2 para testes (e quando não vale)

Onde encaixa bem:

• Blindar refatoração: escreve os testes ANTES de mexer, garante o comportamento atual, aí tu refatora sem medo
• Fluxo end to end de feature nova: é exatamente o caso que a Cognition destaca
• Área legada com caminho pouco óbvio: a Cognition cita mais jeito pra achar alternativas quando o caminho óbvio não está disponível, e legado é o reino do caminho não óbvio
• Reproduzir um bug antes da correção: primeiro o teste que falha, depois o fix. Clássico e continua valendo

Agora a cautela, porque não é tudo maravilha 😛

Em tarefa agêntica difícil de terminal, o próprio benchmark mostra o SWE-2 bem atrás dos modelos de fronteira:

Isso é distância grande, não é detalhe de casa decimal

A leitura prática: pra aquele trabalho longo de ficar operando o ambiente, mexendo em várias ferramentas e se virando no terminal, tem opção melhor

Pra escrever a suíte que protege tua feature, o apelo dele é outro, e é justamente o que aparece nos números da próxima seção

O que esperar do SWE-2 nesse tipo de tarefa

Os números que existem hoje, sem chute:

• 50,0% no FrontierCode 1.1 Main, que é o benchmark próprio da Cognition
• o medium pontua acima do SWE-1.7 nesse mesmo benchmark com 58% menos turnos e 81% menos custo médio por tarefa
• o custo fica cerca de 64% menor que o Fable 5.1 e em torno de um quarto do GPT-6 Astra

Repara na natureza desses números: benchmark da casa e comparação relativa de custo

É por isso que a ausência de tabela de preços por token não vira contradição aqui: a Cognition fala em quanto ele custa PERTO dos outros, não em quanto ele custa por token na tua conta

O argumento aqui é custo por tarefa em trabalho repetitivo, não estado da arte em tudo. E faz sentido, já que os três níveis de esforço saíram de uma única rodada de RL com objetivo sensível a custo: o modelo foi treinado pra pensar no preço da conversa, não só no resultado

E escrever teste É trabalho repetitivo. É o tipo de coisa que tu roda dez vezes na semana e que não precisa do modelo mais caro do planeta em cada rodada

Só pra deixar registrado sem rodeio: a afirmação de que ele escreve melhor testes end to end é da Cognition, no material de lançamento dela. Não tem verificação independente aqui, e eu não vou inventar uma

Conclusão

A qualidade do teste que sai não depende do modelo ser topzera

Depende de quão bem tu descreve o caminho de ponta a ponta e quais regressões tu realmente teme. Pedido preguiçoso gera teste decorativo, em qualquer modelo

Próximo passo concreto pra hoje: pega uma função que já te deu dor de cabeça, abre o SWE-2 no nível medium, pede o teste descrevendo entrada, efeito e saída observável, e depois quebra o código de propósito

Se o teste ficar verde com o código quebrado, tu descobriu algo mais útil que qualquer benchmark 😀

até o próximo post!