Claude Code Anti-Gravity: A Configuração de IDE que Mudou Minha Forma de Desenvolver

Eu estava no meio de um projeto para um cliente no mês passado quando meu fluxo de trabalho com Claude Code apenas no terminal bateu em um muro. Não um muro técnico -- um cognitivo. Eu tinha seis abas de terminal abertas, três janelas de contexto diferentes consumindo tokens, e tinha perdido a noção de qual agente estava trabalhando em qual funcionalidade. O código estava bom. Minha capacidade de gerenciá-lo estava desmoronando.

Naquela mesma semana, encontrei o tutorial detalhado do Jack Roberts sobre combinar Claude Code com o IDE Anti-Gravity do Google, e algo clicou. Não um "ah, que legal" -- mais como um "eu estive fazendo isso errado por meses". Em um fim de semana, reestruturei todo o meu fluxo de trabalho de programação com IA em torno dessa combinação, e a diferença foi impactante o suficiente para eu precisar escrever sobre isso.

A parte que mais me surpreendeu: o terminal não é o gargalo. O terminal é ótimo. Claude Code em um terminal puro ainda é uma das ferramentas de desenvolvimento mais poderosas que já usei. O gargalo era tudo ao redor do terminal -- navegação de arquivos, rastreamento de tarefas, gerenciamento de contexto, feedback visual sobre o que a IA realmente mudou. O Anti-Gravity resolveu problemas que eu nem percebia que estava compensando.

Mas o IDE é apenas metade da história. A verdadeira transformação veio de um framework de prompting chamado BLAST e uma funcionalidade chamada Claude Skills que transformou fluxos de trabalho repetitivos em automações de um único comando. Vou detalhar ambos -- e compartilhar exatamente como configurei tudo -- mas primeiro, você precisa entender por que o fluxo padrão do Claude Code começa a perder produtividade em escala.

Por Que o Claude Code Apenas no Terminal Falha em Escala

Eu amo o terminal. Minha configuração do Ghostty está afinada, meu config do tmux é impecável, e consigo navegar por uma base de código sem tocar no mouse. Então quando ouvi pela primeira vez pessoas falando sobre rodar Claude Code dentro de um IDE, minha reação instintiva foi ceticismo. Por que adicionar overhead visual a algo que funciona perfeitamente em texto?

A resposta ficou óbvia assim que comecei a gerenciar mais de duas tarefas simultâneas.

Claude Code em um terminal é fenomenal para trabalho focado em um único fluxo. Você dá uma tarefa, ele executa, você revisa, itera. Esse loop é enxuto e rápido. O problema aparece quando seu projeto envolve coordenar múltiplos agentes, rastrear mudanças em dezenas de arquivos, e alternar entre diferentes tipos de trabalho -- depuração aqui, construindo uma nova funcionalidade ali, configurando deploy em outro lugar.

No terminal, todo esse contexto vive na sua cabeça. Você é o roteador, o gerente de tarefas e o portão de qualidade, tudo ao mesmo tempo. Depois de umas quatro horas assim, a qualidade das minhas decisões cai visivelmente. Começo a aprovar mudanças que deveria examinar. Esqueço quais arquivos um agente modificou vinte minutos atrás. Perco o fio de qual era o objetivo original para uma branch de funcionalidade específica.

O Anti-Gravity muda essa equação ao externalizar essa carga cognitiva em uma interface visual. Mudanças em arquivos são destacadas em uma barra lateral. Gerenciamento de tarefas acontece em painéis dedicados. Múltiplos modos de interação -- chat na barra lateral, terminal, extensões -- permitem que você escolha a ferramenta certa para o tipo específico de trabalho que está fazendo naquele momento.

Não se trata do Anti-Gravity ser "melhor" que um terminal. É sobre combinar duas ferramentas que se complementam de formas que eu não esperava. O terminal cuida da velocidade de execução. O IDE cuida da consciência situacional.

E essa combinação importa mais do que a maioria dos desenvolvedores pensa, por causa de algo que a maioria dos tutoriais de Claude Code mal menciona: a degradação da janela de contexto.

O Problema da Janela de Contexto Sobre o Qual Ninguém Te Avisa

