Testes Automatizados com IA: Como testar seu App com Claude Code e Cursor [2026]

Todo app feito com IA quebra em algum momento, e quase sempre quebra no lugar que ninguém testou. Nós aprendemos isso do jeito caro: uma mudança pequena no formulário de cadastro, pedida em uma frase para o agente, derrubou o login de um projeto interno por uma tarde inteira. Desde então, testes automatizados com IA viraram parte fixa do nosso processo, e o curioso é que a mesma IA que gera o bug é a melhor ferramenta que temos para pegá-lo.

Escrever teste sempre foi a tarefa que todo dev empurra para depois. Dá trabalho, parece não entregar nada visível e fica desatualizado rápido. Com agentes como o Claude Code e o Cursor, esse custo despencou. Em vez de gastar uma hora montando mocks e dados de exemplo, nós descrevemos o comportamento esperado e o agente escreve, roda e ajusta os testes até a suíte passar. O trabalho humano passa a ser outro: decidir o que merece teste e revisar se cada teste prova mesmo alguma coisa.

A seguir está o fluxo completo que usamos na Marfin: como configurar o Claude Code para testar por conta própria, como fazer o mesmo no Cursor, como montar testes end-to-end com Playwright, como testar as regras de segurança do Supabase e quais erros a IA comete quando escreve testes. Se você ainda está escolhendo ferramenta, vale passar antes pelo nosso comparativo das melhores IDEs com IA em 2026.

Link para esta seçãoO que são testes automatizados com IA

Teste automatizado é código que verifica outro código. Você escreve uma função que calcula o frete e escreve outra que chama essa função com valores conhecidos e confere se o resultado bate com o esperado. Quando alguém mexe no cálculo do frete meses depois, o teste roda sozinho e avisa se algo mudou. Testes automatizados com IA seguem a mesma lógica, com uma diferença prática: quem escreve, executa e conserta boa parte desses testes é um agente de IA, e o desenvolvedor atua como revisor e dono dos critérios.

Isso muda a economia do processo. Antes, um projeto pequeno raramente tinha testes porque o custo de escrever cada um deles pesava mais do que o benefício percebido. Hoje, pedir uma suíte para um módulo inteiro leva poucos minutos de conversa com o agente. O gargalo sai da digitação e vai para o julgamento: saber quais comportamentos precisam de proteção e perceber quando um teste gerado está verificando a coisa errada.

Link para esta seçãoOs três tipos de teste que usamos

Testes unitários verificam uma peça isolada, como uma função de formatação de CPF ou o cálculo de desconto de um cupom. São rápidos, rodam em milissegundos e são o tipo de teste que a IA escreve melhor, porque o contexto necessário cabe inteiro em um arquivo. Em projetos JavaScript e TypeScript nós usamos o Vitest, que aceita a sintaxe do Jest e roda bem mais rápido em projetos com Vite. Em Python, o pytest resolve.

Testes de integração verificam se as peças conversam direito. O exemplo clássico é a rota de API que recebe um pedido, grava no banco e dispara um email. O teste de integração sobe um banco de teste, chama a rota e confere se o registro apareceu com os campos certos. Aqui a IA precisa de mais contexto, porque o teste depende de configuração de ambiente, variáveis e dados iniciais.

Testes end-to-end, ou E2E, simulam um usuário de verdade no navegador. Abrem a página, clicam no botão de cadastro, preenchem o formulário e conferem se a tela de boas-vindas apareceu. São os mais lentos e os mais frágeis, mas também os que pegam os bugs que o usuário realmente vê. A ferramenta padrão hoje é o Playwright, da Microsoft, que é gratuito e roda Chromium, Firefox e WebKit.

Link para esta seçãoOnde a IA entra no processo

A IA ajuda em quatro momentos. O primeiro é escrever testes para código que já existe, o caso mais comum em projetos que nasceram sem teste nenhum. O segundo é escrever o teste antes do código, no estilo TDD, para servir de especificação para o próprio agente. O terceiro é rodar a suíte, ler o erro e corrigir o código até tudo passar, um ciclo que os agentes fazem sozinhos. O quarto é diagnosticar teste instável, aquele que passa numa execução e falha na outra, um trabalho chato que o agente faz com mais paciência do que qualquer pessoa.

Link para esta seçãoVibe coding sem teste é dívida acumulando juros

