💡 Regra de ouro deste módulo
Não existe "melhor plataforma". Existe plataforma forte em X e plataforma fraca em Y. Se durante a leitura você pensar "então X é o melhor", reescreva a frase: "X é o mais forte em [tarefa específica]". É a disciplina que o resto da Trilha 4 vai exigir.
📊 Contexto rápido
Em 2026, as três plataformas ocupam categorias diferentes (como o módulo 4.1 deixou explícito): Claude Code e Antigravity são IDE-agents com ênfases distintas, DeerFlow é harness genérico. Ler os três posicionamentos abaixo como se fossem do mesmo tipo de ferramenta é o atalho mais comum para concluir errado.
💻 Claude Code — o par de programação
Claude Code é o CLI/IDE-agent da Anthropic focado em engenharia de software. A descrição em uma frase é literal: foi desenhado para sentar ao lado do desenvolvedor, no terminal ou no plugin do editor, e participar do loop de código. Single-vendor em modelos (só Claude), skills oficiais, MCP como extensão, sandbox apoiado no host do desenvolvedor, fluxo git-aware.
🎯 Conceito Central
Claude Code é forte em code tasks com acesso ao working tree: ler um repositório inteiro, sugerir edições, rodar testes, abrir PRs. O loop de trabalho do dev é o centro de gravidade — tudo gira em torno do terminal e do git.
- •CLI-first — terminal, não web; integra com IDE via plugin
- •Anthropic-only — você depende do roadmap de modelos da Anthropic
- •Skills oficiais — catálogo curado, boa trigger accuracy
- •MCP — integração padrão com serviços externos
- •Sandbox no host — sem container por padrão; cabe ao dev
💡 Onde é fraco
Claude Code é fraco fora de código. Tarefas que envolvem mídia (PPT, podcast, vídeo), integração com canais IM, fluxos multi-step não-de-código, ou que exigem multi-modelo — não são o centro de gravidade dele. Usar Claude Code para "gerar uma apresentação pro cliente" funciona, mas é nadar contra a corrente.
🪐 Antigravity — a IDE pensada em agentes
Antigravity é o IDE-agent recente do Google. Diferente de Claude Code (que é um agente dentro do editor), Antigravity foi desenhado desde o início como uma IDE agêntica: multi-agente nativo, Gemini no núcleo, integração profunda com o workspace Google. Em 2026 ainda é a plataforma mais nova das três — o que significa mais UX emergente, mas também menos comunidade.
🎯 Conceito Central
Antigravity é forte em autonomia dentro do editor e em orquestração multi-agente nativa. É a aposta mais recente de "IDE pensada em agentes desde o primeiro commit". O que você ganha é UX inovadora; o que você paga é catálogo menor e menor maturidade de extensões.
- •IDE agêntica nativa — o editor foi redesenhado ao redor do agente
- •Multi-agente — suporte a vários agentes cooperando no editor
- •Gemini-centric — otimizada para o ecossistema Google
- •Workspace Google — integração com Drive, Docs, etc.
⚠️ Cuidado com o efeito "uau"
Como Antigravity é a mais nova, a primeira demo dela tende a parecer a mais impressionante. O curso trata esse efeito explicitamente no módulo 4.3: descontar novidade antes de concluir. Uma feature nova que outras plataformas ainda não têm é um ponto real, mas "ter UX mais fresca" não é um eixo.
🦌 DeerFlow 2.0 — o harness que você hospeda e estende
DeerFlow 2.0 não é um IDE-agent. É um harness open-source, multi-model e multi-channel, desenhado para você hospedar e estender. Skills cobrem domínios muito além de código — research, podcast, PPT, video, análise, consultoria. Sandbox configurável até K8s, memória de longo prazo como primeira classe, canais IM (Telegram, Slack, Feishu, WeChat, WeCom).
🎯 Conceito Central
DeerFlow é forte quando a tarefa não cabe no editor. Research profundo, geração de mídia, fluxos long-running com memória, integração com canais IM, multi-skill encadeado. E é o único dos três que você hospeda inteiro — o que significa controle de dados, de custo e de roadmap.
- •Open-source — você lê, modifica, contribui
- •Multi-model — OpenAI, Anthropic, OpenRouter, vLLM local
- •Multi-channel — web, API, Telegram, Slack, Feishu, etc.
- •Skills além de código — deep-research, ppt, podcast, data-analysis
- •Long-term memory — primeira classe, auditável
- •Sandbox até K8s — suporta multi-tenant
💡 Onde é fraco
DeerFlow é mais fraco em code tasks curtas dentro do editor. Se você quer apenas "renomeia essa variável em 30 arquivos", um IDE-agent vence em fricção e velocidade. DeerFlow compensa em tarefas longas e multi-domínio, não em edit-loop rápido.
🎬 Por que demonstração ao vivo bate lista de features
O resto da Trilha 4 vai rodar a mesma tarefa nas três plataformas. Não vai listar features num slide. A razão é prática: feature list envelhece em uma semana e premia quem tem equipe de marketing maior. Demo ao vivo premia o que funciona hoje, na sua máquina, para a sua tarefa.
💡 Princípio didático
Demo-first, rubrica fixa (tempo, qualidade, fricção, custo), observação com caderno aberto. Se não deu pra rodar na sua máquina, não conta. Se a rubrica não está preenchida, é impressão — não conclusão.
📊 Por que listas de features mentem
- Feature existe ≠ feature funciona: "suporta MCP" pode significar "em 2 servidores e com bugs" ou "padrão oficial com 50 servidores"
- Feature existe ≠ feature é acionada: skill no catálogo que o agente nunca dispara é um item de marketing, não de capacidade
- Feature existe ≠ feature cabe no seu fluxo: "gera PPT" é verdade, mas se o PPT sai no formato errado, não conta
- Feature aparece na página ≠ feature é estável: beta de 2 semanas e GA de 1 ano ocupam o mesmo bullet
✓ FAZER
- ✓Rodar a mesma tarefa exata nas três
- ✓Cronometrar tempo total até o entregável
- ✓Anotar fricção (erros, re-prompts, UX ruim)
- ✓Calcular custo real em tokens / dinheiro
- ✓Retestar daqui a 30 dias para descontar novidade
✗ NÃO fazer
- ✗Comparar pela feature list do site oficial
- ✗Assumir que "a mais nova" é "a melhor"
- ✗Rodar tarefas diferentes em cada plataforma
- ✗Ignorar custo porque "ainda tá de graça"
- ✗Confundir "onboarding ruim" com "ferramenta ruim"
🧪 Lab: "diga oi" nas 3 plataformas
Lab-relâmpago. Objetivo: calibrar a primeira impressão antes dos labs pesados dos módulos 4.3 e 4.4. Sem isso, o aluno tende a confundir "onboarding ruim" com "ferramenta ruim" quando as tarefas reais começarem.
🎯 Passos do lab (≈15 min)
- Prepare o caderno com três colunas: tempo-para-primeira-resposta, tom da resposta, fricção percebida.
- Claude Code: abra o terminal, rode o CLI (ou abra o plugin no editor), digite exatamente
oi, o que você consegue fazer?. Anote. - Antigravity: abra a IDE agêntica, inicie uma sessão nova, mande o mesmo prompt. Anote.
- DeerFlow 2.0: abra o frontend web local (do módulo 1.2), sem plan mode, mande o mesmo prompt. Anote.
- Compare as três linhas e escreva uma frase por plataforma: "Primeira impressão: …". Guarde esta nota — ela vira baseline para os módulos 4.3 e 4.4.
📊 O que observar sem julgar
- Tempo até 1º token: não é qualidade, é fricção de entrada
- Tom da resposta: formal, casual, técnico, resumido
- Prompts de permissão: quantas vezes a plataforma pede confirmação
- Erros de bootstrap: falha de auth, provider não configurado, UI quebrada
- "Feeling" geral: uma palavra só — rápida, travada, polida, promissora
💡 Dica prática
O objetivo deste lab não é decidir qual plataforma é melhor. É reconhecer que as três têm personalidades diferentes e que isso é legítimo. Se alguma travar na instalação, documente o ponto onde travou — virou insumo para o módulo 4.3 sobre "fricção".
✓ O que o lab quer
- ✓Baseline calibrado das 3 plataformas
- ✓Uma frase honesta por plataforma
- ✓Notas específicas sobre fricção de setup
- ✓15 minutos de atenção, não mais
✗ O que o lab NÃO quer
- ✗Conclusão sobre "qual é a melhor"
- ✗Teste de capacidade (fica pros módulos 4.3 e 4.4)
- ✗Comparação direta dos outputs verbais
- ✗Prompts extras para "dar chance" para alguma
📝 Resumo do Módulo
Próximo Módulo:
4.3 — 🧪 Labs comparativos 1 e 2
Tarefa de código (refatorar + PR) e tarefa de research (relatório com 10 fontes). Rubrica de tempo, qualidade, fricção, custo.