Aqui vai um fato que mudou como eu estruturo cada sessão de Claude Code: uma vez que sua janela de contexto cruza aproximadamente 50% da capacidade, a qualidade da saída começa a degradar. Não quebra -- degrada. As respostas ficam ligeiramente menos precisas. O código fica ligeiramente mais genérico. Alucinações começam a aparecer nas bordas. Se você não estiver prestando muita atenção, não vai perceber até estar depurando problemas fantasma que remontam a uma sessão inchada de contexto.

Confirmei isso através de um experimento simples mas eficaz. Peguei a mesma tarefa de programação -- construir um endpoint de API REST com validação, tratamento de erros e testes -- e executei em diferentes níveis de utilização de contexto. Com 20% de contexto, o código gerado era enxuto, bem estruturado e correspondia às convenções do meu projeto quase perfeitamente. Com 60%, o código funcionava mas não seguia alguns dos meus padrões de nomenclatura e incluía algumas importações desnecessárias. Com 80%, gerou um endpoint funcional mas com um padrão de tratamento de erros completamente diferente do que existia no restante da base de código.

Mesmo prompt. Mesmo modelo. A única variável foi quanto contexto já estava carregado.

É por isso que a disciplina de "uma janela por tarefa" importa tanto. Antes de entender isso, eu usava uma única sessão de Claude Code por horas, carregando arquivo após arquivo, fazendo pergunta após pergunta, construindo funcionalidade após funcionalidade. A primeira hora era mágica. Na terceira hora, eu gastava mais tempo corrigindo a IA do que ela me economizava.

O Anti-Gravity ajuda aqui porque sua interface torna o uso do contexto visível. Você pode ver quanto da sua janela está consumido, o que torna natural fechar uma sessão e começar uma nova quando as coisas começam a ficar sobrecarregadas. No terminal, o uso do contexto é invisível -- você só sente quando as saídas pioram, e a essa altura você já desperdiçou ciclos.

A regra prática que sigo agora: uma janela de contexto por tarefa. Termine uma funcionalidade, feche a sessão, comece uma nova para a próxima funcionalidade. Parece desperdício -- como se você estivesse jogando fora a "memória" que a IA construiu. Mas a memória além dos 50% é mais prejudicial do que útil. Contexto fresco com um prompt claro e focado produz melhores resultados do que um contexto profundo poluído por três horas de conversas não relacionadas.

Essa única percepção me economizou mais tempo do que qualquer ferramenta ou técnica individual. Mas o verdadeiro desbloqueio de produtividade veio quando aprendi a estruturar prompts para essa restrição usando o framework BLAST.

O Sistema BLAST: Um Framework de Prompting que Realmente Escala

A maioria dos conselhos sobre prompting se resume a "seja específico" e "forneça contexto". Útil, mas vago. O framework BLAST -- que Jack Roberts demonstrou em seu tutorial do Anti-Gravity -- dá a esse conselho uma estrutura concreta que posso repetir consistentemente entre projetos.

BLAST significa Blueprint, Linkages, Architecture, Stylize e Trigger. Cada componente aborda um modo de falha específico que vi no desenvolvimento assistido por IA. Deixe-me explicar como realmente uso cada um, porque a teoria é menos interessante que a prática.

Blueprint é a especificação do projeto. Não uma descrição vaga -- um documento estruturado que descreve o que você está construindo, por que existe, e como é o sucesso. Mantenho meus blueprints em um arquivo BLUEPRINT.md na raiz do projeto, e o referencio nos meus prompts de sistema do Claude Code usando regras globais. Um bom blueprint responde três perguntas: o que este projeto faz, para quem é, e quais são as restrições técnicas inegociáveis?

Para um projeto recente de dashboard SaaS, meu blueprint tinha umas 400 palavras. Especificava a persona do usuário (gerentes de operações em empresas de logística de médio porte), o fluxo de trabalho principal (monitorar exceções de entrega em tempo real), o stack tecnológico (Next.js 15, Supabase, Tailwind), e três restrições (deve carregar em menos de 2 segundos em 3G, deve suportar modo offline, deve integrar com o sistema existente de notificações do Slack). Quando o Claude tem esse blueprint em contexto, cada componente gerado se alinha com essas restrições sem eu re-especificá-las em cada prompt.