Quem cria apps descrevendo o que quer em linguagem natural, o famoso vibe coding, costuma pular a etapa de testes porque o app parece funcionar. Você abre, clica, está tudo lá. O problema aparece na décima iteração, quando o agente reescreve um componente para adicionar uma funcionalidade nova e, de quebra, muda o comportamento de outro que você nem pediu para tocar.

Isso acontece porque o agente trabalha com o contexto que tem naquele momento. Se ele desconhece que a função de cálculo de preço também é usada na tela de checkout, pode alterar a assinatura dela sem atualizar o outro lugar. Um humano cometeria o mesmo erro. A diferença é que o agente faz dez mudanças desse tipo por hora, então a chance de regressão cresce na mesma velocidade da produtividade.

A suíte de testes funciona como a memória do projeto. Ela registra o que o app precisa continuar fazendo, e qualquer mudança que quebre esse contrato aparece em vermelho na hora. Para o agente, isso vale ouro: com testes, o Claude Code consegue verificar o próprio trabalho antes de dizer que terminou. Sem testes, ele depende de você abrir o navegador e conferir tudo na mão.

Nós tratamos testes como a rede de proteção que permite acelerar. Com a suíte cobrindo login, pagamento e as regras de acesso ao banco, dá para pedir mudanças grandes ao agente com tranquilidade, porque se algo quebrar nós ficamos sabendo em segundos.

Link para esta seçãoTestes automatizados com IA no Claude Code

O Claude Code é a ferramenta que mais usamos na Marfin, e é nele que o fluxo de testes rende mais. Ele roda no terminal, lê o projeto inteiro, executa comandos e reage à saída deles. Na prática, ele escreve o teste, roda npm test, lê a falha e corrige, tudo na mesma tarefa. Com o Opus 4.8, lançado em 28 de maio de 2026, esse ciclo ficou mais confiável: a Anthropic divulgou quatro vezes menos erros não reportados, o que significa menos casos em que o agente diz que a suíte passou quando ela falhou. Se você está começando com a ferramenta, nosso tutorial do Claude Code cobre instalação e primeiros comandos.

Link para esta seçãoConfigure o CLAUDE.md com os comandos de teste

O primeiro passo é contar ao agente como os testes funcionam no seu projeto. O arquivo CLAUDE.md, na raiz do repositório, é lido no início de toda sessão. Nós sempre incluímos ali o comando para rodar a suíte inteira, o comando para rodar um arquivo só, onde ficam os testes e as regras da casa. Um trecho típico fica assim:

## Testes

Framework: Vitest (unitário e integração) e Playwright (E2E).
Rodar tudo: npm test
Rodar um arquivo: npx vitest run src/lib/frete.test.ts
Rodar E2E: npx playwright test
Testes ficam ao lado do arquivo testado, com sufixo .test.ts.
Nunca altere um teste existente para fazê-lo passar sem pedir confirmação.
Toda correção de bug começa com um teste que reproduz o bug.

A regra sobre alterar testes existentes é a que mais evita dor de cabeça. Sem ela, um agente pressionado a entregar a suíte verde pode ajustar a asserção em vez de corrigir o código, e você termina com um teste que passa e um bug que continua lá. A última linha cria um hábito que vale para o projeto inteiro: cada bug encontrado vira um teste, e aquele bug específico fica impedido de voltar.

Link para esta seçãoO fluxo de TDD com IA que usamos

TDD com IA é o jeito mais seguro que encontramos de pedir funcionalidades novas. Em vez de pedir "crie a função de cupom de desconto", pedimos primeiro os testes: "escreva os testes para uma função que aplica cupom de desconto, cobrindo cupom expirado, cupom com valor mínimo e cupom percentual acima de 100%. Rode os testes e confirme que eles falham". Só depois de ver a falha pedimos a implementação.

Confirmar que o teste falha antes do código existir parece burocracia, mas é o que prova que o teste verifica alguma coisa. Um teste que passa sem implementação está testando o vazio. Com o teste vermelho na tela, pedimos ao Claude Code para implementar a função até a suíte ficar verde, sem mexer nos arquivos de teste. Ele implementa, roda, lê o erro, ajusta e repete, geralmente em duas ou três voltas.

import { describe, it, expect } from 'vitest'
import { aplicarCupom } from './cupom'

