Tusk
Tusk AI, Inc. · Programação · Produtividade
Tusk é um agente de testes com IA que escreve e executa testes unitários e de API em cada pull request e aponta os erros que encontra. A Tusk AI, Inc. encerrou o produto em 10 de junho de 2026.
Sobre Tusk
What Is Tusk
Tusk começou em 2024 na turma W24 do Y Combinator com uma promessa estreita. Você entregava ao agente os bugs que os clientes abriam e recebia um pull request de volta. Equipes pequenas de engenharia perdem tardes inteiras em correções de dez linhas, e Tusk existia para tirar esses chamados do caminho.
Em 2026 o produto já era outra coisa: um agente de testes com IA. Gerava testes unitários e de API para cada pull request, rodava o que tinha escrito e repetia até passar. Testar é a parte do lançamento para a qual ninguém tem tempo, e Tusk se vendia como o colega que faz isso sem você pedir.
Os limites importam para quem avalia o que sobrou. Era preciso um repositório no GitHub, uma suíte de testes já existente e paciência para o agente tentar várias vezes o mesmo teste que falhava. Os números sobre pegar casos de borda vinham de benchmarks da própria empresa, não de uma auditoria independente.
O limite decisivo é a data. A Tusk AI, Inc. anunciou em 11 de junho de 2026 que o produto havia sido encerrado no dia anterior. O GitHub App saiu das organizações dos clientes, quem usava o Tusk Drift precisou desinstalar o SDK e apagar o workflow de CI, e o suporte durou um mês depois disso. A empresa indicou o Devin, da Cognition, para automação de testes e revisão de código.
Getting Started
- Criar a conta no Tusk e instalar o GitHub App nos repositórios que o agente podia ler e alterar.
- Instalar a CLI na raiz de cada serviço, o que levava um comando só, e rodar a configuração inicial para o Tusk indexar os padrões dos seus testes.
- Abrir um pull request como sempre. O Tusk publicava os testes gerados em um comentário, executava tudo no seu CI e continuava ajustando o que falhava.
- Revisar esses testes como qualquer outro código. A empresa dizia que cerca de 69% dos testes gerados terminavam mesclados nos pull requests.
Informações do produto
Uma visão rápida dos preços, das plataformas compatíveis e do desempenho de Tusk.
Ideal para
Os usuários, tarefas e cenários em que esta ferramenta se encaixa melhor.
Usuários
- Equipes pequenas sem alguém dedicado a QA
- Fundadores que ainda revisam código
- Engenheiros de backend e plataforma
Tarefas
- Subir a cobertura antes de um lançamento
- Detectar regressões em pull requests
- Acompanhar contratos de API de terceiros
Cenários
- Um código legado com pouca cobertura e sem orçamento para reescrita
- Um time que publica várias vezes por dia em três ou quatro repositórios
- Comparar ferramentas que já não existem
Principais recursos
Testes unitários para cada pull request
O Tusk lia o diff, buscava contexto nos testes que você já tinha e propunha testes unitários em um comentário do pull request. Executava o que escrevia e repetia os que falhavam, então a saída era código executável, não sugestão. Para um time que via teste como obrigação chata, ter testes funcionando sem abrir o editor era o valor inteiro.
Testes de API a partir de tráfego real
O Tusk Drift gravava o tráfego real nos seus endpoints e transformava aquilo em testes de API. Em vez de escrever mocks, você recebia testes derivados do que o serviço realmente recebia. Isso servia para monitorar contratos, onde uma resposta que muda em silêncio quebra clientes dos quais você só ouve falar quando alguém reclama.
CoverBot preenche a cobertura em uma agenda fixa
O CoverBot funcionava como o Dependabot, só que os pull requests dele vinham cheios de testes unitários em vez de atualizações de dependência. Você apontava para um repositório, escolhia diário ou semanal e deixava rodar. O Tusk falava em 30% mais cobertura em um mês, número da própria casa que vale como direção, não como garantia.
Suítes que se mantêm sozinhas
Testes envelhecem quando a regra de negócio muda. O Tusk atualizava as suítes que falhavam a cada commit para que continuassem refletindo o comportamento atual. É conveniência real e risco real ao mesmo tempo, porque um teste que se reescreve para passar também pode se reescrever por cima de um bug de verdade.
Contexto de Jira, Linear e dos seus próprios testes
O Tusk puxava contexto de negócio dos tickets de Jira e Linear e padrões de código dos testes que o seu time já havia escrito. Os testes gerados seguiam suas convenções de nome e de fixtures em vez de inventar um estilo novo. Quem já tinha testado geradores genéricos costumava citar essa diferença como a primeira que notou.
Revisão de código e correção de bugs
O agente original nunca sumiu de vez. O Tusk continuava revisando pull requests e conseguia seguir o rastro de um bug relatado até a correção. A revisão vinha com o mesmo aviso dos testes: tudo o que é gerado precisa de leitura humana antes do merge.
Prós e contras
Prós
- Os testes chegavam já executados, o que cortava o vai e vem típico dos copilotos de IA.
- O gerador de testes unitários entrava no CI, então a cobertura avançava sem uma sprint separada.
- As integrações com GitHub, Jira e Linear mantinham o contexto nas ferramentas que o time já usava.
- O preço por dev ativo, sem mínimo de licenças, deixava barato testar em um repositório só.
Contras
- O produto acabou. Os repositórios perderam o GitHub App e quem usava o Drift teve de remover código do SDK dos serviços.
- Os benchmarks eram da própria empresa, então a alegação de pegar casos de borda que outros agentes não viam nunca foi verificada por fora.
- O melhor resultado dependia de uma suíte existente e de uma plataforma só. Fora do GitHub, ou sem testes prévios, o rendimento caía bastante.
- Revisão com IA continua precisando de olho humano, e um teste que passa não prova que o código está certo.
Perguntas frequentes
O Tusk gerava testes unitários e de API para pull requests, revisava código e corrigia bugs relatados por clientes. Os times usavam para subir a cobertura e pegar regressões antes do deploy.
Conteúdo relacionado
Explore ferramentas, skills e artigos relacionados a Tusk.
Alternativas a Tusk
Base Code
Base44 (Wix) · Programação · ProdutividadeO Base Code é um ambiente de desenvolvimento em nuvem compartilhado da Base44. O time descreve mudanças em um repositório do GitHub pelo chat, confere tudo na prévia e envia o resultado como pull request.
Google EmbeddingGemma 2
Google DeepMind · Escrita · Imagem · ProgramaçãoGoogle EmbeddingGemma 2 é um modelo aberto de 740 milhões de parâmetros que transforma texto, código, imagens, áudio e quadros de vídeo em vetores de um único espaço de 768 dimensões, rodando em celulares e notebooks.
GitGlow
GitGlow · Programação · ProdutividadeO GitGlow é um cliente Git de desktop que coloca seu código e as mudanças dos seus agentes de IA na mesma revisão, para você saber o que vai sair da máquina antes de publicar.