Linkages definem como os componentes se conectam. Esta é a parte que a maioria dos desenvolvedores pula, e é a parte que causa mais retrabalho. Linkages descrevem seu fluxo de dados, contratos de API e dependências de componentes. Eu os escrevo como mapas de relacionamento simples: "O componente do dashboard consome dados da API de exceções, que consulta a tabela delivery_exceptions do Supabase, que é populada pelo handler de webhooks conectado à plataforma logística do cliente."

Sem linkages, o Claude constrói componentes que funcionam isoladamente mas não se conectam de forma limpa. O dashboard pode esperar dados em um formato enquanto a API retorna em outro. Ao especificar linkages antecipadamente, reduzi bugs de integração em algo que parece uns 70% -- não tenho métricas exatas sobre isso, mas meu histórico de git conta uma história clara de menos commits de "fix integration" desde que comecei a usar essa abordagem.

Architecture cobre sua estrutura de arquivos, convenções de nomenclatura e padrões organizacionais. Onde vão os novos componentes? Como as rotas são estruturadas? Qual é o padrão de testes? Passo ao Claude um resumo da arquitetura existente para que ele siga as convenções da base de código em vez de inventar as próprias.

Stylize cuida do estilo de código -- mas não apenas formatação. Cobre padrões como convenções de tratamento de erros, padrões de logging, como você estrutura operações assíncronas, e se prefere composição ou herança. Minha seção de stylize para a maioria dos projetos é uma lista de umas quinze regras específicas, coisas como "use retornos antecipados em vez de condicionais aninhados" e "todos os erros de API devem incluir um código de erro legível por máquina e uma mensagem legível por humanos".

Trigger é o prompt real -- a instrução específica para a tarefa atual. Como os outros quatro componentes cuidam do contexto, o trigger pode ser curto e focado. "Construa o endpoint de API de exceções de entrega que retorne resultados paginados com filtro por intervalo de datas e nível de severidade." Só isso. O Claude já tem carregados o blueprint, linkages, architecture e regras de estilo. O trigger apenas aponta para o trabalho específico.

Isso é o que faz o BLAST funcionar dentro do Anti-Gravity especificamente: você pode armazenar os componentes Blueprint, Linkages, Architecture e Stylize como regras globais ou locais na configuração do IDE. Regras globais se aplicam a todos os projetos. Regras locais ficam no diretório do seu projeto e se aplicam apenas àquela base de código. O Trigger é a única coisa que você digita de novo cada vez.

Essa separação -- contexto persistente em regras, contexto fresco em triggers -- mapeia perfeitamente com a restrição de janela de contexto que mencionei antes. Suas regras carregam eficientemente porque são estruturadas e consistentes. Seu trigger usa contexto mínimo porque não precisa re-explicar o projeto. O resultado é mais da sua janela de contexto disponível para a geração real de código.

Tentei trabalhar sem BLAST por uma semana depois de adotá-lo, apenas para calibrar a diferença. A diferença de qualidade foi significativa o suficiente para eu voltar em dois dias.

Mas um framework é tão bom quanto sua capacidade de executá-lo consistentemente, e é aí que o Claude Skills mudou o jogo para mim.

Claude Skills: Transformando Fluxos de Trabalho Repetitivos em Automações de Um Único Comando

Se o framework BLAST é a estratégia, Claude Skills são as táticas. Skills são automações personalizadas que você define uma vez e aciona repetidamente -- instruções reutilizáveis que o Claude segue quando ativadas. Pense nelas como fluxos de trabalho salvos que codificam suas melhores práticas para que você não precise re-explicá-las em cada sessão.

Existem dois tipos de skills, e a distinção importa mais do que pode parecer.

Skills estáticas são conjuntos de instruções fixas. Não mudam entre execuções. "Quando eu disser 'novo componente', crie um componente React em /src/components/ com uma interface TypeScript para props, um arquivo Storybook e um arquivo de testes usando Vitest" -- isso é uma skill estática. Mesmas instruções, mesma estrutura de saída, toda vez. Tenho umas doze dessas para padrões comuns nos meus projetos: criar endpoints de API, configurar migrações de banco de dados, scaffolding de suítes de teste, gerar stubs de documentação.