describe('aplicarCupom', () => {
  it('recusa cupom expirado', () => {
    const cupom = { codigo: 'VERAO', percentual: 10, validoAte: new Date('2026-01-01') }
    expect(() => aplicarCupom(200, cupom, new Date('2026-09-01'))).toThrow('Cupom expirado')
  })

  it('limita o desconto ao valor do pedido', () => {
    const cupom = { codigo: 'TUDO', percentual: 150, validoAte: new Date('2027-01-01') }
    expect(aplicarCupom(200, cupom, new Date('2026-09-01'))).toBe(0)
  })
})

Repare que o teste recebe a data atual como parâmetro. É um detalhe que pedimos explicitamente, porque teste que depende do relógio do sistema quebra sozinho no dia em que o cupom de exemplo vence, e ninguém entende por que a suíte ficou vermelha sem mudança no código.

Para tarefas maiores, vale ativar o plan mode antes de qualquer edição (Shift+Tab duas vezes no terminal). O agente descreve quais testes pretende escrever e em que ordem, e você corrige o plano antes de ele gastar tokens. Com o effort control do Opus 4.8, dá para subir o esforço de raciocínio nessas tarefas de planejamento e baixar nas tarefas mecânicas, como gerar testes para funções utilitárias simples.

Link para esta seçãoHooks para rodar os testes a cada edição

O recurso que transformou nosso uso de testes no Claude Code foi o sistema de hooks. Um hook é um comando que o Claude Code executa automaticamente em momentos definidos, como depois de editar um arquivo. Com um hook que roda os testes relacionados após cada edição, o agente recebe o resultado sem precisar lembrar de rodar nada.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx vitest run --changed 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Esse trecho vai no arquivo .claude/settings.json do projeto. O --changed faz o Vitest rodar só os testes ligados aos arquivos alterados, o que mantém o ciclo rápido. O final do comando garante que a saída chegue ao modelo: quando um hook termina com código 2, o Claude Code devolve a mensagem de erro para o agente, que corrige antes de seguir para o próximo passo.

Uma alternativa mais leve é o hook Stop, que dispara quando o agente considera a tarefa concluída. Rodando a suíte completa ali, com a mesma saída em código 2 na falha, ele só consegue encerrar com tudo verde. Em projetos grandes, rodar a suíte inteira a cada edição deixa o agente lento, então nós combinamos os dois: testes relacionados a cada edição e suíte completa no final.

Link para esta seçãoSubagentes dedicados a testes

O Claude Code permite criar subagentes, cada um com instruções e ferramentas próprias, em arquivos dentro de .claude/agents/. Nós mantemos um subagente só para testes, com a missão de escrever casos de borda e desconfiar do código que recebe. O agente principal implementa a funcionalidade e delega a escrita dos testes para ele. Isso traz um olhar separado, o mesmo princípio de ter um QA diferente do dev: quem testa trabalha com um contexto limpo, sem as suposições que o agente principal acumulou durante a implementação.

Link para esta seçãoTestes no Cursor: rules e Agent mode

O Cursor é a IDE que usamos para building no dia a dia, e para testes ele se destaca num ponto específico: a visão lado a lado. Você vê o arquivo de código, o arquivo de teste e o terminal na mesma janela, e o Agent mode trabalha nos três. Para quem prefere acompanhar cada mudança visualmente, é o ambiente mais confortável. O passo a passo de instalação e configuração está no nosso tutorial do Cursor AI.

Link para esta seçãoRules de teste no Cursor

O equivalente ao CLAUDE.md no Cursor são as Rules, arquivos .mdc dentro da pasta .cursor/rules. Nós criamos uma rule chamada testes.mdc com as mesmas instruções: framework, comandos, convenção de nomes e a proibição de alterar testes existentes sem avisar. Dá para configurar a rule para ser anexada automaticamente sempre que um arquivo .test.ts entrar no contexto, usando o campo de globs no cabeçalho do arquivo.

Também deixamos um AGENTS.md na raiz com o básico, porque o Cursor e várias outras ferramentas leem esse formato. Assim a regra de testes vale para qualquer agente que abrir o projeto, inclusive quando alguém do time usa uma ferramenta diferente da nossa.

Link para esta seçãoO ciclo de correção no Agent mode