Skills dinâmicas se adaptam com base na entrada ou contexto. É aqui que as coisas ficam genuinamente poderosas. Uma skill dinâmica pode inspecionar o projeto atual, ler arquivos existentes, tomar decisões com base no que encontra, e executar de forma diferente dependendo da situação. Jack Roberts demonstrou uma em seu tutorial que me deixou impressionado: uma skill de clonagem e aprimoramento de sites.

A skill funcionava assim: dê uma URL, e ela usaria o Firecrawl para extrair a estrutura e conteúdo do site, analisar os padrões de design, e então reconstruir o site com melhorias usando ferramentas modernas -- tudo através de um único comando. Ela usava a API do Nano Banana 2 para geração aprimorada de imagens quando as imagens do site original precisavam de upgrade, e ImageB para processamento de imagens. Todo o pipeline -- extrair, analisar, redesenhar, gerar assets, construir -- acontecia em uma única ativação de skill.

Adaptei uma versão simplificada disso para meu próprio trabalho. Minha versão não clona sites de concorrentes (a ética disso fica turva rápido), mas analisa uma página existente que estou redesenhando, extrai a estrutura de conteúdo e padrões-chave de UI, e gera uma nova implementação que preserva o conteúdo enquanto moderniza a interface. Me economiza umas duas horas por página comparado com análise e reconstrução manual.

Aqui está como construí essa skill no Anti-Gravity. Você acessa o Skill Creator pela interface do Claude Code, e ele te guia para definir a frase de ativação da skill, parâmetros de entrada, conjunto de instruções, e quaisquer ferramentas ou APIs externas necessárias. O insight-chave é tratar a criação de skills como escrever uma assinatura de função muito detalhada: entradas claras, saídas claras, efeitos colaterais claros.

Minha skill de redesign aceita três entradas: a URL da página a analisar, o stack tecnológico alvo (padrão Next.js + Tailwind), e uma referência de estilo (geralmente uma captura de tela ou link do Figma da estética desejada). O conjunto de instruções diz ao Claude para primeiro analisar a hierarquia de conteúdo da página fonte, depois mapear essa hierarquia para os padrões de componentes do stack tecnológico alvo, e então gerar os componentes com a referência de estilo aplicada. Cada passo produz uma saída intermediária que posso revisar antes do próximo passo executar.

O passo de revisão intermediária é crítico. Aprendi da forma difícil que skills multi-passo totalmente autônomas produzem resultados impressionantes cerca de 70% das vezes e falhas espetaculares nos outros 30%. Adicionar checkpoints de revisão entre passos reduz a taxa de falha para perto de zero, ao custo de alguma intervenção manual. Vale a troca toda vez.

Para gerenciamento de chaves de API entre skills -- já que muitas delas chamam serviços externos -- uso variáveis de ambiente armazenadas em um arquivo .env que o Anti-Gravity carrega automaticamente. Chave de API do Firecrawl, chaves de API de geração de imagens, strings de conexão de banco de dados -- todas ficam em variáveis de ambiente em vez de hardcoded nas definições de skills. Isso mantém credenciais sensíveis fora das configurações das suas skills e torna trivial alternar entre ambientes de desenvolvimento e produção.

Mais uma coisa sobre skills que levei tempo para apreciar: elas compõem. Uma skill que faz scaffold de um componente pode ser combinada com uma skill que escreve testes, que se encadeia com uma skill que gera documentação. Construir uma biblioteca de skills componíveis é como construir uma biblioteca de scripts shell, exceto que cada script tem acesso a um motor de raciocínio de IA que pode se adaptar ao contexto atual.

Os desenvolvedores que conheço que são mais produtivos com Claude Code têm algo em comum: uma rica biblioteca de skills que construíram ao longo do tempo. O investimento inicial para criar cada skill é de uns 20-30 minutos. A economia de tempo contínua se multiplica a cada uso.

Configurando o Stack Completo: Anti-Gravity, Claude Code e Tudo Mais

Certo, deixe-me guiá-lo pelo processo real de configuração porque alguns detalhes me fizeram tropeçar e provavelmente farão você tropeçar também.

Passo 1: Instalação do Claude Code e seleção de plano. O Claude Code em si é gratuito para começar, mas o nível gratuito tem limitações significativas em volume de uso e acesso a modelos. O plano Pro a $20/mês desbloqueia limites de taxa mais altos e acesso ao Claude Opus, que é o modelo que uso para decisões arquitetônicas complexas e refatorações multi-arquivo. Para a maioria das tarefas de programação, o Claude Sonnet dá conta do trabalho, mas quando preciso que o modelo raciocine sobre design de sistemas ou desembarace um bug particularmente complicado, o Opus vale cada centavo. Instale o app do Claude Code pelo site da Anthropic -- é um aplicativo independente que também se integra ao seu terminal.

Passo 2: Configuração do IDE Anti-Gravity. O Anti-Gravity é o IDE do Google que fica sobre a experiência padrão de edição de código mas adiciona funcionalidades nativas de IA. Baixe-o na página de ferramentas de desenvolvedor do Google. O ponto-chave de integração é que o Anti-Gravity reconhece o Claude Code como provedor backend de IA, então você obtém as capacidades de raciocínio do Claude dentro da interface do IDE do Google. O IDE oferece múltiplos modos de interação logo de cara.

Primeiro, há o chat na barra lateral -- um painel de conversa persistente que fica aberto enquanto você programa. Uso para perguntas rápidas, explicações de código e pequenas modificações. Ele não consome uma janela de contexto separada da sua sessão principal de terminal, o que é importante para a estratégia de gerenciamento de contexto que descrevi antes.

Segundo, você tem extensões que adicionam funcionalidades potencializadas pelo Claude a tipos de arquivo e fluxos de trabalho específicos. As extensões que mais uso são a de revisão de código (destaca problemas potenciais antes de fazer commit) e a de refatoração (sugere melhorias ao código selecionado com aplicação em um clique).

Terceiro -- e é aqui que acontece a maior parte do trabalho pesado -- você ainda tem o terminal integrado diretamente no IDE. Esta é sua experiência completa do Claude Code, idêntica ao que você teria em um terminal independente, mas agora cercada pelo contexto visual da árvore de arquivos do seu projeto, editores abertos e painéis de tarefas.

Passo 3: Configure regras globais e locais. Isso mapeia diretamente para o framework BLAST. Regras globais vão no seu diretório de configuração do Claude Code e se aplicam a todo projeto em que você trabalha. As minhas incluem preferências gerais de programação: modo estrito do TypeScript, preferir padrões funcionais, sempre incluir tratamento de erros, escrever código auto-documentado. Regras locais ficam em um diretório .claude/ na raiz do seu projeto e contêm instruções específicas do projeto: o stack tecnológico, convenções de nomenclatura, padrões de API e quaisquer restrições únicas daquela base de código.

O Anti-Gravity lê ambos os conjuntos de regras e os aplica automaticamente quando você interage com o Claude em qualquer modo -- barra lateral, extensão ou terminal. Você configura as regras uma vez, e toda interação com o Claude as respeita. Sem mais copiar e colar a mesma linha de "lembre de usar modo estrito do TypeScript" em cada prompt.

Passo 4: Seleção de modelo. O Anti-Gravity suporta múltiplos modelos, incluindo Gemini 3.1 (modelo do Google) e Claude Opus. Testei ambos extensivamente para tarefas de programação, e aqui vai minha opinião honesta: Gemini 3.1 é forte para completamento de código, sugestões inline e edições rápidas. Claude Opus é mais forte para raciocínio multi-arquivo, decisões arquitetônicas e tarefas que requerem entender as relações entre componentes. Minha configuração usa Gemini para o chat da barra lateral (interações rápidas e leves) e Claude Opus para sessões de terminal (trabalho profundo e complexo). Você pode configurar isso nas configurações de modelo do Anti-Gravity -- diferentes modelos para diferentes modos de interação.

Passo 5: Conecte serviços externos. Aqui é onde a configuração fica realmente empolgante. O Anti-Gravity suporta conectores para Gmail, Notion, Google Calendar e outros serviços. Conectei meu workspace do Notion para que o Claude possa referenciar minha documentação de projeto e quadros de tarefas diretamente. Conectei meu calendário para que agentes agendados (mais sobre isso em instantes) possam verificar conflitos antes de reservar blocos de tempo focado para tarefas longas.