Com as rules no lugar, o fluxo no Cursor é parecido com o do Claude Code. Selecionamos o arquivo que precisa de testes, abrimos o chat no Agent mode e pedimos a suíte cobrindo casos específicos. O agente cria o arquivo, roda o comando no terminal integrado, lê a saída e corrige. Para evitar aprovar cada execução, liberamos os comandos de teste na allowlist de execução automática e mantemos a confirmação manual para comandos destrutivos.

Um recurso que usamos bastante é selecionar o erro direto no terminal e mandar para o chat. O stack trace vai com contexto completo, e o agente costuma achar a causa na primeira tentativa. Para testes instáveis, pedimos que ele rode o mesmo teste dez vezes seguidas e analise em quais execuções falhou, o que geralmente revela uma condição de corrida ou uma dependência de ordem entre testes.

O Cursor também tem o Bugbot, que revisa pull requests no GitHub e aponta bugs prováveis antes do merge. Ele complementa a suíte sem substituí-la: o Bugbot lê o diff e levanta suspeitas, enquanto os testes executam o código e dão a resposta definitiva.

Link para esta seçãoTestes end-to-end com Playwright e IA

Testes E2E são onde a IA economiza mais tempo, porque escrever seletores e esperas no Playwright na mão é tedioso. O caminho que usamos é conectar o agente ao navegador via MCP. O Playwright MCP, mantido pela Microsoft, dá ao Claude Code e ao Cursor a capacidade de abrir páginas, clicar, preencher campos e ler o que aparece na tela.

No Claude Code, a instalação é um comando: claude mcp add playwright npx @playwright/mcp@latest. No Cursor, o servidor entra no arquivo de configuração de MCP pelas configurações da IDE. Com isso ligado, pedimos coisas como "abra localhost:3000, crie uma conta nova com um email de teste, confirme que a tela de onboarding aparece e depois transforme esse fluxo em um teste Playwright em tests/e2e/cadastro.spec.ts".

O agente navega de verdade, descobre os seletores olhando a página e escreve o teste com base no que viu. Isso resolve o problema clássico dos testes E2E gerados às cegas, em que a IA inventa um data-testid que nunca existiu no HTML. Depois de gerado, rodamos npx playwright test para confirmar que o teste passa sozinho, sem o agente no meio.

Link para esta seçãoSeletores que sobrevivem a mudanças

Uma instrução que sempre incluímos: priorizar seletores por papel e texto, como getByRole('button', { name: 'Criar conta' }), em vez de classes CSS. Quando o agente redesenha a interface numa iteração futura, as classes mudam e os testes baseados nelas quebram sem motivo. Seletores por papel acompanham o que o usuário vê e sobrevivem a refatorações visuais. De quebra, isso força a interface a ter uma acessibilidade mínima, porque o teste só encontra botões que têm nome acessível.

Link para esta seçãoTraces para diagnosticar falhas

O Playwright grava traces com screenshots, rede e console de cada passo. Quando um teste E2E falha, abrimos o trace com npx playwright show-trace para entender o que aconteceu e, em casos mais cabeludos, entregamos o arquivo ao agente pedindo o diagnóstico. Na maioria das vezes, a causa é uma espera mal feita: o teste clicou antes de a página terminar de carregar os dados.

Link para esta seçãoTestando o backend: Supabase, RLS e rotas de API

Boa parte dos apps que criamos com IA usa Supabase como backend, e é ali que mora o bug mais perigoso: a regra de acesso errada. Uma política de Row Level Security mal escrita deixa um usuário ler os dados de outro, e nada na interface denuncia isso. O app funciona normalmente para quem usa, enquanto os dados ficam expostos para quem sabe consultar a API direto.

Para esse cenário, pedimos ao agente testes de integração que se passam por usuários diferentes. O teste cria dois usuários no Supabase local (via Supabase CLI, com supabase start), faz login como o primeiro, grava um registro, faz login como o segundo e tenta ler o registro do primeiro. O teste só passa se a leitura voltar vazia. Parece exagero até o dia em que esse teste pega uma política que alguém afrouxou para "resolver" um erro de permissão.

O Supabase também oferece suporte ao pgTAP, framework de testes que roda dentro do próprio PostgreSQL, e o comando supabase test db executa esses testes. Para quem tem afinidade com SQL, pedir ao Claude Code testes pgTAP para cada política de RLS é o jeito mais direto de blindar o banco. Nosso tutorial de Supabase mostra como montar o ambiente local que esses testes usam.