A configuração dos conectores envolve fluxos OAuth para cada serviço -- coisas padrão, nada exótico. A recompensa é que o contexto do Claude agora se estende além da sua base de código para seu ambiente de trabalho mais amplo. Quando peço ao Claude para "verificar as tarefas do sprint atual e escolher o ticket backend de maior prioridade", ele lê diretamente do meu quadro do Notion e gera um plano baseado na descrição real do ticket. Sem copiar e colar detalhes de tickets nos prompts.

Passo 6: Integração com GitHub e Vercel. Esses dois merecem menção especial porque fecham o ciclo do desenvolvimento ao deploy. A integração com GitHub permite ao Claude criar branches, fazer commits e abrir pull requests sem sair do IDE. A integração com Vercel permite acionar deploys e verificar URLs de preview. Meu fluxo típico agora: Claude constrói uma funcionalidade em uma sessão de terminal, cria um PR pelo conector do GitHub, Vercel automaticamente faz deploy de um preview, e eu reviso o preview ao vivo junto com o diff do código. Tudo dentro do Anti-Gravity. O loop de feedback de deploy que costumava levar 15 minutos de troca de abas agora acontece em uns 90 segundos.

Um detalhe sobre a integração com GitHub: certifique-se de que suas credenciais Git estejam configuradas via chaves SSH ou um helper de credenciais antes de conectar. Na primeira vez que tentei com credenciais HTTPS, o fluxo de autenticação falhou silenciosamente e o Claude apenas reportou "unable to push" sem contexto de erro útil. Chaves SSH resolveram imediatamente.

Gerenciamento Multi-Agente: Executando Fluxos de Trabalho Paralelos Sem Perder a Cabeça

Esta é a seção que eu gostaria que existisse quando comecei a escalar o uso do Claude Code. Rodar um único agente do Claude é simples. Rodar três ou quatro simultaneamente em diferentes tarefas dentro do mesmo projeto é onde a maioria dos fluxos de trabalho das pessoas desmorona.

O problema central é coordenação. O Agente A está refatorando o módulo de autenticação enquanto o Agente B está construindo um novo componente de dashboard que depende da API do módulo de autenticação. Se ambos modificam arquivos compartilhados sem consciência um do outro, você obtém conflitos de merge no melhor caso e bugs sutis de fluxo de dados no pior.

O gerenciador de tarefas do Anti-Gravity ajuda aqui mantendo um registro de agentes ativos e seu escopo atual. Você pode ver em quais arquivos cada agente está trabalhando, quais arquivos estão "travados" por modificações ativas, e quais tarefas estão na fila versus em andamento. Essa visibilidade sozinha previne a maioria das falhas de coordenação -- posso ver que o Agente A está modificando auth.ts e segurar a tarefa do Agente B até que essa modificação seja completada.

A funcionalidade de agendamento de agentes vai além. Posso definir uma sequência de tarefas -- "primeiro refatorar auth, depois construir dashboard, depois escrever testes de integração" -- e o agendador as executa em ordem, passando contexto relevante entre estágios. Cada tarefa obtém uma janela de contexto fresca (lembre da regra de degradação dos 50%), mas o agendador carrega adiante um resumo do que as tarefas anteriores realizaram e quais arquivos modificaram.

Para tarefas verdadeiramente independentes -- trabalho em funcionalidades não relacionadas que não compartilham arquivos nem APIs -- executo agentes em paralelo sem agendamento. O Anti-Gravity pode gerenciar sessões simultâneas em painéis de terminal separados, cada um com sua própria janela de contexto e escopo de tarefa. O gerenciador de tarefas me mostra uma visão unificada de todo o trabalho ativo, para que eu possa monitorar o progresso sem alternar entre terminais.

Meu padrão diário típico: começo a manhã enfileirando três ou quatro tarefas no agendador com base nas prioridades do meu sprint. As primeiras uma ou duas são sequenciais (geralmente funcionalidades dependentes). O restante é paralelo (funcionalidades independentes ou correções de bugs). Reviso a saída conforme cada tarefa é completada, aprovo ou solicito revisões, e o agendador passa para o próximo item. Em um dia produtivo, essa configuração gera mais código revisado, testado e commitado até a hora do almoço do que eu costumava produzir em um dia inteiro de programação manual.