Nas rotas de API, a lógica é a mesma. Pedimos testes que cobrem o caminho feliz e, principalmente, os caminhos tristes: requisição sem token, token de outro usuário, corpo malformado, campo obrigatório vazio. A IA tende a testar só o caso que funciona se você deixar, então listar os casos de erro no pedido faz diferença.

Link para esta seçãoClaude Code vs Cursor vs Copilot para testes

As três ferramentas escrevem testes, mas cada uma se encaixa num momento diferente do trabalho. A tabela resume como nós usamos cada uma.

Nosso fluxo combina as duas primeiras. O Claude Code assume as tarefas grandes, como cobrir de testes um módulo legado inteiro ou implementar uma funcionalidade com TDD do começo ao fim. O Cursor fica com os ajustes do dia a dia, quando estamos com o código aberto e queremos acrescentar um caso de teste ou entender uma falha. O Copilot continua com o melhor autocomplete, e para quem escreve testes na mão ele adianta bastante as asserções repetitivas.

Windsurf e Devin também entram na conversa. O Windsurf, hoje da Cognition, tem o Cascade, que roda testes e corrige de forma parecida com o Agent mode do Cursor. O Devin trabalha de forma assíncrona e serve para delegar tarefas como "aumente a cobertura do módulo de pagamentos para 80%" e revisar o pull request depois. Para quem começou o app em plataformas visuais como Lovable ou Bolt.new, o caminho é sincronizar o projeto com o GitHub e rodar os testes a partir do Claude Code ou do Cursor, já que essas plataformas focam em gerar interface e integração com o banco.

Link para esta seçãoOs erros mais comuns quando a IA escreve testes

Testes gerados por IA têm defeitos recorrentes. Conhecer cada um deles acelera a revisão, porque quase todo problema cai em uma destas categorias.

Link para esta seçãoTestes que testam o mock

Para isolar a função, o agente mocka tudo em volta dela, inclusive a parte que deveria ser testada. O resultado é um teste que confere se o mock devolve o que o mock foi programado para devolver. Sempre que vemos um teste com mais linhas de mock do que de asserção, pedimos ao agente que justifique cada mock ou transforme o teste em integração.

Link para esta seçãoTestes alterados para passar

Esse é o mais traiçoeiro. Diante de uma falha, o agente conclui que o teste está errado e ajusta o valor esperado. Às vezes o teste estava errado mesmo. Na maioria das vezes, o bug estava no código. Por isso a regra no CLAUDE.md e nas rules do Cursor, e por isso revisamos com atenção todo diff que mexe em arquivo de teste. Um git diff filtrado pelos arquivos de teste é o primeiro comando que rodamos ao revisar uma tarefa entregue pelo agente.

Link para esta seçãoAsserções fracas

Um expect(resultado).toBeDefined() passa para quase qualquer coisa. A IA recorre a esse tipo de asserção quando está incerta sobre o que esperar, e o teste vira enfeite. Pedimos sempre valores exatos: o total do pedido deve ser 180, a lista deve ter três itens, a mensagem de erro deve ser esta. Uma técnica que ajuda é a mutação manual: mudamos uma linha do código de propósito e vemos se algum teste quebra. Se nenhum quebrar, os testes daquele trecho estão fracos. Para automatizar essa checagem em JavaScript e TypeScript existe o Stryker, ferramenta de mutation testing que faz essas alterações em massa.

Link para esta seçãoTestes que dependem de tempo, rede ou ordem

Teste que chama a API real de pagamento, lê o relógio do sistema ou depende de outro teste ter rodado antes vai falhar de forma aleatória. Pedimos ao agente para usar timers falsos (vi.useFakeTimers() no Vitest), interceptar requisições de rede e garantir que cada teste monte e desmonte os próprios dados.

Link para esta seçãoAPIs inventadas

Com menos frequência nos modelos atuais, ainda acontece de o agente chamar um método de biblioteca que nunca existiu ou que mudou de nome numa versão recente. Como o teste roda, o erro aparece na hora, o que é mais uma vantagem de deixar o agente executar em vez de só escrever. Para bibliotecas que mudam rápido, conectar um servidor MCP de documentação atualizada reduz bastante esse problema.

Link para esta seçãoRodando os testes a cada push com GitHub Actions

Testes que só rodam quando alguém lembra acabam parando de rodar. O último passo do fluxo é colocar a suíte no CI, para que todo push e todo pull request passem pelos testes automaticamente. Com GitHub Actions, isso é um arquivo YAML na pasta .github/workflows, e pedir ao Claude Code para criá-lo leva um minuto: descrevemos a versão do Node, o gerenciador de pacotes, os comandos de teste e se o Playwright precisa instalar navegadores.

Duas configurações fazem diferença. A primeira é bloquear o merge quando os testes falham, nas regras de proteção da branch principal. A segunda é guardar o relatório do Playwright como artefato, com vídeos e traces das falhas, para análise posterior. Quando um teste E2E falha no CI, baixamos o trace, passamos para o Claude Code e pedimos o diagnóstico junto com a correção.

Link para esta seçãoPreços e planos

Os frameworks de teste são gratuitos e de código aberto: Vitest, Jest, Playwright, pytest e pgTAP custam zero. O gasto está nas ferramentas de IA que escrevem e mantêm os testes.

Na nossa experiência, o plano Pro do Claude dá conta de um projeto pequeno. Quem roda o agente o dia inteiro, com suítes grandes e muitas iterações, costuma precisar do Max. O GitHub Actions tem cota gratuita de minutos para repositórios privados e é ilimitado em repositórios públicos, o que cobre a maioria dos projetos no começo. Preços em dólar mudam com frequência, então confira a página de cada ferramenta antes de assinar.

Link para esta seção8 dicas para testes automatizados com IA

1. Comece pelos fluxos que dão prejuízo. Login, pagamento, permissões e qualquer coisa que envolva dinheiro ou dados de clientes. Cobertura de 100% em funções de formatação vale menos do que um teste bem feito no checkout.

2. Peça os casos de erro explicitamente. A IA testa o caminho feliz por padrão. Liste no pedido as entradas inválidas, os usuários sem permissão e os limites numéricos que você quer cobertos.

3. Veja o teste falhar antes de confiar nele. Rode o teste contra o código sem a implementação ou com um bug proposital. Se ele continuar verde, a asserção está fraca e precisa ser refeita.

4. Proíba a edição silenciosa de testes. Coloque a regra no CLAUDE.md e nas rules do Cursor. Todo diff em arquivo de teste merece revisão humana antes do merge.

5. Automatize a execução com hooks. No Claude Code, um hook depois de cada edição faz o agente corrigir as regressões enquanto trabalha, sem depender de você lembrar de pedir.

6. Use seletores por papel nos testes E2E. Os métodos getByRole e getByLabel sobrevivem às mudanças de layout que o próprio agente vai fazer nas próximas iterações.

7. Teste as políticas de RLS com usuários diferentes. Esse teste é o que mais evita vazamento de dados em apps feitos com Supabase, e o agente escreve em poucos minutos.

8. Coloque tudo no CI desde o primeiro dia. Uma suíte pequena rodando a cada push vale mais do que uma suíte grande que ninguém executa. Bloqueie o merge quando algo falhar.

Testes automatizados com IA mudaram a conta que fazia todo mundo pular essa etapa. Escrever a suíte ficou barato, e o que sobra para o time humano é a parte que sempre exigiu mais cabeça: decidir o que proteger e desconfiar de teste que passa fácil demais. Na Marfin, funcionalidade nova só entra com pelo menos um teste escrito antes do código, e o Claude Code roda essa suíte dezenas de vezes por dia sem ninguém pedir.

Se o seu app nasceu sem teste nenhum, o melhor ponto de partida é pequeno. Abra o Claude Code ou o Cursor, peça testes para o fluxo de login e para a função que mexe com dinheiro, confirme que eles falham quando você quebra o código de propósito e coloque os dois no CI. A partir daí, cada bug encontrado vira um teste novo, e a suíte cresce junto com o produto.

Leia também:

• Melhores IDEs com IA em 2026
• Claude Code: tutorial completo em português
• Cursor AI: como criar um app do zero
• Agentes de IA para programação
• Supabase: tutorial completo
• GitHub Copilot: tutorial completo
• Windsurf: tutorial completo
• Devin AI: tutorial completo
• Replit vs Cursor vs Windsurf: qual o melhor IDE com IA
• O que é vibe coding