Uma ressalva honesta: a abordagem multi-agente requer boa cobertura de testes para capturar problemas de integração. Executo a suíte completa de testes depois que cada agente completa sua tarefa, e já peguei regressões sutis que pareciam boas isoladamente mas quebravam quando combinadas. Sem testes, agentes paralelos criariam mais problemas do que resolveriam. Isso não é um atalho para evitar disciplina de engenharia -- é um multiplicador em cima dela.

O que Errei e o que Faria Diferente

Quero ser direto sobre os erros que cometi ao construir esse fluxo de trabalho, porque os tutoriais fazem tudo parecer suave e a realidade tem atrito.

Erro um: automatizar demais cedo demais. Fiquei empolgado com Claude Skills e tentei criar automações para tudo na primeira semana. A maioria dessas skills iniciais era rígida demais -- assumiam estruturas de projeto específicas e quebravam quando eu as usava em bases de código diferentes. As skills que uso diariamente agora são as que construí depois de um mês de repetição manual, quando entendia profundamente o fluxo de trabalho que estava automatizando. Construa skills a partir de padrões que você comprovou manualmente. Não tente automatizar fluxos de trabalho que não tenha feito manualmente pelo menos dez vezes.

Erro dois: ignorar a janela de contexto até ser tarde demais. Nas primeiras duas semanas, tratei a regra dos 50% de contexto como uma diretriz em vez de um limite rígido. "Vou só continuar essa sessão, está quase pronto." O código gerado nessas sessões sobre-estendidas me custou mais tempo de depuração do que começar uma sessão nova teria custado. Agora trato como regra rígida. Quando meu contexto parece pesado, fecho e reinicio. Sempre.

Erro três: usar o modelo errado para a tarefa errada. Usava Claude Opus como padrão para tudo porque sentia que usar o "melhor" modelo daria os melhores resultados. Acontece que Opus é exagero para modificações simples de arquivo e na verdade é mais lento que Sonnet para tarefas diretas. O overhead do raciocínio mais profundo do Opus adiciona latência sem melhoria proporcional na qualidade quando a tarefa é "adicione um spinner de carregamento neste botão". Combine a complexidade do modelo com a complexidade da tarefa. Use Opus para arquitetura e decisões de design. Use Sonnet (ou até Gemini 3.1 para completamentos inline) para tarefas de implementação onde a direção já está clara.

Erro quatro: não investir o suficiente em regras locais. Meus primeiros projetos com essa configuração tinham regras locais escassas -- talvez cinco ou seis linhas. A IA constantemente fazia suposições que não correspondiam às convenções do meu projeto, e eu gastava tempo corrigindo. Agora meus arquivos de regras locais têm 40-60 linhas e incluem exemplos específicos de padrões preferidos junto às regras em si. Mostrar ao Claude um exemplo do padrão de tratamento de erros que você quer é dez vezes mais eficaz do que descrevê-lo em termos abstratos.

O que faria diferente se começasse de novo: Passaria o primeiro dia inteiro apenas configurando regras e testando-as contra prompts de exemplo antes de escrever qualquer código real. O tempo de configuração se paga na primeira semana, mas fui impaciente demais para investir isso no início e paguei o preço em ciclos de correção por um mês.

O Impacto Mensurável: Antes e Depois Dessa Configuração

Quero compartilhar números específicos porque afirmações vagas sobre "ganhos de produtividade" são inúteis sem contexto.

Antes (Claude Code apenas no terminal, sem framework):

• Tempo médio para construir uma funcionalidade CRUD com testes: 3,5 horas
• Depuração relacionada a contexto por semana: aproximadamente 4 horas
• Deploys falhados por problemas de integração: 2-3 por semana
• Skills/automações: zero, tudo manual

Depois (Anti-Gravity + BLAST + Claude Skills, 6 semanas depois):

• Tempo médio para construir uma funcionalidade CRUD com testes: 1,2 horas
• Depuração relacionada a contexto por semana: menos de 30 minutos
• Deploys falhados por problemas de integração: talvez 1 por mês
• Skills ativas na minha biblioteca: 14 (8 estáticas, 6 dinâmicas)

A métrica de funcionalidade CRUD é a comparação mais confiável porque é a tarefa mais padronizada. Outros trabalhos -- integrações complexas, funcionalidades novas, design de arquitetura -- são mais difíceis de comparar porque não existem duas tarefas idênticas. Mas subjetivamente, a melhoria parece consistente em todos os tipos de tarefa.

A métrica de depuração relacionada a contexto é a melhoria mais satisfatória. Quatro horas por semana de "por que o Claude está gerando código estranho" evaporaram quase completamente quando adotei a disciplina de uma-janela-por-tarefa e comecei a monitorar o uso de contexto pela interface do Anti-Gravity.

A métrica de deploy melhorou em parte pela melhor qualidade de código de janelas de contexto frescas, e em parte porque a integração GitHub-para-Vercel captura problemas em deploys de preview antes de chegarem à produção. Ambos os fatores vêm da configuração do Anti-Gravity.

Uma métrica que não consigo quantificar mas sinto fortemente: fadiga cognitiva. O fluxo de trabalho antigo me deixava mentalmente esgotado às 15h. Gerenciar tudo na minha cabeça -- qual agente fez o quê, quais arquivos mudaram, onde parei -- consumia energia que deveria ter ido para decisões reais de engenharia. Descarregar esse gerenciamento para o IDE liberou largura de banda mental que percebo mais na qualidade do meu trabalho à tarde.

Ganhos rápidos a esperar na primeira semana: as regras globais e locais por si só vão melhorar visivelmente a qualidade de saída do Claude. O chat na barra lateral vai reduzir sua troca de contexto entre documentação do navegador e terminal. A visibilidade de mudanças em arquivos vai capturar modificações não intencionais que fluxos de trabalho apenas-terminal não detectam.

Ganhos de longo prazo (semanas 3-6): sua biblioteca de skills começa a compor. Fluxos de trabalho multi-agente se tornam práticos. O framework BLAST se torna memória muscular em vez de um processo consciente. O sistema completo -- IDE, framework, skills, agentes -- começa a parecer uma única ferramenta integrada em vez de uma coleção de partes.

Para Onde Acredito que Isso Está Indo

Seis meses atrás, eu escrevia prompts do Claude Code em um terminal e me sentia produtivo. Agora estou orquestrando múltiplos agentes de IA através de uma interface visual com automações personalizadas e pipelines de deploy integrados. O ritmo de mudança nesse espaço é genuinamente desorientador, e acredito que ainda estamos nos primeiros capítulos.

A combinação das capacidades de raciocínio do Claude Code com a camada de gerenciamento visual do Anti-Gravity aponta para um futuro onde o IDE não é apenas um lugar para escrever código -- é um centro de comando para dirigir agentes de IA que escrevem código em seu nome. Seu trabalho muda de implementação para especificação, revisão e orquestração.

Essa mudança assusta alguns desenvolvedores. Eu entendo. Mas de onde estou, isso não torna as habilidades de engenharia menos valiosas. Torna-as mais valiosas. Os desenvolvedores que entendem design de sistemas, que conseguem escrever especificações claras, que sabem como estruturar um projeto para manutenibilidade -- eles são os que mais tiram proveito dessas ferramentas. A IA cuida da digitação. Você cuida do pensamento.

Se você levar uma coisa deste post, que seja a disciplina da janela de contexto. Uma janela por tarefa. Contexto fresco para trabalho fresco. Tudo mais que descrevi se constrói sobre essa base, e não custa nada implementar agora mesmo em qualquer configuração que você já esteja usando.

As ferramentas vão continuar evoluindo. Google vai enviar atualizações para o Anti-Gravity. A Anthropic vai melhorar as capacidades de programação do Claude. Novos frameworks e técnicas vão surgir. Mas o princípio de gerenciar o contexto da sua IA como um recurso escasso -- essa é uma percepção permanente. E é a que fez a maior diferença no meu trabalho.

Como é seu fluxo de trabalho com Claude Code agora? Tenho genuína curiosidade sobre se outros encontraram soluções diferentes para o problema de gerenciamento de contexto, ou se a abordagem de uma-janela-por-tarefa é tão universal quanto tem sido na minha experiência.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io