---
title: "Curso Completo de Claude Code — 4 Horas"
author: "Marco Fernández / X"
description: "Este é o curso definitivo sobre Claude Code para iniciantes. O instrutor usa o Claude Code todos os dias para gerenciar um negócio que gera mais de 4 milhões de dólares por ano em lucro. Ele também..."
source: "https://adhenawer.net/posts/pt_br/curso-completo-claude-code-4-horas.html"
lang: pt-BR
---

TL;DR · principais pontos

1. Este é o curso definitivo sobre Claude Code para iniciantes.
 2. Sem rodeios, este é o roteiro completo do curso.

## INTRODUÇÃO E VISÃO GERAL DO CURSO 0:00

Este é o curso definitivo sobre Claude Code para iniciantes. O instrutor usa o Claude Code todos os dias para gerenciar um negócio que gera mais de 4 milhões de dólares por ano em lucro. Ele também ensina mais de 2.000 pessoas a usar o Claude Code tanto para tarefas pessoais quanto corporativas e profissionais — e é, em grande medida, o que ocupa seu dia inteiro. Uma vez que você entenda o que está prestes a ser ensinado neste curso, não é exagero dizer que o Claude Code vai amplificar sua produtividade. Você vai encontrar alavancagem em áreas que provavelmente nem sabia que tinha — tanto para engenharia de software quanto para outras partes da sua vida. O foco aqui não é software em si. Não é preciso ter formação técnica para entender o que será apresentado. O conteúdo começa devagar e constrói os conceitos de forma natural e gradual para que todo mundo esteja na mesma página.

Sem rodeios, este é o roteiro completo do curso. Começa com o básico: baixar e configurar o Claude Code. Em seguida, são apresentados os ambientes de desenvolvimento integrado, ou IDEs. Há vários no mercado, e os três mais usados são apresentados para que todos estejam familiarizados. Depois disso, é mostrado como configurar o “cérebro do projeto”, que é o arquivo claude.md. Com isso feito, o Claude Code é usado para construir algo de verdade, porque o foco de todo o curso é na construção prática. Será desenvolvido um aplicativo web simples hospedado ao vivo na internet — aprendendo fazendo, não apenas assistindo a uma demonstração. Após isso, são cobertos o diretório .claude, a pasta de subagentes e uma série de funcionalidades que poucas pessoas conhecem. Em seguida, os vários modos do Claude Code são detalhados: o plan mode, que muitos já ouviram falar; o modo “dangerously skip permissions”, que ganhou alguma notoriedade recentemente; e como usá-los, além de como usá-los com segurança. Depois disso, são abordados builds complexos de projetos usando plan mode. Na sequência, vem o gerenciamento de contexto — um termo muito em voga atualmente. Serão apresentadas formas de gerenciar o contexto com eficiência, evitar a degradação de contexto e garantir que os prompts sejam construídos e estruturados de forma a maximizar o retorno. Todos os slash commands do Claude Code são percorridos e explicados. Em seguida, os hooks são abordados: scripts customizados que podem ser disparados automaticamente antes ou depois de qualquer tool call do Claude Code. Depois, as skills do Claude Code, que é basicamente como criar arquivos de skill que transformam o Claude Code em uma série de agentes especializados diferentes. A seguir, o Model Context Protocol e como configurá-lo de forma eficaz. São apresentados alguns sistemas automatizados que podem ser construídos rapidamente com Model Context Protocol, incluindo gerenciadores de email, um sistema de contabilidade próprio e muito mais. Os plugins e marketplaces do Claude Code são cobertos. A integração com o Chrome DevTools é apresentada — uma conexão muito subestimada entre o Claude Code e o Chrome que permite coletar dados de fontes que não têm APIs. É extremamente valioso aprender. Os subagentes do Claude Code com acesso controlado a ferramentas são detalhados. A nova funcionalidade de agent teams é apresentada e como usá-la produtivamente. E então, Git worktrees e mobilidade de sessão — o que essencialmente permite criar sessões paralelas do Claude sem muitas das desvantagens que ferramentas como o Claude Bot infelizmente resultaram. Por fim, é coberto escalonamento e deploy: como pegar as automações e rodá-las em produção usando Modal webhooks, GitHub Actions e Claude Code na web.

## INSTALAÇÃO E CONFIGURAÇÃO INICIAL DO CLAUDE CODE 1:53

A primeira coisa que precisa ser feita é comprar uma assinatura do Claude Code. O motivo é que ele não está disponível no plano gratuito de zero dólares. Para ter acesso ao Claude Code, é necessário pelo menos o plano Pro para produtividade cotidiana. Esse é o plano recomendado para quem está começando. O dinheiro gasto em uma assinatura assim é tão pequeno comparado aos enormes benefícios de produtividade que, apesar de custar 17 dólares, não vale sequer questionar. Não é exagero dizer que o Claude Code provavelmente entrega benefícios de produtividade na ordem de 10.000 a 15.000 dólares por mês, porque não é apenas alguém com habilidades de desenvolvedor, o que permite construir sistemas que aliviam estresses e tensões na vida. Ele vai muito além de um desenvolvedor. É basicamente um segundo cérebro neste ponto.

Após clicar em “try Claude”, a página leva ao login. Depois de concluído, é possível criar a conta pela primeira vez. As opções de notificações podem ser selecionadas conforme preferência — se a caixa de entrada de email já é muito movimentada, é razoável não assinar atualizações ocasionais de produto. Em seguida, há uma tela de onboarding com informações pessoais para preencher. O plano Pro custa 17 dólares, mas em outras moedas a conversão pode elevar esse valor — em dólares canadenses, por exemplo, esse valor se converte em torno de 28 dólares.

Após concluir a assinatura, o que se tem é uma conta Claude. Isso é tudo que é necessário para começar. A partir daqui, a forma mais simples de começar com o Claude Code é abrir uma instância de terminal. Isso pode parecer intimidador para muitos. Então será mostrado como fazer tanto no terminal quanto na interface gráfica, que a Anthropic montou há cerca de quatro ou cinco meses.

Qualquer recurso apresentado ao longo do curso provavelmente terá uma aparência um pouco diferente no momento em que for consultado versus quando foi gravado. Isso acontece porque o Claude Code, a Anthropic e as ferramentas de IA em geral mudam muito rapidamente, especialmente porque a maioria dos desenvolvedores também usa o Claude Code, o que multiplica a produtividade deles. O que importa não é o layout específico, as cores, as palavras na tela. O que importa mais é saber onde encontrar as coisas. O recurso número um para consultar funcionalidades avançadas do Claude Code é a documentação oficial em code.anthropic.com/docs.

A documentação do Claude Code especifica que para instalar o Claude Code no sistema pela primeira vez, é possível executar o que se chama de comando curl. No macOS, Linux ou WSL, basta abrir um terminal — no Mac, basta digitar “terminal” — e executar o comando de instalação fornecido. No Windows, o processo é equivalente usando PowerShell ou CMD. Após executar o comando e aguardar a instalação, o Claude Code está instalado no computador.

Uma vez instalado, tudo que é preciso fazer para usar o Claude é digitar a palavra “claude” diretamente no terminal. É realmente simples assim. Se for a primeira vez fazendo login, o sistema pedirá autenticação automaticamente quando o programa for aberto. Caso contrário, também é possível digitar `/login`. Uma vez clicado, isso leva à conta Claude que foi criada anteriormente. Após concluir a autenticação, o Claude Code está configurado. É possível fechar essa janela e se verá a instrução para pressionar Enter para continuar.

Só para estar na mesma página: tudo que foi feito até agora foi basicamente abrir uma interface de chat com um modelo de IA. É apenas que, em vez de estar em um aplicativo desktop bonito ou na web, está no terminal. O valor aqui é que, em vez de executar um modelo de IA na web ou em algum servidor de nuvem distante, o que se está fazendo agora é executá-lo localmente no computador. Isso dá a capacidade de pegar esse modelo e modificar localmente arquivos no computador, escrever scripts, escrever histórias, escrever poemas, reestruturar o organizador de arquivos, limpar o PC ou o Mac. Essa coisa está conectada ao computador local. Isso por si só já o torna extraordinariamente poderoso.

## ENTENDENDO A INTERFACE DO CLAUDE CODE NO TERMINAL 5:02

A tela do terminal pode parecer bastante intimidadora para iniciantes. A maioria das pessoas acaba usando o fluxo do terminal, não o fluxo da interface gráfica. Então vale entender o que aparece na tela.

No canto superior esquerdo, há o ícone do Claude Code — parece um caranguejo ou uma água-viva, mas é adorável. Em seguida, aparece “Claude Code” com a versão atual. Abaixo disso, o modelo que está sendo usado — por exemplo, Opus 4.6. Depois, o plano em uso — como Claude Max, que é alguns níveis acima do plano Pro. E então, talvez o mais importante, o diretório de trabalho atual. Como mencionado, o Claude Code está trabalhando dentro do computador em uma pasta específica. No caso de uso inicial, o Claude Code está em `/users/[nome-do-usuário]`, que é basicamente a pasta home no macOS.

Abaixo disso está o campo de comando anterior — por exemplo, se foi digitado `/clear` para limpar tudo e dar uma lousa em branco. Em seguida, vem onde se insere texto. Quando se digita algo, aparece aqui. Abaixo disso, o modelo é exibido novamente. Em seguida, os vários modos. O modo atual pode ser “bypass permissions” — um modo um tanto perigoso, um modo com o qual muitas pessoas não se sentem super confortáveis, mas que é o modo preferido para trabalho de conhecimento e tarefas intelectualmente valiosas. É possível alternar entre modos simplesmente clicando em Shift e Tab. Há também informações sobre a versão, qual a mais recente, e no lado direito, a contagem de tokens.

A contagem de tokens é algo muito interessante. É possível ajustá-la — trata-se da linha de status do Claude Code, que também será abordada em detalhes. É possível deixá-la colorida, personalizada e exibindo o que se quiser.

A primeira coisa a fazer é apenas dizer “Hey, como vai?” para demonstrar. Imediatamente depois do envio, um novo prompt aparece com uma palavra como “finagling” ou “processing” ou algo parecido. O Claude Code usa uma série de termos engraçados sempre que está pensando — termos como “finagling”, “processing”, “ruminating”, “considering”. São bem engraçados e é possível customizar isso.

Em seguida, aparece o número de segundos que a consulta já dura. Depois de dois segundos de “hey, como vai?”, ele produziu cinco tokens. E por fim, também há a contagem de tokens. Para estar na mesma página: um token não é o mesmo que uma palavra, mas para a maioria dos propósitos práticos, pode-se considerar um token como análogo a uma palavra. Por exemplo, “hey, como vai?” não são quatro tokens. Podem ser quatro palavras, mas provavelmente algo entre seis e sete tokens. Pense nos tokens como análogos a palavras — apenas alguns a mais.

Uma informação adicional importante que aparece é chamada “context”. O contexto vai de zero a cem por cento e é basicamente quanto do histórico de conversa foi utilizado na janela de chat atual com a instância atual do Claude Code. Isso se torna muito importante mais adiante quando se está projetando técnicas melhores de gerenciamento de contexto, que é uma parte significativa do que este curso aborda. Pelo menos no momento desta gravação, o gerenciamento de contexto é o grande gargalo para fazer esses sistemas fazerem mais e melhor.

Também se nota que no lado direito, o contador de tokens subiu significativamente. Basicamente, isso significa que com cerca de 20.000 tokens, estamos a aproximadamente 10% do caminho pelo thread de conversa inteiro disponível. O que é muito legal é que o Claude Code pega todo esse histórico e em intervalos regulares o comprime para aumentar a densidade de informação — pegando uma sequência de texto e tornando-a cada vez mais compacta. Mesmo que algo tenha sido escrito de forma verbosa, à medida que o contexto aumenta, o Claude gerencia isso automaticamente para garantir que se mantenha dentro da janela.

## AMBIENTES DE DESENVOLVIMENTO INTEGRADO (IDES) — VISUAL STUDIO CODE E CURSOR 8:18

Os terminais são muito semelhantes às interfaces gráficas — apenas parecem mais intimidadores. É recomendável que as pessoas se acostumem a usar no terminal porque, ao fazer isso, se desbloqueia ainda mais funcionalidades. É possível executar vários terminais lado a lado, usar diferentes ferramentas de terminal que oferecem tempos de atualização mais rápidos e assim por diante. Mas para quem está começando, a interface gráfica também funciona muito bem.

Então, o que é um ambiente de desenvolvimento integrado (IDE)? Um IDE é basicamente três coisas juntas: um organizador de pastas de arquivos, mais um editor de texto, mais um widget de chat com IA, similar ao que se obtém em chatgpt.com ou claude.ai. É como ter o Finder do Mac — onde se pode ir em finder e basicamente navegar por uma série de pastas onde se pode selecionar diferentes arquivos e abri-los — mais algo como o Bloco de Notas ou Notes, mais algo como o ChatGPT, tudo em um único lugar.

Atualmente há dois IDEs principais para os quais o mercado está convergindo. O primeiro se chama Visual Studio Code. O segundo se chama Cursor. O Visual Studio Code é o original, porque o Cursor foi construído sobre ele. O VS Code foi desenvolvido há muito mais tempo pela Microsoft. É muito extensível, tem excelente suporte e é muito direto. O Cursor pode ser considerado como o Visual Studio 2.0 — não só tem a maioria das mesmas funcionalidades, algumas ainda em beta, mas também é muito mais moderno e tem um foco muito maior em IA, que é obviamente o ponto principal.

Será mostrado inicialmente como configurar as coisas no Visual Studio Code. Depois, a configuração no Cursor. E para o restante do curso, todo o trabalho será feito no Cursor.

Para instalar o Visual Studio Code, basta acessar visualstudio.com e baixar para o sistema operacional específico. No macOS, basta arrastar o aplicativo para a pasta de aplicativos. Ao abrir, tem-se uma tela que se parece com um explorador de arquivos no lado esquerdo. Clicando em “Open a folder”, é possível navegar pelo computador e abrir qualquer pasta. Ao clicar em um arquivo, ele se abre no editor de texto central — que é onde se vê e edita o código.

Agora, o VS Code não vem com o Claude Code por padrão. Para acessar o Claude Code, é necessário baixá-lo como extensão. No lado esquerdo, clicar nos blocos (ícone de extensões) e pesquisar “Claude Code”. Haverá várias opções — a que se está procurando é a desenvolvida pela Anthropic, com o marca de verificação de desenvolvedor verificado. É muito importante preferir usar fontes verificadas — pessoas têm inserido malware e outras coisas em extensões não verificadas. Após instalar, se terá acesso ao Claude Code no VS Code.

Para usar o Claude Code no VS Code, clicar no botão Claude Code no canto superior direito da janela do agente. Também há um logo do Claude no canto superior. A interface resultante é bem diferente da do terminal, mas funciona essencialmente da mesma forma.

Na interface do VS Code: no topo, há a aba de conversas passadas — é possível voltar a qualquer conversa anterior com o Claude Code à medida que o histórico se acumula, tanto localmente quanto na web. Abaixo disso, o logo do Claude Code. Abaixo, a janela de chat. Ao digitar e enviar uma mensagem, aparece o mesmo tipo de texto de processo de “accomplishing” ou “fidgeting” — aquele texto de processamento divertido que aparecia no terminal. Depois disso, vem a resposta.

No canto inferior esquerdo, há os vários modos de permissão. Assim como antes havia “dangerously skip permissions” no terminal, o mesmo está disponível aqui. Ao clicar nesse botão, é possível alternar entre todos os diferentes modos possíveis, e o contorno em torno do chatbot também muda de cor de acordo com o modo selecionado.

Quando está em “ask before edits”, antes de fazer qualquer alteração em arquivos locais, o Claude vai perguntar para confirmar. Isso é bastante seguro e muitos programadores mais tradicionais trabalham assim. Mas quando o Claude está no meio de um trabalho intenso e está pedindo edições a cada cinco segundos, se realmente se quer desbloquear a produtividade, ou se usa “edit automatically”, ou se usa “bypass permissions”.

À direita disso fica o arquivo que está atualmente sendo passado como contexto. Por exemplo, se há um arquivo index.html aberto, o Claude está atualmente “olhando” para aquele arquivo. Ao perguntar “que arquivo você está olhando agora?”, ele dirá que está olhando pelo index.html que está aberto no editor. Ele não leu o conteúdo ainda, porque ler um arquivo massivo consumiria bastante tokens — o que custaria dinheiro. Mas é possível pedir mudanças nele em tempo real, como mudar o título ou refatorar de modo escuro para modo claro.

## CONFIGURANDO O CURSOR (ANTERIORMENTE "ANTIGRAVITY") 11:57

Assim como esperado, o Cursor é bem similar ao VS Code. Ele tem um site em cursor.sh (anteriormente tinha branding diferente). Ao baixar e abrir, a aparência é muito parecida com o que foi visto no VS Code, porque os dois foram construídos um sobre o outro. Assim como o VS Code era um explorador de arquivos, um editor de arquivos e um gerenciador de agentes, o Cursor tem exatamente essas três ideias. No lado esquerdo ficam as pastas. No meio, o conteúdo dos arquivos. No lado direito, a conversa com agentes.

A única diferença real entre o Cursor e o VS Code é o que está no lado direito. No VS Code, havia um botão dedicado para o Claude Code. No Cursor, por padrão, não há. Para acessar o Claude Code no Cursor, assegurando que a extensão já está instalada, é necessário deletar o ícone padrão (que é o Gemini do Google) e substituí-lo pelo ícone do Claude. O motivo é que o Cursor é um produto do Google, então eles tentam promover os modelos Gemini. Mas é possível usar qualquer modelo que se queira.

Para deixar claro: este é um curso específico de Claude Code. Mas é possível usar qualquer modelo para qualquer propósito dentro do IDE. O tipo de modelo é menos importante do que ser muito bom em usá-lo e o fato de ele ser inteligente. Após fazer a troca, o layout fica exatamente igual ao do VS Code. Não há mais nada a cobrir sobre o Cursor especificamente — a interface é idêntica. Agora é hora de construir coisas de verdade.

## O ARQUIVO CLAUDE.MD — O CÉREBRO DO PROJETO 13:40

Agora que está configurado no Cursor, a próxima coisa importante é o claude.md, que é o cérebro do workspace. Para deixar isso bem simples e direto, porque muitas pessoas entendem mal como os claude.mds funcionam, vale examinar uma conversa hipotética.

Imagine que você está do lado direito da tela. O que você faz é enviar uma mensagem dizendo: “pesquise X para mim” — pesquise, não sei, as melhores postagens em tendência no Twitter no seu nicho, seja lá o que for. Então o que acontece depois é que o modelo — Claude, seja Opus 4.6, 4.5, Sonnet ou Haiku — vai responder dizendo “claro, um momento”. Após retornar o que foi pedido, você continua nessa linha. O padrão é: usuário, depois modelo, depois usuário, depois modelo.

A forma como o prompt do claude.md funciona é a seguinte: bem na primeira mensagem, antes mesmo de chegar a esse ponto, o que está oculto é o fato de que existe na verdade um outro prompt. Esse prompt é injetado no topo da string de conversa antes mesmo de a primeira mensagem ser enviada. E assim, esse claude.md sendo a primeira coisa que o modelo lê e internaliza é realmente muito importante para ajudar a direcionar o output. Isso é o que se chama de “esterçar o navio”.

Existe uma analogia útil aqui. Imagine que se está em algum lugar na costa leste da América do Norte e se está tentando ir para a costa mais a oeste da África. Essas distâncias intermediárias são enormes — provavelmente ao menos 10.000 quilômetros. Se um navio está posicionado na saída do porto e o destino está do outro lado, com capacidade limitada de esterçar ao longo do caminho, a única forma de chegar o mais próximo possível ao destino seria ser muito preciso na direção de saída do porto. Porque se não for, mesmo um desvio muito pequeno de ângulo pode parecer pouca coisa inicialmente, mas ao longo de uma distância de dezenas de milhares de quilômetros, isso se desvia enormemente do objetivo.

A esterçabilidade em IA é basicamente quando se tenta minimizar a amplitude de opções potenciais. O que o claude.md faz é permitir pegar o espaço de, digamos, um ângulo muito amplo de direções para onde a IA poderia ir e comprimi-lo em um subconjunto muito mais provável de opções. Assim, mesmo que se esteja ligeiramente errado, o impacto no destino final — embora não vá chegar exatamente ao objetivo — ainda estará bem perto.

Portanto, deve-se tratar o claude.md como a trajetória inicial a partir da qual todas as sessões do Claude são lançadas, seja no terminal ou na interface gráfica. Com esse entendimento, agora que estamos na mesma página sobre como o claude.md é injetado no início de qualquer conversa, começa-se a perceber que há um valor tremendo em fazer esse claude.md o mais high quality possível.

Incluir um arquivo CLAUDE.md maiúsculo em qualquer diretório de projeto workspace significa que ele é injetado no início da conversa. E assim, não se fala com ele de forma diferente do que se falaria com o próprio Claude. É apenas um arquivo que padroniza e torna muito fácil construir convenções para diferentes workspaces.

Nesse arquivo, é preciso ser muito conciso, e também dar ao modelo os limites para os quais esse workspace serve. Seria possível copiar todo o conteúdo do claude.md e colá-lo diretamente no Claude Code e então se livrar do claude.md completamente. Mas o valor em ter um claude.md é não ter que fazer isso toda vez. É inicializado no topo do histórico de conversa como foi visto. E o que está no arquivo, para ser honesto, não é super importante em termos de conteúdo específico — o que importa é que ele existe e contém as instruções relevantes para o projeto.

## DESIGN DE WEBSITES COM CLAUDE CODE — TRÊS ABORDAGENS 15:48

Agora que se sabe sobre o claude.md, é hora de construir o primeiro website. Para simplificar, começa-se provavelmente com o build mais direto: uma página web completa — não apenas o hero header, que é a seção do topo, mas o site inteiro.

O motivo de começar com isso é deixar todos entenderem quão bom o Claude Code e ferramentas similares ficaram em design de websites de alta qualidade. Há um site chamado godly.website que basicamente mostra designs de alta qualidade premiados. Praticamente todos esses sites, com talvez algumas exceções, são agora realizáveis em provavelmente menos de 10 minutos usando o Claude Code. Isso não é apenas conversa — é algo que foi feito pessoalmente dezenas de vezes, incluindo construir 15 sites em um dia para um projeto.

Além disso, também será aprendido como o claude.md afeta os prompts, serão abordadas as três principais formas que as pessoas usam atualmente para criar sites, e haverá uma discussão rápida sobre deploy.

As três maneiras principais pelas quais as pessoas estão atualmente projetando com Claude Code são:

A primeira é fornecer um design pré-existente e então dar ao Claude Code a capacidade de fazer screenshot de si mesmo repetidamente. O que acontece é que a primeira variante que o Claude Code cria será como uma correspondência de 80%. Depois, o Claude faz um screenshot, compara diretamente com a imagem fonte e lista todas as diferenças. Então chega a 90% do caminho. Depois a 95%. E geralmente consegue chegar a algo como 99% de correspondência. O valor nessa abordagem é pegar um site de inspiração — talvez algo de godly.website ou Dribbble — e usá-lo como modelo para extrair fundamentos de design: tamanho do texto, cores, como os botões ficam, e por aí vai. Então se muda o conteúdo do site com o Claude para que seja o site que se quer fazer.

A segunda maneira é simplesmente fazer um grande despejo de transcrição de voz. Existem ferramentas que permitem gravar um grande texto usando transcrição de voz. Ao segurar uma tecla de função, um widget aparece na parte inferior da tela e escuta tudo que se diz. E porque se pode falar muito mais rápido do que se digita — a maioria das pessoas digita entre 50 a 70 palavras por minuto, mas falamos por volta de 200 palavras por minuto, o que é uma melhoria de 2,5x a 3x — é possível descrever em detalhes o que se quer no website. O modelo extrai o significado do texto, então um grande despejo de transcrição de voz funciona muito bem para especificar tudo que se quer.

A terceira forma é usar componentes. Existem serviços como o 21st.dev onde designers criaram componentes específicos de websites. É possível clicar em um componente e então clicar em “copy prompt”. Isso copia todo o texto necessário para o Claude Code reproduzir aquele componente. É muito simples: criar uma conta em um desses serviços, navegar pelos componentes, encontrar um que se goste, copiar o prompt e colar no Claude Code pedindo para instalar aquilo em determinado lugar do site.

Pessoalmente, considera-se muito mais fácil ir direto para a opção um — dar ao Claude um design e um loop de screenshot e deixar funcionar a partir de algo pré-existente. O resultado final vai ser bem diferente do site de inspiração — é apenas uma boa forma de ter uma ideia aproximada do design final sem ter que se preocupar com coisas como tamanho de fontes, cores e assim por diante.

Antes de partir para o design de verdade, é necessário entender a diferença entre construir algo e fazer o deploy. Quando se constrói algo, normalmente se está construindo localmente — rodando no computador local. Se se quer que outras pessoas possam acessá-lo, é necessário fazer o deploy, colocar na internet. Há diversas ferramentas que permitem fazer isso. Para o momento, será mostrado apenas como construir as coisas. Ao longo do curso, em módulos seguintes, serão abordadas ferramentas como Netlify, Vercel, Modal e outras que permitem colocar tanto software quanto websites e apps completos na nuvem para que outras pessoas possam acessar.

## LOOP DE SCREENSHOT E PROCESSO DE DESIGN ITERATIVO 19:22

Para usar a abordagem de screenshot com referência visual, o primeiro passo é capturar um screenshot completo do site de inspiração. Para isso, abrir as ferramentas do desenvolvedor do Chrome usando Cmd+Shift+I ou clicando com o botão direito na página e selecionando “Inspecionar”. Na janela que se abre, mudar as dimensões para largura total de desktop em resolução 1920x1080 — essa é a proporção widescreen padrão. Então pressionar Cmd+Shift+P (ou Ctrl+Shift+P no Windows) para abrir a barra de comandos. Com essa barra aberta, digitar “screenshot” e selecionar “Capture full size screenshot”. Isso vai rolar pela página inteira e tirar um screenshot completo de cima a baixo. Não é algo que muita gente sabe que é possível, mas funciona muito bem.

Uma vez com o screenshot, é necessário fazer mais uma coisa: reduzir o tamanho do arquivo. Se um arquivo de 20 megabytes fosse enviado para o Claude Code, primeiro consumiria enormemente o limite de tokens, e segundo a API tem um limite de tamanho de arquivo. O arquivo precisa ser significativamente menor. É possível usar um serviço como iloveimage.com para redimensionar a imagem — reduzir em 50% ou 75% para obter um arquivo com menos de 4-5 megabytes. Isso fica um pouco borrado, mas ainda tem qualidade suficiente para o propósito.

Com o screenshot redimensionado, ele é adicionado ao Claude Code. No modo bypass permissions, é possível encontrar o arquivo e arrastá-lo ou copiá-lo e colá-lo diretamente no campo de entrada.

Além do screenshot, também é útil copiar os estilos do site de referência. Para isso, voltar ao site, encontrar a tag body e clicar com o botão direito em “Copy styles”. Isso copia os estilos do site, incluindo as cores dos botões e os gradientes de fundo. Ao colar isso junto com o screenshot, o Claude Code tem tanto a referência visual quanto informações de cor e estilo.

Com a imagem e os estilos fornecidos, o claude.md já contém a instrução que diz ao Claude o que fazer quando receber uma imagem de referência — algo como “quando o usuário fornecer uma imagem de referência, screenshot e opcionalmente algumas notas de CSS, gere um website”. Então o Claude imediatamente começa a analisar a imagem de referência e construir a recriação do website.

O Claude vai criar um arquivo HTML, tirar screenshots dele, comparar com o screenshot de referência e fazer ajustes iterativos. Essa é a filosofia central de build do Claude Code: dar uma tarefa de alto nível, deixar executar, e deixar verificar seus próprios resultados. O que muitas pessoas fazem errado com o Claude Code é dar uma tarefa, deixar fazer, e simplesmente dar outra tarefa — sem verificação. Sem esse loop de verificação, perde-se a grande maioria do valor da IA.

A IA não vai ser perfeita na primeira vez, mas o valor da IA não está em sua capacidade de acertar 100% de primeira. O valor da IA está na velocidade: ela consegue chegar a 80% muito rapidamente, e depois a 90%, depois a 95%, depois eventualmente a 100%. E o que pensamos que é muito tempo é na verdade apenas uns 5 minutos. Em contraste com quanto tempo levaria um ser humano para fazer o mesmo, que seria algo como 5 horas — humanos tendem a ser mais precisos no primeiro go, mas não em um ou dois minutos. Então sempre deve haver um loop de tarefa, executar a tarefa, verificar os resultados, e estará tudo bem.

## DESENVOLVIMENTO PARALELO E MÚLTIPLAS INSTÂNCIAS 21:42

Uma das capacidades mais poderosas do Claude Code é executar múltiplas instâncias em paralelo. Em vez de esperar que uma instância termine antes de iniciar outra, é possível ter três, quatro, cinco ou mais instâncias trabalhando simultaneamente em projetos diferentes.

Para demonstrar isso, ao mesmo tempo em que uma instância está construindo um site a partir de um screenshot de referência, uma segunda instância é aberta com um screenshot completamente diferente. O computador começa a trabalhar bem nesse ponto — dois processos de desenvolvimento de site rodando ao mesmo tempo, consumindo recursos, mas produzindo dois resultados em paralelo.

Como o Claude Code pode ser executado em quantas instâncias forem suportadas pelos tokens disponíveis, é possível ter quantas abas se queira de designers de website rodando simultaneamente. E essa nem é a forma mais eficiente — há uma estrutura de gerenciamento de terminal muito mais eficaz que permite fazer cinco, dez ou vinte dessas simultaneamente.

O número ideal de instâncias paralelas depende da intensidade intelectual das tarefas e da capacidade de fazer o malabarismo mental. A regra prática: se o Claude Code está esperando por mais instruções por mais de 10 a 20% do tempo, provavelmente há abas demais abertas. Pessoalmente, o limite é em torno de três ou quatro instâncias simultâneas.

Uma dica muito prática para gerenciar múltiplas instâncias: configurar um hook que toca um som de notificação quando uma instância termina. É possível definir sons diferentes para diferentes janelas. Quando o som 1 toca, sabe-se que a janela do canto superior esquerdo terminou — vai-se lá dar mais instruções e olhar os resultados. Quando o som 2 toca, vai-se à janela do canto superior direito e trabalha-se lá. Isso será coberto em detalhes no módulo de hooks.

Quando um website está pronto, basta dizer “abrir index.html” e o Claude vai abrir o arquivo no navegador. A qualidade resultante pode não ser perfeita — às vezes há problemas como fotos cortadas ou texto mal posicionado — mas como ponto de partida para refinamento iterativo, é impressionante considerando que levou apenas alguns minutos.

Para personalizar o site com conteúdo real, basta usar uma ferramenta de transcrição de voz para fazer um despejo de tudo que se quer mudar. Comentários sobre o logo, tipografia, botões, fotos — tudo em linguagem natural. O Claude interpreta e implementa. Por exemplo, dizer que o logo está muito grande, que a fonte do hero header está muito pesada, pedir uma fonte com serifa, que as fotos estão cortadas e precisam ser centralizadas, que o copyright precisa ser atualizado — tudo isso em um único bloco de voz.

## O DIRETÓRIO .CLAUDE — ESTRUTURA E FUNCIONALIDADES AVANÇADAS 24:15

Agora que foi feita uma construção inicial com o Claude Code e foram produzidos websites razoavelmente sólidos com apenas alguns minutos de trabalho, é hora de mergulhar mais fundo na funcionalidade avançada do Claude Code. O que será abordado aqui provavelmente menos de 10% dos usuários atuais do Claude Code entendem. Ao desbloquear o que está prestes a ser ensinado neste módulo, se terá um conhecimento significativamente maior sobre o Claude Code e também se poderá combinar cada uma dessas funcionalidades diferentes de maneiras fantásticas que trarão valor rapidamente.

Então o que é o diretório .claude? Para qualquer pessoa sem background técnico, em convenção de programação, uma pasta com um ponto na frente é basicamente uma pasta oculta. Se você abrir o explorador de arquivos, não a verá. Por exemplo, no Mac, a pasta do usuário pode ter subpastas como Documents — mas se houver uma pasta chamada “.oculta”, o explorador de arquivos não a mostraria. É a maneira dos desenvolvedores de criar pastas que não bagunçam a organização visual.

No caso do Claude Code, há um diretório com letra minúscula `.claude`. Dentro desse diretório, há suporte para cerca de 10 a 15 funcionalidades avançadas legais que, uma vez conhecidas, permitem aumentar significativamente o Claude Code além da versão básica.

Vejamos como se parece um diretório `.claude` totalmente configurado. Dentro da pasta `.claude` é possível adicionar:

`settings.json` — permissões de equipe e hooks. Os hooks são como aquele som de notificação que foi mencionado antes — é assim que se consegue aquele barulho de sino no final de cada execução.

`settings.local.json` — qualquer arquivo com “.local” no nome fica local no computador em vez de ser enviado a um repositório online. Muitos programadores e usuários do Claude Code usam o GitHub para armazenar todos os seus projetos ativos. Como o GitHub é um serviço em nuvem, há casos em que não se quer que o serviço em nuvem tenha acesso aos dados, particularmente se forem sensíveis, como tokens e chaves de autenticação. A convenção é usar “.local” para evitar enviar ao GitHub.

`CLAUDE.md` — onde o arquivo principal de instruções fica, e também `CLAUDE.local.md`, que é a versão local não versionada.

Pasta `agents/` — subagentes especializados.

Pasta `skills/` — automações de tarefas.

Pasta `rules/` — regras segmentadas.

E finalmente `.mcp.json` — configuração do Model Context Protocol.

Para alguém chegando sem background técnico, isso pode parecer louco. settings.json, settings.local.json, por que CLAUDE está em maiúsculas, o que significa MD? Isso tudo será explicado. Por agora, apenas saiba que esses são basicamente os vários botões que a Anthropic, os desenvolvedores do Claude Code, deram para customizar a própria instância. Cada um desses arquivos pode ser customizado ao grau desejado. Alguns arquivos referenciam outros arquivos. É possível co-desenvolver todas essas configurações com o próprio Claude, pois a maioria das pessoas não desenvolve essas coisas por conta própria.

Agora há dois níveis para isso. O que foi discutido — a pasta `.claude` — fica dentro do diretório do workspace, no projeto em que se está trabalhando. Mas existe também um nível ainda mais alto: o diretório global `~/.claude/`. O til no início indica a pasta home do computador — não a pasta home do workspace específico. O Claude Code permite definir configurações que são tanto locais (específicas para o workspace atual) quanto globais (compartilhadas entre todos os workspaces). Assim, além de poder ter um claude.md no nível local para um projeto específico, há também a possibilidade de ter claude.mds e rules de alto nível que se aplicam a todos os projetos.

Para resumir, há três camadas de claude.md que se combinam: o global pessoal em `~/.claude/CLAUDE.md`, o do projeto em `.claude/CLAUDE.md` dentro do workspace atual, e o nível enterprise para licenças corporativas. Praticamente 99,9% das pessoas não terão licenças enterprise. O conceito é o mesmo — apenas mais um arquivo Markdown que existe em um nível diferente de precedência.

## A PASTA RULES — SEGMENTANDO O CLAUDE.MD 27:11

A pasta `rules/` dentro do `.claude` permite dividir um claude.md monolítico em diferentes arquivos de regras separados. Em vez de ter tudo em um único arquivo, é possível definir regras de alto nível que correspondem a diferentes partes de um build.

Por exemplo, pode-se ter uma regra para estilo de código, uma para testes, uma para segurança, uma para frontend, e dentro do frontend uma para React e outra para estilos. A regra de estilo de código pode ser um parágrafo simples sobre como organizar o código. A segurança pode ser alguns parágrafos sobre como proteger as bases de código. Os estilos podem ser uma lista de classes Tailwind CSS ou instruções de formatação para deixar websites com uma aparência específica.

Para converter um claude.md existente em rules segmentadas, basta dizer ao Claude Code: “divida o claude.md em suas regras componentes, usando a especificação de rules do Claude Code”. O Claude vai ler o arquivo atual, pesquisar a especificação de rules se não souber, e dividir o arquivo em três ou mais arquivos de rules dentro da pasta rules. Por exemplo, pode criar `workflow.md`, `tech-defaults.md` e `design.md` como regras separadas.

O valor disso vai além da organização. É possível evoluir o workflow sem tocar as regras de design. Em geral, essa forma de segmentação pode ser muito útil especialmente quando se está trabalhando com outras pessoas — é possível dar acesso às pessoas apenas para os estilos, enquanto se mantém controle total sobre o workflow de alto nível. Também ajuda quando o claude.md é muito longo — muitas pessoas têm claude.mds com milhares de palavras. Dividi-lo assim ajuda a manter a organização e a ver áreas que não são mais necessárias.

## BOAS PRÁTICAS PARA O CLAUDE.MD — O QUE FAZER E O QUE EVITAR 28:20

Para simplificar, as principais recomendações compiladas para o claude.md são as seguintes:

O que fazer: primeiro, executar `/init` ao trabalhar em uma nova pasta pela primeira vez. Segundo, usar bullet points e títulos curtos e tentar comprimir a informação ao máximo — escrever em estilo de alta densidade informacional. Não despejar transcrições de voz no claude.md. Se quiser escrever um claude.md usando ajuda, é recomendável fazer o despejo de voz para o Claude e então pedir que converta em um resumo muito compacto e de alta densidade de regras. Terceiro, colocar as coisas mais importantes no topo. Se há algo que absolutamente não deve ser feito — nunca deletar arquivo X, por exemplo — mencioná-lo bem no começo.

Os primeiros itens que a IA aprende tendem a ser lembrados. Há o que se chama de “viés de primazia” — tanto os seres humanos quanto a IA se lembram muito do início, não se lembram tanto do meio, e são mais propensos a lembrar de alguma coisa do final. Isso se chama “viés de recência”. Então o Claude e nós somos tendenciosos a lembrar de coisas bem no começo de uma sequência e no final da sequência, mas principalmente no começo, motivo pelo qual se coloca guardrails importantes no topo.

Periodicamente revisar e poddar o claude.md, tratando-o como código técnico vivo. Se o Claude atualizar constantemente o claude.md, perceberá que com o tempo ele adiciona coisas que não são super necessárias, instruções muito precisas, começa a mudar a forma como fala com o usuário. Tratar isso como dívida técnica e reduzi-la ao longo do tempo.

O que não fazer: não despejar guias de estilo e documentações de API completas nele. Esse é um hábito infeliz que muitas pessoas têm — querem que o Claude seja um companheiro para determinada ferramenta, então pegam toda a API da ferramenta e tentam colar no claude.md. Isso acaba sendo 10.000 tokens e, como esse arquivo é inicializado toda vez que o Claude Code é executado, além de demorar um pouco mais por causa do tempo de inicialização, também é mais custoso e reduz a qualidade do Claude. Em vez disso, falar com o Claude: “quais endpoints específicos de API vamos precisar?” e então dar apenas as seções específicas necessárias.

O claude.md permite o que se chama de @include. Se no claude.md houver uma referência como `@git.md` e houver um arquivo chamado `git.md` em outro lugar no computador, ele vai realmente incluir aquele arquivo no claude.md. Essa funcionalidade é meio gerenciada pelas rules, mas não inclua um monte de arquivos a menos que seja absolutamente necessário.

Não escrever regras muito vagas em geral. Tratar o Claude como uma inteligência extraordinária mas focada em um nicho muito específico. Se for dada corda demais, ele vai se enforcar. Não escrever coisas genéricas e aspiracionais a menos que faça sentido. Por exemplo, não dizer “seja esperto”, não dizer “não cometa erros” — o Claude não vai entender isso de uma forma que melhore seus outputs.

Manter o claude.md entre 200 e 500 linhas no máximo. Mais do que 500 linhas, está se despejando muito contexto. E não esquecer de adicionar rules quando o Claude continua cometendo o mesmo erro. Se estiver trabalhando com uma biblioteca ou plataforma específica que tem uma forma muito particular de fazer as coisas, toda vez que carregar uma instância nova do Claude Code, ele vai continuar cometendo aquele erro. Se ele errar mais de duas ou três vezes, dizer “adicione isso ao seu claude.md para que funcione na próxima vez que abrir uma instância nova do Claude”. Essa é uma das estratégias favoritas.

## AUTO MEMORY E O COMANDO /INIT 31:23

Além do claude.md, existe também o conceito de memória automática. Em adição ao claude.md, há um pequeno arquivo adicional que é injetado no topo de cada sessão. A Anthropic e os desenvolvedores do Claude Code fazem muito dessas injeções — não é apenas o claude.md. É o arquivo de memória também, além de muitas definições de tool calls e muita coisa a mais.

A forma como a memória funciona é: se contar ao Claude algo em uma instância e pedir que ele lembre, ele vai escrever isso em um arquivo de memória. Em outra instância, ao abri-la, esse é um arquivo de memória global, e ele vai lembrar. Por exemplo, se abrir o Claude Code e perguntar “qual é o nome do meu irmão?” — se nunca tiver dito isso ao Claude — ele vai dizer que não sabe. Mas se disser “lembre que o nome do meu irmão é Jorge”, o que ele vai fazer é salvar isso no arquivo de memória. E se ir a uma instância nova do Claude Code e perguntar “qual é o nome do meu irmão?”, desta vez ele vai responder “Jorge” — porque o arquivo de memória foi injetado.

Na prática, a memória não é super valiosa isoladamente — o claude.md já faz muito disso. Mas é separada do claude.md. Pode-se tratá-la como as anotações pessoais do Claude — não é bem o conjunto de instruções. É uma coisa ligeiramente diferente.

O comando `/init` é extremamente valioso quando se está trabalhando em um projeto novo sem um claude.md existente. Basta abrir a pasta do projeto, abrir o Claude Code, digitar `/init`, e o Claude vai analisar toda a base de código atual, resumir o que ela faz e dar instruções para uma versão futura do Claude. Isso é feito diretamente na raiz do workspace — não dentro de uma pasta `.claude` — mas a organização pode ser feita manualmente depois.

Por que isso é valioso se o Claude tecnicamente já tem acesso a todos os arquivos? Porque de outra forma, toda vez que uma sessão for iniciada, o Claude teria que ler todos os arquivos do zero — o contact.html, o index.html, o message.md, tudo. Em vez de consumir, digamos, 10.000 tokens por vez, estaria consumindo 100.000 porque teve que ler tudo. E duas coisas acontecem: primeiro, a qualidade do Claude em média cai porque há uma relação negativa entre o comprimento do prompt e a qualidade dos outputs. Segundo, está se pagando muito mais. O claude.md criado pelo `/init`, em adição a fornecer instruções e orientação, também é um mecanismo pelo qual se pode reduzir significativamente o uso de tokens e aumentar a qualidade média — porque ele simplesmente já sabe tudo, especialmente ao usar o `/init` antes de realmente ter que ler os arquivos.

## MODOS DE PERMISSÃO — CONTROLE DETALHADO DE ACESSO 32:55

Os modos de permissão controlam como os agentes lidam com permissões. O modo de permissão atual é também passado para quaisquer subagentes que forem criados. Eles tendem a herdar o contexto de permissão da conversa principal, mas há situações em que é possível substituir o modo também.

O modo padrão — “ask before edits” ou “default” — é a verificação de permissão padrão com prompts. Antes de o Claude fazer qualquer mudança em qualquer arquivo no computador, ele tem que perguntar se é aceitável. Esse modo é útil em projetos de alto risco onde cada mudança precisa ser validada.

Ao tentar mudar o título de um projeto com “ask before edits” ativo, o que acontece é que primeiro ele olha para o arquivo específico que define o título, abre no lado direito da tela a seção exata da página que está considerando atualizar, e mostra exatamente o que vai mudar. Aparece uma mensagem perguntando se deve fazer esta edição ao arquivo específico, com três opções: sim, pressionar um; sim, permitir todas as edições desta sessão, pressionar dois; ou não, pressionar três. Essa interrupção constante pode ser muito chata quando o Claude está no meio de um trabalho intenso.

O próximo modo principal é “accept edits” ou “edit automatically”. Nesse modo, qualquer edição a arquivos pré-existentes é automaticamente aceita, mas se quiser criar novos arquivos, ainda vai pedir confirmação. Isso é útil quando se quer dar ao modelo carta branca sobre qualquer arquivo pré-existente, mas não se quer que ele tenha controle ou capacidade de criar novos.

O próximo é “bypass permissions” — que não está disponível por padrão na primeira instalação. Para configurá-lo, é necessário ir às configurações da extensão do Claude Code no VS Code ou Cursor, encontrar “Claude Code allow dangerously skip permissions” e ativar a opção. Vale notar: eles recomendam isso apenas para sandboxes sem acesso à internet. O bypass de permissões permite ao Claude fazer qualquer coisa — criar arquivos, editar, deletar. Há um risco real: houve um caso documentado em que alguém estava rodando o Claude Code em modo bypass e, por uma má interpretação de uma solicitação, ele executou um comando que deletou todos os dados do disco rígido. São coisas possíveis, embora raríssimas. Na prática, isso ocorre em uma porcentagem infinitesimalmente pequena das vezes. O principal risco prático no dia a dia é simplesmente acumular arquivos temporários desnecessários que incham o workspace ao longo do tempo.

O plan mode é o modo de exploração somente leitura — o Claude Code pode pesquisar usando ferramentas web, ler arquivos pré-existentes, raciocinar a partir de primeiros princípios e usar sua própria inteligência. Então pode pegar tudo isso e colocar em um documento de plano antes de apresentá-lo. O plan mode é incrível e é usado em praticamente qualquer build mais complexo do que um design simples.

O modo “Delegate” é um modo de coordenação para líderes de equipes de agentes. O Claude Code tem um recurso chamado “agent teams” onde um único agente pode delegar trabalho a vários subagentes. Esse é o modo de permissão dado ao líder da equipe de agentes, que basicamente lhe permite delegar tarefas, embora não seja permitido fazer nada além das ferramentas de gerenciamento de equipe.

## PLAN MODE — POR QUE PLANEJAR ANTES DE CONSTRUIR 35:20

O plan mode vai fazer a maior parte do que será discutido a seguir. O plan mode é exploração somente leitura — o Claude Code pode pesquisar coisas usando ferramentas web, ler todos os arquivos pré-existentes no diretório, raciocinar a partir de primeiros princípios e usar sua própria inteligência. E então pode basicamente pegar tudo isso e colocar em um documento de plano antes de apresentá-lo.

O plan mode é fantástico. É usado praticamente toda vez que há qualquer tipo de build mais complicado do que um design simples. O motivo pelo qual é tão bom é que, em vez de agir — o que no mundo real leva muito tempo e energia tanto para fazer quanto para desfazer —, o plan mode apenas pesquisa todos os fatores envolvidos no build antes de fazê-lo. Se trabalhar nesse espaço teórico de planejamento em vez do espaço real do build e de todas as bibliotecas e todo o código, serão poupadas muitas, muitas horas de construção ao longo de apenas alguns dias, e provavelmente dezenas e centenas de horas ao longo de uma vida de uso dessa ferramenta. Um minuto de planejamento poupa dez minutos de construção. É simplesmente muito alavancado.

Imagine dois possíveis cenários. No primeiro cenário, constrói-se algo com o Claude Code, testa-se e percebe-se que há algum problema com a abordagem. Talvez esteja se construindo um app web simples que, ao fazer login, adiciona números ou credenciais a um banco de dados. Fez-se isso, percebeu-se que está errado. O que isso significa é que, porque a abordagem está errada, basicamente o tempo gasto construindo — embora não completamente desperdiçado — uma grande parte dele foi desperdiçada. Não só foram gastos os 15 minutos para construir a coisa, não só os 5 minutos para testar, mas também é preciso reconstruir, o que pode levar mais 15 minutos multiplicado por quantas vezes for necessário testar e retestar. Isso significa que o tempo total gasto é de 35 minutos mais uma quantidade considerável de tokens.

No segundo cenário — construção com plan — gasta-se os primeiros cinco minutos apenas planejando algo super detalhado com o plan mode do Claude Code. Em algum momento durante o planejamento, porque está sendo construído um escopo muito granular e detalhado, e todos os objetos estão sendo examinados, o Claude Code percebe que não vai funcionar a meio caminho e então apenas recria um plano melhor que funciona. O tempo total para chegar à construção é apenas cinco minutos mais cinco minutos, dez minutos. E então talvez o tempo real de construção, porque é muito melhor e mais rápido, seja apenas cinco a quinze minutos. Então não só se pouparam 20 minutos em uma única construção, mas também com significativamente menos tokens.

O que isso significa é que é muito melhor fazer todo o trabalho aqui — basicamente durante o planejamento da especificação. É como planejar um projeto de construção: planeja-se projetos de construção para não se chegar a uma situação em que não há materiais suficientes no canteiro de obras e tudo tem que ser parado para ir buscar mais. Melhor ir à planta e fazer as mudanças lá do que no mundo físico, onde incorrem custos reais.

## CONSTRUINDO UMA PLATAFORMA COMPLETA DE GERAÇÃO DE PROPOSTAS 38:12

O projeto prático para demonstrar o plan mode é uma plataforma de geração de propostas — basicamente reconstruindo o PandaDoc do zero. O objetivo é ser capaz de gerar automaticamente propostas de alta qualidade — documentos de vendas — que podem ser enviados a prospectos através de uma interface web. O sistema precisa ter: geração de propostas por IA, propostas como páginas estáticas públicas, login, dashboard para gerenciar propostas, templates baseados em um PDF existente, capacidade para os clientes assinarem eletronicamente, capacidade de pagamento integrado, e um design limpo estilo Apple.

O primeiro passo é criar a especificação do projeto. Em vez de tentar especificar tecnicamente, basta descrever o que se quer. Usando uma ferramenta de transcrição de voz, pode-se fazer um despejo de tudo que se quer no app. Então essa transcrição é colada no Claude Code em plan mode.

Ao receber a especificação em linguagem natural, o Claude Code começa a fazer perguntas de esclarecimento através de uma interface gráfica interativa: qual framework de frontend você quer usar? Quão legalmente robusto precisam ser as assinaturas eletrônicas? As propostas têm preços fixos ou variáveis? Está usando Supabase para o banco de dados? Tailwind para CSS utilitário, Shadcn UI para componentes polidos? Onde está o template de proposta?

Após fornecer um template de proposta em PDF, o Claude analisa o documento de nove páginas e gera um plano de implementação detalhado. O plano inclui: visão geral do produto, stack tecnológico completo, seções do template de proposta, esquema do banco de dados, rotas e endpoints de API, estrutura de arquivos do projeto, e fluxo de usuário completo.

Com o plano aprovado, muda-se para o modo bypass permissions e se fornece as chaves necessárias: credenciais do Supabase (URL do projeto e chave anônima), chaves da API do Stripe (pública e privada para o ambiente de testes sandbox). Enquanto o Claude está construindo, é possível configurar o Supabase: criar um projeto novo, copiar as chaves de API, executar as migrations SQL no editor SQL do Supabase.

Após as credenciais serem fornecidas, o Claude Code constrói todo o sistema: autenticação de usuários, dashboard, formulário de criação de propostas, geração via IA, páginas públicas de proposta com layout baseado no PDF de template, assinatura eletrônica via canvas, integração com Stripe para pagamentos. O processo todo de build leva aproximadamente 15 a 20 minutos com intervenção mínima do usuário.

O resultado final é um app completo com login, dashboard, geração de propostas, visualização pública, assinatura e pagamento — funcionalidade equivalente ao PandaDoc, construída em menos de meia hora e hospedada de graça no Netlify. Para deploy, basta abrir o Netlify, importar o projeto do GitHub, configurar as variáveis de ambiente (copiadas do arquivo .env local) e configurar o webhook do Stripe. O app fica online e acessível publicamente em poucos minutos.

## SEGURANÇA EM APLICAÇÕES DESENVOLVIDAS COM CLAUDE CODE 40:24

Com grande poder vem grande responsabilidade. Apesar de quão incrível o Claude Code é no momento, seria muito cauteloso em publicar apps completamente “vibe coded” na internet. Existem pessoas que estão usando o Claude Code e ferramentas similares para tentar encontrar vulnerabilidades de segurança também. E infelizmente, apesar de quão incrível o Claude Code é agora, ele não está no ponto em que garante 100% a segurança de tudo no frontend e no backend.

Então há algumas precauções de segurança recomendadas:

Primeiro, que a URL não seja óbvia ou básica. Não usar algo trivial como um subdomínio simples. Há serviços que escaneiam todas as faixas de DNS e todas as URLs, o que significa que quanto mais curta e simples a URL, mais arriscado é, pois mais outras pessoas terão acesso. Provavelmente já houve 30 ou 40 pessoas que acessaram o serviço de exemplo logo depois de ser criado — é simplesmente assim que funciona.

Segundo, não cobrar dinheiro sem ter um desenvolvedor revisando pelo menos o frontend de autenticação uma vez. Isso é dito por razões de responsabilidade. Não vale pegar dados de usuários — nomes de usuário, senhas, endereços de email, logs de pagamento — e ter isso exposto a atores mal-intencionados na internet. Se quiserem lançar apps com essa abordagem, vale pagar algumas centenas de dólares para alguém revisar o app. O software em si não é o diferencial competitivo de qualquer maneira, então pode-se simplesmente entregar para revisão e pedir dicas de segurança. Ou que o revisor use até o próprio Claude Code para fazer isso quase automaticamente.

O uso mais seguro e recomendado é para ferramentas internas dentro de equipes ou para clientes em contextos controlados. Não publicar essas coisas e tentar monetizá-las da internet em geral. Foram vistas histórias de horror demais com segurança em projetos vibe coded que ficaram expostos publicamente.

## GERENCIAMENTO DE CONTEXTO — ENTENDENDO A JANELA DE CONTEXTO 41:21

O gerenciamento de contexto é essencialmente como lidar com tokens em um prompt da forma mais eficaz possível. Muitas pessoas complicam isso excessivamente, então será mantido o mais simples possível.

Se abrir uma nova instância do Claude Code e digitar `/context`, e então rolar para cima e dar um zoom, o Claude dirá essencialmente o que está usando atualmente a janela de contexto. Para quem não sabe, janela de contexto no domínio da IA simplesmente se refere à quantidade total ou número total de tokens que um modelo específico pode lidar de uma vez.

Por exemplo, com o Claude Opus 4.6 — o modelo mais avançado disponível —, a janela de contexto é de cerca de 200.000 tokens. Existem modelos como algumas versões da série Sonnet que podem chegar a um ou dois milhões de tokens. Mas o número de tokens em uma janela de contexto não está diretamente relacionado ao desempenho do modelo. A janela de contexto é algo separado disso.

Ao executar `/context`, pode-se ver que com apenas o comando `/context` já foram usados 26.400 tokens. A pergunta natural é: de onde vieram todos esses tokens? A resposta aparece logo abaixo.

Imediatamente abaixo na categorização, é possível ver todas as diferentes formas como os tokens estão sendo usados. O primeiro é o system prompt — o claude.md. Há o global `~/.claude` que define todos os workspaces, não apenas o atual. Depois há o `.claude` local do projeto. Há também o arquivo de memória `MEMORY.md`. E somente então se envia a mensagem real.

Então antes de ter enviado qualquer mensagem, provavelmente uns 10.000 tokens já foram consumidos por todos esses system prompts. E apenas uns dois ou três tokens foram consumidos pela solicitação real.

Mas onde estão os outros 15.000 tokens dos 26.400? Além do system prompt (que inclui o claude.md e as rules), também há “system tools” — que no momento desta gravação são quase 17.000 tokens. As system tools são coisas como a capacidade do modelo de executar bash (abrir um terminal), a capacidade de fazer web search (buscar uma página web e retornar as informações), a capacidade de criar um plano. Essas são ferramentas e funções que o usuário não percebe que o Claude tem acesso, mas tem. E isso é o que os desenvolvedores do Claude Code — Boris Cherny e toda a equipe — basicamente fizeram: antes mesmo de chegar à mensagem do usuário, há todas essas ferramentas listadas.

Essas ferramentas estão constantemente mudando. Se quiser uma lista de todas elas, basta perguntar ao modelo: “quais ferramentas você tem acesso? Liste todas”. Ele vai enumerar cada uma. Por exemplo: `task` (o que abre cada vez que se chama um subagente), `task_output` (para recuperar o output do agente), `bash` (como executar comandos de shell), `glob` (encontrar arquivo por padrão), `grep` (buscar conteúdo de arquivos), `read` (como lê arquivos), `edit` (como faz mudanças), `write` (como cria e sobrescreve novos arquivos), `notebook_edit` (para Jupyter notebooks, muito usado em ciência de dados), `webfetch` (como chama várias fontes de internet), `websearch` (permite buscar como o Google), `todo_write` (de onde vêm aquelas listas de tarefas quando o Claude Code está trabalhando), `ask_user_question` (de onde vêm aquelas interfaces de “escolha uma opção”), `enter_plan_mode`, `exit_plan_mode`, `skill` (função meta que orquestra como se chama skills), `task_stop` (para parar algo que está rodando).

De todo o contexto, 16.800 tokens são consumidos por todas essas ferramentas constantemente. E não há nada que se possa fazer para corrigir isso a menos que se queira criar uma versão própria do Claude Code. O time do Claude Code está constantemente melhorando, podando e assim por diante.

## MCP TOOLS, MEMÓRIA E ESTRATÉGIAS DE COMPACTAÇÃO 44:23

Em seguida no `/context` estão as MCP tools. Diferente das system tools — que são padrão —, as MCP tools são coisas que o usuário mesmo define. Cada uma dessas ferramentas é algo que se conectou a um servidor MCP para estender a funcionalidade do Claude Code. Basicamente, as system tools são padrão, e as MCP tools são controláveis pelo usuário.

Como porcentagem do contexto total, talvez 2,8% seja gasto em customizar a própria instância do Claude e 8,4% com as ferramentas padrão. Obviamente as padrão são maiores. Mas alguns MCPs podem ser bem volumosos. Há que se ser seletivo na escolha deles. É importante selecionar servidores MCP que não consumam excessivamente o contexto.

Em seguida estão os arquivos de memória. O arquivo `MEMORY.md` é muito direto, e no contexto típico são apenas 88 tokens — nem de longe um problema. É basicamente o bloco de rascunho do Claude enquanto trabalha.

Depois estão as skills. Se houver uma pasta de skills do Claude em outro repo, o arquivo de skills carrega basicamente apenas a definição de skills, que no exemplo típico são 61 tokens — expressos como fração dos 200.000 tokens disponíveis, isso é menos de 0,1%. Por que as skills consomem tão poucos tokens em relação a tudo mais? Porque a skill inteira não é realmente carregada no contexto. A única seção carregada é o que em Markdown é chamado de “front matter” — um pequeno cabeçalho no início do arquivo. O que é realmente legal é que os desenvolvedores do Claude Code perceberam que poderiam carregar apenas um nome, descrição e ferramentas permitidas no front matter, e então somente se o Claude realmente achar que precisa usar aquela skill — ou se especificamente for dito “use o arquivo de scrape leads” — é que vai de fato carregar tudo. Isso significa que se obtém a maioria dos benefícios de ter acesso a várias ferramentas e dar ao agente a capacidade de fazer várias coisas, mas sem ter que carregar tudo no contexto imediatamente.

E então finalmente vêm as mensagens reais — a conversa em si. Consumindo talvez 2,6% da janela de contexto total apenas através de mensagens e vai-e-vem.

O buffer de auto-compact é um espaço reservado pelos desenvolvedores do Claude Code. Quando se atinge esse buffer — quando restam apenas 33.000 tokens — automaticamente compacta todo o histórico anterior de conversa. Isso também pode ser feito manualmente usando `/compact`. O que acontece com `/compact` é que ele pega todo o histórico de conversa, seja o que for, e simprime em um resumo de altíssima densidade informacional.

Após compactar, pode-se pedir ao Claude para contar o que ele acabou de compactar, e ele vai dizer: “esta sessão está sendo continuada a partir de uma conversa anterior que ficou sem contexto. O resumo abaixo cobre a parte anterior da conversa”. Ele vai ter uma aba de análise onde cronologicamente analisa a conversa e a resume de forma mais compacta. Isso vai ser significativamente menos tokens do que o original — provavelmente três ou quatro vezes menor. E assim, a compactação gradual e progressiva de uma conversa maximiza a densidade de informação.

A auto-compactação está sendo implementada de forma cada vez mais proativa pelo time do Claude Code — os tokens mais antigos são constantemente comprimidos em resumos de maior densidade informacional em segundo plano. Isso é bastante impressionante porque os humanos simplesmente não são muito bons em permanecer realmente concisos, e isso melhora constantemente a qualidade dos outputs subsequentes, além de custar menos — o que é curioso, porque o modelo de negócio da Anthropic é monetizar o Claude. O fato de estarem fazendo isso de certa forma vai contra seus interesses diretos, o que é um dos motivos pelos quais a empresa é valorizada — claramente motivados pela qualidade do produto mais do que pela receita imediata.

## DICAS AVANÇADAS DE GERENCIAMENTO DE CONTEXTO 47:33

A documentação do Claude Code tem uma seção dedicada a reduzir o uso de tokens e minimizar o que é chamado de “context rot” — degradação do contexto — que se acumula em uma conversa. As principais estratégias são as seguintes:

Usar `/cost` para verificar o uso atual de tokens. Também é possível configurar uma linha de status para exibir isso continuamente. Para configurar a linha de status no Claude Code, usar `/status-line` no terminal (não disponível na versão GUI). Ao executar esse comando, será perguntado o que se quer exibir na linha de status. Uma boa opção é pedir uma barra de carregamento mostrando quantos tokens foram usados do contexto total.

Adicionar instruções customizadas de compactação. Usando `/compact` com um prompt, é possível dizer ao Claude o que priorizar na compactação, o que pode ser muito valioso.

Usar `/clear` para começar do zero ao mudar para algo não relacionado. Se estava trabalhando em uma coisa e agora quer falar sobre algo completamente diferente, limpar o contexto é muito mais eficiente.

Usar instruções no claude.md para minimizar o número total de tokens gerados. Dizer algo como: “escreva o mais sucintamente possível; raciocine o quanto quiser porque isso não é adicionado ao contexto, mas quando me der alguma coisa, me dê apenas as informações essenciais; se precisar de mais, pedirei explicitamente”.

Escolher o modelo certo. Para tarefas simples com subagentes, usar modelos menores como Sonnet. Esses modelos menores são tipicamente menos inteligentes, mas têm janelas de contexto maiores e custam menos. Isso permite fazer todo o trabalho pesado dentro do subagente que é mais barato, e então retornar apenas os resultados.

Reduzir overhead de MCP server. Como mencionado, alguns servidores MCP são muito ruins — têm um número enorme de ferramentas. Ao baixar um, 20% do uso de tokens pode sumir imediatamente. Isso é obviamente muito custoso. O Claude Code tem algo chamado “advanced and automatic tool search”: quando as descrições de ferramentas MCP excedem 10% da janela de contexto, ele não carrega todas elas. Apenas busca por elas primeiro antes de usar. Isso ajuda a evitar overheads massivos de servidores MCP e economizar tokens.

Mover instruções do claude.md para skills. Lembrar que o claude.md deve ter entre 200 e 500 linhas no máximo. Qualquer coisa mais longa, e instruções que são mais tarefas do que regras podem ser transformadas em skills. As skills carregam sob demanda, o que significa que somente quando especificamente invocadas é que serão adicionadas ao contexto.

Ajustar o thinking estendido. Ao usar `/model`, é possível ajustar o nível de esforço do thinking — desativar completamente ou aumentar o número de tokens que tem para pensar. Como mencionado, o thinking não é incluído nas mensagens. Ele offload o raciocínio para uma área separada.

Escrever prompts específicos é provavelmente a dica de maior ROI. Em vez de “melhore este código”, algo como “corrija essa funcionalidade específica que encontrei neste arquivo” é muito mais preciso e resulta em uso significativamente menor de tokens.

Por fim, planejamento para tarefas complexas reduz significativamente o número total de tokens usados. Chamadas de API, servidores e páginas web carregam muitos tokens no contexto. Evitar fazer pesquisa na fase de build é muito valioso — front-load a pesquisa com plan mode e preocupar-se com o restante depois.

## SKILLS — A FERRAMENTA DE MAIOR VALOR ECONÔMICO DO CLAUDE CODE 49:20

As skills — anteriormente referidas como “custom slash commands” — são provavelmente uma das formas economicamente mais valiosas de usar o Claude Code. Uma skill é como um documento de POP (Procedimento Operacional Padrão) — uma lista estruturada de instruções em formato Markdown que transforma o Claude Code em um especialista para uma tarefa específica e repetitiva.

Se abrirmos o diretório `.claude` em um workspace bem configurado, é possível ver uma pasta de skills aninhada. Pode-se ter skills para: classificar leads, criar propostas automaticamente, encontrar outliers em um nicho, atualizar e responder automaticamente emails, editar vídeos do YouTube, fazer onboarding de novos clientes na agência, se candidatar a vagas no Upwork, monitorar e classificar posts em comunidades online.

O que essa coleção representa é basicamente todas as coisas que se faz normalmente no dia a dia como parte do trabalho de conhecimento intelectualmente valioso, o que efetivamente gera renda. E o que se fez foi transformar tudo isso em checklists e dar esses checklists ao Claude.

Para demonstrar, a skill “scrape-leads” faz o seguinte: ela raspa e verifica leads de negócios usando um serviço, depois classifica com um modelo de linguagem, enriquece os emails e salva em uma planilha Google. É usada quando o usuário pede para encontrar leads, raspar negócios, gerar listas de prospectos ou construir bancos de dados de leads para qualquer indústria ou localização.

A skill tem um objetivo no topo, uma série de inputs, alguns scripts que podem ser usados, e então um processo. Esse processo é uma checklist: começar com um teste de 25 leads, depois fazer verificação, depois um scrape completo, depois classificação com LLM, upload para a planilha Google, enriquecimento de emails faltantes, e assim por diante.

Isso é uma quantidade significativa de tempo e energia que antes levava de uma a duas horas. Lead scraping é uma parte enorme do que torna uma campanha de cold email bem-sucedida, e tinha que ser feito manualmente. Agora, basta transformar todo o conhecimento em uma skill, defini-la em formato Markdown e escrever com a ajuda do Claude. E então pode-se dizer simplesmente “raspe 1000 dentistas nos Estados Unidos”. Quando se pressiona enter, o que acontece é que a skill é carregada com sucesso, e começa com um teste de 25 leads para verificar a qualidade. Automaticamente encontra os diferentes filtros a usar.

Depois disso, como diz a especificação da skill, ele vai ler cada um dos 25 leads, às vezes fazer um pouco de pesquisa básica para verificar se são leads do tipo desejado. Se sim, prossegue com um scrape completo em paralelo de 1000 leads simultaneamente, o que ocorre muito rapidamente. Foram iniciados quatro scrapers ao mesmo tempo, e se obtém 250 de cada um.

No caso do curso, isso antes teria levado 15 a 20 minutos apenas para configurar os filtros e configurar a busca inicial. Depois, mais 10 ou 15 minutos para verificar manualmente os 25. Depois, iniciar o scraper real, depois fazer upload para a planilha Google, depois fazer referência cruzada dos leads, depois executar alguns fluxos adicionais baseados em IA. Um processo que levava pelo menos meia hora agora é feito em 87 segundos.

Para quem usa fast mode — o novo modelo Opus 4.6 com capacidade de rodar 2,5 vezes mais rápido por cerca de três vezes o preço — é possível pagar um pouco mais se isso significar fazer todo o trabalho de conhecimento necessário um pouco mais rapidamente.

## ESTRUTURA DE UMA SKILL — COMO CRIAR E REFINAR 52:41

Como se cria uma skill? A primeira coisa a entender é como a estrutura de uma skill funciona.

Uma skill bem construída tem três componentes principais. Primeiro, há a pasta da skill em si — por exemplo, `scrape-leads/`. Dentro dela, há outra pasta chamada `scripts/` que executa a parte programática da skill. E então há o arquivo principal `skill.md` em Markdown.

O `skill.md` deve ser tratado como o orquestrador de toda a operação. Como em uma orquestra, o maestro não é a pessoa fazendo a música — o maestro está orquestrando a produção de música de uma variedade de outras fontes. Dentro da pasta `scripts/`, temos os músicos reais — os violinistas, os celistas, os pianistas. O `skill.md` dá uma grande checklist de tarefas, fornece todas as informações de referência e tudo que o Claude precisa. E trata-o exatamente como um funcionário júnior: “aqui está o checklist, vá fazer”.

Onde a orquestração entra é quando há um problema com a execução passo a passo das subtarefas. Algumas dessas subtarefas serão scripts que terão que ser executados — esses são os músicos que tocam as partituras específicas. Outras serão tarefas de raciocínio que o Claude executa com sua inteligência.

Por que as skills consomem tão poucos tokens em relação a MCPs e ferramentas? Porque a skill inteira não é carregada no contexto. Se examinarmos o arquivo de skill de scrape de leads, a única seção que é realmente carregada no contexto é o “front matter” do arquivo — um pequeno cabeçalho em Markdown. O front matter carrega apenas um nome, descrição e ferramentas permitidas. Somente quando o Claude realmente acha que precisa usar a skill — ou quando se diz explicitamente “use o arquivo scrape-leads” — é que ele carrega tudo. Isso significa que se obtém a maioria dos benefícios de ter acesso a uma tonelada de ferramentas, mas sem ter que carregar tudo no contexto imediatamente.

Para criar uma skill do zero, o processo é: descrever ao Claude o que se quer automatizar e pedir que ele formate como uma skill. Se ele não souber exatamente como são as skills, vai pesquisar a formatação. Depois, pega-se essa skill e alimenta uma instância nova do Claude Code que não tem compreensão nenhuma da skill — para ver como se sai. Se errar, dá-se feedback: “modifique a skill para fazer melhor da próxima vez”. Repete-se o processo. A taxa de erro pode começar em talvez 30% — está funcionando bem apenas 70% das vezes na primeira tentativa. Depois de algumas mudanças, está bom 80%. Depois de mais algumas mudanças, bom 90%. E eventualmente se chega a 98 a 99% de fidelidade e precisão. Em qualquer campo de conhecimento hoje, isso é mais do que suficiente.

O bom das skills é que não precisam ser perfeitas da primeira vez. Não são como um programa onde se monta algo e, no segundo que comete um erro, está acabado. É like um agente inteligente que, quando encontra um erro — como um problema com espaços em nomes de arquivo durante um upload para o Google Sheets —, percebe o problema, vai ler a documentação relevante, e corrige automaticamente. Esse loop de tentar e retestar é o que o Claude faz muito bem.

## SKILL EM AÇÃO — GERAÇÃO DE WEBSITES PARA DENTISTAS 55:18

Um exemplo prático mais avançado de skill é a criação de websites customizados para diferentes negócios a partir de uma planilha de leads. Imagine que se tem uma planilha com 1.000 dentistas nos Estados Unidos, cada um com nome da clínica, telefone, endereço, especialidades. O objetivo é gerar um website personalizado para cada dentista em poucos segundos.

A skill de geração de websites funciona assim: ela recebe uma linha da planilha com as informações da clínica. Com essas informações, faz uma pesquisa sobre a clínica (usando o Chrome DevTools MCP para navegar e colher informações). Então gera um HTML de página única com: nome da clínica, serviços oferecidos, foto de equipe (via Unsplash ou similar), informações de contato, call-to-action para agendamento, estilo visual limpo e profissional.

Durante a demonstração, a skill gerou um site para uma clínica em cerca de 30 segundos. Com 10 subagentes executando em paralelo, o tempo por website cai para cerca de 3 segundos. Para uma lista de 10.000 leads: 10.000 × 3 segundos = 30.000 segundos = aproximadamente 8 horas de geração completamente automatizada.

O que isso permite é construir um sistema de prospecção completo: scrape de 1.000 leads (87 segundos), geração de 1.000 websites personalizados (50 minutos com 10 subagentes em paralelo), publicação de cada website via Modal (segundos cada um), envio de email frio personalizado para cada lead com o link do website que foi criado especificamente para a clínica deles. Uma abordagem de outbound que era anteriormente impensável em termos de personalização em escala agora se torna realizável.

O que é realmente interessante é que, ao combinar a skill de scraping de leads com a skill de geração de websites e outra skill que automatiza a criação de campanhas no Instantly (plataforma de cold email), se constrói um sistema de crescimento quase completamente automatizado.

## MODEL CONTEXT PROTOCOL (MCP) — EXTENSÕES PARA O CLAUDE CODE 56:38

Agora que se entende como skills funcionam — que são basicamente funções de backend que podem executar scripts, quase como programas que usam a inteligência flexível da IA e o rigor procedural de scripts Python para fazer a mesma coisa sempre, mas com a flexibilidade de tratar erros —, é hora de falar sobre Model Context Protocol.

A forma de ver o MCP é: são skills, exceto que outras pessoas fazem as skills por você. Na maioria das vezes, são equipes de desenvolvedores. A ideia é muito parecida — basicamente está se dando ao agente acesso a uma parte de software. E então, da mesma forma que ele chama suas próprias ferramentas, como web search e bash e Chrome DevTools, MCP e screenshot, tudo que já foi visto — o que se está fazendo é simplesmente chamar as ferramentas, mas outra pessoa é responsável por montá-las.

Isso leva à pergunta óbvia: onde encontrar MCPs? Há sites como `mcpservers.org`, `github.com/modelcontextprotocol/servers` e `mcp.market`. Vale saber que nem todos vão ser 100% seguros ou confiáveis. São bibliotecas de terceiros que pessoas estão montando. Mas muitos desses são bem vetados nesse ponto. O importante é preferir os mais populares e revisados pela comunidade.

O maior MCP é provavelmente o Chrome DevTools MCP. Esse é usado constantemente — basicamente todo dia, muitas vezes. Porque ele permite que o agente de código controle e inspecione um navegador Chrome ao vivo. Na opinião do instrutor, é significativamente mais alta qualidade do que qualquer uma das ferramentas de navegador atuais que o Claude ou outras plataformas disponibilizaram. Há uma extensão Chrome que pode ser usada para controlar aquela instância do Chrome através dessa ferramenta do Claude.

Por exemplo, pode-se dizer ao Claude “abra uma aba e vá para um site específico”, “tire um screenshot”, “resuma esta página”. O Claude vai abrir o navegador, navegar, tirar screenshots e depois falar sobre o site. É possível também dar instruções como “clique neste botão” ou “entre com meu email”. O Chrome DevTools MCP faz isso cerca de 100 vezes mais rápido do que a capacidade de controle de navegador embutida do Claude.

Para instalar qualquer MCP, o processo é sempre o mesmo: encontrar o JSON de configuração do servidor MCP na documentação, copiá-lo e dizer ao Claude para instalar no workspace local. O JSON tem a estrutura: `{“mcpServers”: {“nome-do-servidor”: {“command”: “...”, “args”: [...]}}}`. O Claude faz o resto. Após instalação, abre-se uma nova instância do Claude Code para que as novas ferramentas sejam reconhecidas.

Quando se precisa de um MCP que requer autenticação — como o Gmail MCP ou o ClickUp MCP —, o Claude vai solicitar a criação ou colagem de uma chave de API ou token de autenticação. O processo varia por serviço, mas geralmente envolve: ir às configurações do serviço, gerar um token de API, colá-lo no Claude quando solicitado, e então reiniciar a sessão do Claude Code.

## MCP NA PRÁTICA — GMAIL, CLICKUP E GESTÃO DE CONTEXTO 58:23

O overhead de tokens do MCP é uma consideração importante. Ao usar o `/context` após instalar o MCP do ClickUp, pode-se ver que o overhead é significativo. A ferramenta “ClickUp search” consome 1.600 tokens. “Get workspace hierarchy” consome 419. E assim por diante. Se somarmos tudo, as ferramentas MCP do ClickUp estão consumindo quase 20.000 tokens. Isso é mais do que as system tools padrão!

O que isso significa é que logo de cara, antes de enviar qualquer mensagem, já se está em algo como 35.000 tokens ou mais. Levando em conta o system prompt também, se está em 40.000. Contando arquivos de memória e skills, se está perto de 45.000. E isso é tudo antes de enviar uma única mensagem. Dado que a janela de contexto é 200.000 tokens, isso representa 22,5% da janela de contexto totalmente consumida antes de qualquer trabalho real.

Em contraste, ao comparar com as skills, vê-se que “scrape-leads” consome apenas 63 tokens. “School monitor” consome 59. “Cross niche outliers” consome 58. Um único tool do MCP do ClickUp como “update_task” consome mais do que praticamente todas as skills combinadas. É como... por que diabos usaria ferramentas MCP se posso fazer uma skill?

A resposta é a conveniência. O MCP é rápido de configurar — basicamente apenas logar e fornecer uma linha. A skill levou mais tempo para criar. Aquela skill de website design levou uns 5 minutos para criar do início ao fim. Uma vez criada, é super eficiente. Mas a configuração do MCP leva talvez 2 minutos.

Então a forma de usar MCPs pessoalmente é: além do Chrome DevTools MCP, que é excelente e usado constantemente, os MCPs são usados principalmente para esboçar rapidamente se algo é possível. Básicamente vai-se a uma nova ferramenta que se quer ver se é possível integrar, diz-se “aqui estão os detalhes do MCP, podemos fazer X, Y e Z?”. E se puder fazer X, Y, Z na primeira vez, diz-se “ótimo, pegue o que acabou de fazer e converta em uma skill”. Aí vão-se encontrar os endpoints de API e construir um script que faz tudo automaticamente, em vez de usar a ferramenta MCP super inchada.

A experiência prática da demonstração com o Gmail MCP mostra isso bem. Usando o MCP do Gmail para organizar emails com labels, o processo funcionou mas levou 36 segundos para 100 emails. Após converter para uma skill com chamadas diretas à API do Gmail, o mesmo processo levou apenas 3,6 segundos para 100 emails — 10 vezes mais rápido — e consumiu uma fração dos tokens.

## PLUGINS DO CLAUDE CODE — VISÃO GERAL E MARKETPLACE 1:00:19

Os plugins do Claude Code são extensões que adicionam funcionalidades específicas à experiência de uso. Para acessar, usar “Customize and Manage Plugins” no menu do Claude Code.

O único plugin instalado na demonstração é o “claude-mem” para macOS. É um plugin simples que basicamente adiciona todas as mensagens enviadas a qualquer instância do Claude a algum arquivo de memória, e então o Claude pode executar buscas sobre isso. Se perguntar “o que eu perguntei há duas semanas?”, pode responder. É marginalmente útil.

O marketplace oficial fica em `github.com/anthropics/claude-code-plugins`. Alguns plugins disponíveis da Anthropic incluem: frontend design (que segundo eles melhora a qualidade do design — pessoalmente o instrutor considera o fluxo de screenshot de referência superior), Context7 (que permite buscar documentação de qualquer API de forma compacta e eficiente em tokens), Agent SDK Dev, e Code Review.

O Context7 é bastante útil: se estiver trabalhando com três ou quatro ferramentas diferentes, basta instalar como plugin e ele automaticamente comprime a documentação de API das fontes para o Claude poder ler de forma muito eficiente em tokens.

A realidade é que o Claude Code vanilla funciona muito bem sem nenhum tipo de extensão ou plugin no momento. Mas conhecer o que existe é valioso. E a tendência é que as funcionalidades de plugins sejam gradualmente absorvidas pelo sistema de skills, que é mais flexível. Portanto, não se apoia muito neles.

## SUBAGENTES — PARALELISMO, ISOLAMENTO DE CONTEXTO E ARQUITETURA 1:01:39

Os subagentes não são necessariamente uma solução mágica. Com eles é possível fazer mais ou menos tudo que se poderia fazer com um agente normal simples. Mas subagentes aceleram as coisas um pouco e permitem paralelizar o workflow, o que pode ser muito útil em circunstâncias específicas.

Um problema importante que as pessoas têm atualmente com subagentes é que eles consomem muitos tokens. E, ao fazer isso, também podem custar bastante, especialmente quando se vai para agent teams, que no momento desta gravação custam cerca de sete vezes mais tokens do que simplesmente usar um único thread do Claude, como foi feito ao longo deste curso. Mas subagentes ainda são bastante úteis de se conhecer.

A lógica dos subagentes é baseada no isolamento de contexto. Quando um subagente é criado, ele começa com seu próprio contexto — não tem memória do agente pai, exceto pelo que é passado na instrução inicial. O único texto dentro do prompt do subagente é algo como “o usuário quer saber o horário atual, por favor determine o horário e reporte de volta”. E esse é basicamente o claude.md completo do subagente.

Então porque há essa separação de contexto, se quiser manter o número total de tokens que se usa o mais baixo possível no agente pai — que é geralmente o mais inteligente, pelo qual se paga o alto custo de API —, em vez de tentar preencher 100.000 tokens de pesquisa quando o agente vai na internet e verifica tendências, aí vai ao Google Analytics, e então coloca coisas no DuckDuckGo, em vez de preencher ou poluir todo o contexto do agente pai, o que se faz é simplesmente dizer “vá pesquisar X, Y, Z e me dê um resumo”. E então ele vai poluir todo o seu próprio contexto, pode usar 50 ou 100 mil tokens, o que é por que muitas pessoas usam a série de modelos Sonnet para esse propósito. E então a única coisa que volta ao pai é apenas aquele resumo. O subagente pode usar 100.000 tokens, mas o que transmite de volta pode ser apenas 2.000, que se comparar ao que o pai teria custado é uma economia de 50 vezes.

Os principais subagentes recomendados são três:

O research sub-agent é quase sempre criado porque a pesquisa consome muitos tokens. A ideia é que o subagente pode fazer toda a pesquisa “sujar” de contexto usando um modelo mais barato como Sonnet, e apenas o resumo compacto volta ao agente pai inteligente.

O reviewer sub-agent funciona de forma contrária — aqui, ter sem contexto é exatamente o ponto. O agente pai escreve muito código. Agora seu contexto está muito enviesado para a forma que escreveu o código. Tem como 10.000 tokens e todos esses tokens dizem “eu devia escrever o código dessa forma por razão tal”. Se quiser ter um código realmente de alta qualidade, às vezes o que se tem que fazer é dar o código para outra versão de si mesmo sem contexto e simplesmente dizer “ei, este é o código, sem conhecer nada, você acha que é bom código?” Se a resposta é sim, é bom código. Se não, o reviewer dirá “é estranho ter escrito assim, por que escreveu dessa forma?” E a razão é porque a versão inicial estava muito enviesada por ter acabado de fazer todo esse pensamento. Em grandes empresas, isso se chama code review — um programador escreve uma função ou ferramenta grande, e aí um revisor olha do zero e identifica problemas que o autor não percebe.

O QA/testing sub-agent: em vez de poluir o contexto do agente principal com testes automatizados, um subagente executa os testes e retorna apenas os resultados. Para design é fácil — basta um screenshot. Para desenvolvimento de backend, é necessário determinar se a coisa que foi dita que deveria funcionar está realmente acontecendo.

## SUBAGENTES NA PRÁTICA — PARALELIZAÇÃO DE CLASSIFICAÇÃO DE EMAILS 1:03:54

Para demonstrar o poder real dos subagentes, o exemplo de classificação de emails é expandido de 100 emails para 1.000 emails usando 10 subagentes em paralelo.

O prompt enviado ao Claude é: “Gostaria de converter este fluxo de gmail-label em um subagente. Motivo: quero paralelizar o trabalho. Em vez de levar 36 segundos para buscar, classificar e rotular 100 emails, quero que seja possível criar 10 subagentes que façam tudo isso simultaneamente e então retornem os resultados. Gostaria de fazer isso usando a especificação de subagentes. Se não souber o que é isso, faça uma pequena pesquisa sobre subagentes — é um recurso da Anthropic e do Claude Code bem suportado pela estrutura atual do workspace. Uma vez construído o subagente usando sonnet-4.5, quero que o implante como teste e me mostre o quão mais rápido é com algum tipo de instrumentação de tempo”.

Ao abrir a aba de thinking, o Claude vai primeiro pesquisar subagentes e então construir um fluxo de gmail-label paralelizado que cria múltiplos subagentes para classificar emails simultaneamente. Vai usar sonnet-4.5 porque pode carregar muito mais contexto e processar todos os emails de forma mais eficiente.

Ao executar com 100 emails, a classificação levou 19 segundos no total (versus 36 com uma única instância). A melhoria é modesta em escala pequena. Mas ao escalar para 1.000 emails divididos em 10 chunks de 100 em paralelo, o benefício fica claro.

Com 10 subagentes rodando em paralelo, cada um com 100 emails, enquanto o processamento serial levaria cerca de 360 segundos (36 × 10), os subagentes em paralelo completam o processamento de 1.000 emails em cerca de um minuto — aproximadamente 6x mais rápido.

Houve uma complicação: quando todos os subagentes retornaram strings massivas de texto com cada email, ao combinar tudo no thread pai, o contexto ficou muito longo e esgotou. A solução foi modificar o prompt para que os subagentes não precisassem retornar o texto real ao agente pai — apenas aplicar os labels diretamente no Gmail e reportar apenas uma confirmação de sucesso. Com essa mudança, 987 de 989 emails foram rotulados com sucesso.

Esta é a verdadeira potência dos subagentes: para tarefas altamente paralelizáveis como processamento de grandes volumes de dados, a aceleração é proporcional ao número de subagentes usados — limitado apenas pelo custo de tokens e pela complexidade de coordenação.

A consideração estatística é importante: se cada subagente tem 95% de chance de completar corretamente, e se rodam 10 em paralelo, a probabilidade de todos completarem corretamente é 0,95 elevado a 10 — cerca de 59%. Com 50 subagentes, cai para 7%. Por isso: manter as instruções dos subagentes simples e focadas, delegar tarefas atômicas e bem definidas, e deixar o agente principal fazer a síntese. Quanto mais simples a tarefa do subagente, maior a probabilidade individual de sucesso.

## AGENT TEAMS — TIMES COMPLETAMENTE AUTÔNOMOS DE AGENTES 1:06:13

Os agent teams diferem dos subagentes de uma forma fundamental: enquanto subagentes são instâncias com contexto limitado que retornam resultados ao pai, os agent teams são instâncias completas do Claude Code — cada uma com seu próprio contexto completo, claude.md, MCPs e skills — que trabalham de forma independente e podem se comunicar uns com os outros.

A analogia organizacional é precisa: há um agente líder (team lead) que coordena o trabalho, e múltiplos agentes membros que executam tarefas. Os membros podem reportar ao líder e também se comunicar diretamente entre si via um scratchpad JSON compartilhado — uma espécie de mini-fórum ou quadro de mensagens interno. Eles publicam tarefas nas quais estão trabalhando. Se têm perguntas, perguntam a pessoas específicas responsáveis por aquelas coisas. Isso pode economizar tempo significativo para cada agente individual.

Sub-agentes: possuem o contexto inteiro, os resultados retornam para o agente que os chamou. Agent teams: possuem o contexto completamente, são totalmente independentes, e não precisam retornar resultados de volta ao chamador — teams podem se comunicar entre si.

No aspecto de coordenação: com subagentes, o agente principal gerencia todo o trabalho. Com agent teams, é uma lista de tarefas compartilhada com auto-coordenação. Assim como com um quadro do Trello ou uma lista de tarefas do ClickUp, esses agentes também trabalham com equivalentes JSON. Dizem que subagentes são melhores para tarefas focadas onde apenas um resultado importa, enquanto agent teams são melhores para trabalho complexo que requer discussão e colaboração.

O custo de tokens é proporcional: se houver 10 agentes ativos rodando, se consumirá aproximadamente 10 vezes o contexto, se não mais, porque também haverá alguma latência e overhead de coordenação e comunicação.

Para habilitar agent teams (recurso experimental), é necessário editar o `settings.json` no workspace atual e adicionar:

```json

{“env”: {“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”}}

```

Os agent teams também são desativados por padrão porque não querem que ninguém gaste acidentalmente 10.000 dólares em agent teams em um dia — o que absolutamente pode acontecer se não for tomado cuidado. Por isso os limites de gastos são tão importantes.

Uma diferença importante em relação a subagentes: como cada membro do team é uma instância completa do Claude Code, cada um pode usar seu próprio claude.md, MCPs e skills. Se houver um claude.md no workspace, todos os três membros do time terão acesso a ele. Isso permite que cada membro execute com o contexto completo de conhecimento do projeto.

## AGENT TEAMS NA PRÁTICA — WEBSITES E ANÁLISE DE SEGURANÇA 1:08:14

Um primeiro exemplo simples de agent team é gerar três websites fundamentalmente diferentes em paralelo para comparar. O prompt: “Estou projetando um site pessoal para Nick Sarayev, crie três agentes usando um team e crie três designs fundamentalmente diferentes, abra todos os três quando terminar, e eu vou comparar, contrastar e dar feedback. Certifique-se de que eles saibam tudo que há para saber sobre mim para que ninguém fique esperando por informações.”

Ao executar, o agente pai executa o que é chamado de “Design Minimalist”, “Design Dark” e “Design Warm” em paralelo. Para usar o terminal nesse contexto, que tem UX bem melhor para agent teams que a GUI, é possível fazer Shift+Seta para cima/baixo para alternar entre os agentes ativos e ver o que cada um está fazendo.

Cada agente cria seu próprio website de forma independente. Quando todos terminam, os três são apresentados. Então escolhe-se o favorito e pede-se mais iterações: “Eu realmente gostei da opção de narrativa quente. Ficou ótimo. Gostaria que agora rodasse mais três agentes. Primeiro quero que você faça pesquisa sobre princípios de design eficazes e princípios de copywriting que convertem. Uma vez feito, quero que rode um monte de agentes para iterar sobre este design e criar suas próprias versões.”

O que o time faz é criar três research agents em paralelo: um pesquisando princípios de design, outro fazendo fundamentos de copywriting, e um terceiro encontrando sites de alta qualidade de criadores como Ali Abdaal, Alex Hormozi, Dan Koe como exemplos de referência. Após coletar tudo isso, os resultados são compilados em documentos de pesquisa densos e então quatro agentes de iteração são criados para produzir novas versões do website com base nessa pesquisa.

O resultado é que, em vez de apenas ter escolhido uma opção e parado aí, foi feita uma exploração completa do espaço de possibilidades. Quatro iterações diferentes foram geradas — uma focada em conversão, uma editorial, uma estilo Dan Koe, uma mais escura — e a melhor foi selecionada para refinamento adicional.

O caso de uso mais poderoso para agent teams é análise de grandes bases de código. O exemplo mostrado é análise de segurança do repositório open source do OpenClaw. O prompt envia 10 agentes para varrer o código base, dividindo-o por tamanho de arquivo. Então quatro agentes documentam os problemas de segurança, e dois agentes de debate discutem os problemas — um dizendo que não são reais, outro dizendo que são críticos. A coordenação entre os agentes de debate é visível em tempo real: eles literalmente enviam mensagens um ao outro via o scratchpad compartilhado, argumentando e contra-argumentando em rodadas.

Os 10 scanners varrem o código em paralelo (83k linhas, 43k, 42k, 42k, 35k, 49k de linhas em diferentes agentes). O processo completo identificou 15 vulnerabilidades em cerca de 15 minutos, ao custo de aproximadamente 80 dólares em tokens. Uma equipe de desenvolvedores humanos levaria semanas para o mesmo nível de análise.

A lição principal: agent teams são como uma arma nuclear — extremamente poderosos, mas apontados diretamente para sua carteira se não forem usados com cuidado. Defina limites de gastos antes de rodar operações de grande escala.

## GIT WORKTREES — DESENVOLVIMENTO PARALELO SEM CONFLITOS 1:10:38

Os Git worktrees eram basicamente o que agent teams são hoje. Essencialmente, é possível ter múltiplos agentes rodando em seus próprios “worktrees” individuais do GitHub — basicamente branches individuais do Git. E ao fazer isso, esses agentes podem todos trabalhar em features individuais que lhes permitem fazer o que precisam antes de eventualmente fazer o merge de volta ao branch principal.

Para visualizar isso: começa-se com um job no `main` — o branch principal. E então há algum bug. Então cria-se um branch chamado `hotfix`. Isso é dado a um agente diferente. Há outro branch chamado `develop` que é dado a outro agente. E finalmente um branch chamado `feature` dado a um terceiro agente. Basicamente o que ocorre é que se tem um agente estendendo este branch, outro estendendo aquele branch, outro aquele, e então um estendendo o último. E cada um passa pelo seu próprio processo de desenvolvimento. E quando terminam, o que fazem é mesclar os resultados de volta ao branch main.

Para quem não está muito familiarizado com programação, a ideia de “merge” pode ser difícil de entender. Mas basicamente cada branch armazena uma cópia da pasta, e essa pasta mestre é basicamente a mesma coisa que esta nova pasta de feature com apenas algumas diferenças menores — geralmente a própria nova feature. Então ao fazer o merge, o que se está fazendo é tabelar uma lista de todas as mudanças entre esses dois, e então pegar as novas mudanças do novo branch de feature e aplicá-las ao branch master. Esse processo de merge pode tipicamente ser bastante bagunçado, e ter agentes por perto para mediar os merges pode ser bastante útil.

A principal vantagem dos worktrees sobre agent teams para código é a eliminação de conflitos de arquivos. Para usuários não programadores, o ponto prático é: worktrees reduzem a possibilidade de dois agentes diferentes trabalhando na mesma base modificarem os mesmos arquivos. Isso pode ocorrer naturalmente porque arquivos raramente são separações perfeitas de funcionalidade — um arquivo pode ter um trecho de código usado por outro arquivo.

Ao usar worktrees, cada agente está literalmente em uma pasta diferente simultaneamente. Os arquivos não são modificados diretamente — cópias de trabalho separadas são criadas. Então se eles fazem mudanças, essas mudanças não harmonizan automaticamente, e é por isso que o passo de merge existe.

Para usar worktrees com agent teams: o claude.md do projeto contém instruções sobre como usar git worktrees para desenvolvimento paralelo — onde cada worktree é um diretório de trabalho isolado compartilhando o mesmo histórico Git, permitindo que múltiplas instâncias do Claude Code trabalhem em tarefas diferentes simultaneamente sem interferência. Com esse claude.md configurado, basta dizer ao Claude que se quer três novas páginas e usar o workflow de git worktrees para isso. O agente entende e cria automaticamente três branches separados, atribui cada um a um agente diferente do team, e coordena o merge final.

O resultado são três novas páginas (sobre, contato, serviços) desenvolvidas em paralelo, cada uma no próprio branch, e depois mergeadas limpa e automaticamente ao projeto principal.

## HOOKS — AUTOMATIZANDO COMPORTAMENTOS BASEADOS EM EVENTOS 1:13:00

Os hooks são scripts customizados que disparam automaticamente antes ou depois de qualquer tool call do Claude Code. São configurados no arquivo `settings.json` dentro do diretório `.claude` do projeto.

O caso de uso mais simples e prático é um som de notificação. Quando se tem múltiplas instâncias do Claude Code abertas ao mesmo tempo e se está fazendo outras coisas enquanto espera que as instâncias terminem suas tarefas, é muito útil receber um sinal quando cada instância termina. Um hook que toca um som ao final de cada execução resolve isso perfeitamente.

Pode-se definir sons diferentes para diferentes janelas. Quando o som 1 toca, sabe-se que a janela do canto superior esquerdo está pedindo mais instruções. Quando o som 2 toca, é hora de verificar outra instância. Isso elimina a necessidade de ficar monitorando constantemente todas as telas abertas.

Outros casos de uso práticos para hooks: registrar automaticamente cada tool call em um arquivo de log para auditoria; executar testes automatizados após cada edição de arquivo para capturar regressões imediatamente; formatar código (linting) automaticamente após cada escrita de arquivo; validar que arquivos sensíveis não foram modificados; sincronizar arquivos com servidores externos após mudanças; e enviar notificações para telefone ou Slack quando tarefas longas completam.

A configuração no `settings.json` segue o padrão: especificar o evento que dispara o hook (como `after_tool_call`), o comando a executar, e opcionalmente um filtro por tipo de ferramenta. Um hook de notificação sonora simples no macOS executa apenas `afplay /System/Library/Sounds/Glass.aiff` para tocar um som de sistema.

Para criar hooks, a forma mais fácil é simplesmente descrever ao Claude Code o comportamento que se quer e pedir que configure o `settings.json` automaticamente. Por exemplo: “Configure um hook que toca um som de notificação sempre que o Claude termina de executar uma tarefa e está esperando por mais instruções”. O Claude vai criar e configurar o hook appropriadamente.

## DEPLOY E PRODUÇÃO COM NETLIFY E MODAL 1:15:05

Construir localmente é apenas o primeiro passo. Colocar o que foi construído acessível via internet — para si mesmo, para a equipe ou para clientes — é o segundo passo.

Para sites estáticos (HTML/CSS/JS sem backend), o Netlify é a ferramenta mais simples. A implantação leva literalmente alguns minutos: conecte o repositório GitHub ao Netlify, configure o diretório de build e o site fica disponível em uma URL pública. O plano gratuito é suficiente para a maioria dos casos de uso pessoais e de pequenas equipes. As variáveis de ambiente (como chaves de API) são configuradas nas definições do site no Netlify.

Para backends, APIs e scripts Python que precisam ficar acessíveis via URL, o Modal é a ferramenta recomendada. O Modal é descrito como “infraestrutura de IA que desenvolvedores adoram” — a proposta é implantar qualquer função Python como um endpoint web em segundos.

Para fazer o cadastro no Modal: ir ao site modal.com, criar conta com Google, completar o onboarding básico. O Modal oferece 5 dólares em créditos gratuitos, com possibilidade de até 30 dólares ao completar tarefas de onboarding como adicionar cartão de crédito. Para contexto: após meses de uso com um endpoint sendo acessado a cada um ou dois dias, o saldo ainda estava em cerca de 4,50 dólares — é um serviço muito barato.

Para usar o Modal com o Claude Code, é necessário criar um token de API no Modal, copiá-lo e fornecê-lo ao Claude junto com as instruções da plataforma. Uma vez configurado, basta dizer “implante esta função como endpoint público no Modal” e o Claude faz toda a configuração.

O fluxo de trabalho prático demonstrado no curso foi criar um endpoint que verifica se é o aniversário do usuário e retorna uma mensagem engraçada. O endpoint foi criado em menos de 2 minutos. Inicialmente exigia autenticação via curl, mas após pedir ao Claude para “remover a autenticação e deixar acessível via browser com um GET simples”, o endpoint foi modificado e ficou disponível como uma URL pública simples que qualquer um pode acessar.

O caso de uso mais poderoso é transformar skills em endpoints web acessíveis. A skill de scraping de leads vira um formulário web: o usuário especifica o tipo de lead e a quantidade, clica em executar, e alguns segundos depois recebe um arquivo CSV com os resultados. Isso cria ferramentas internas que qualquer membro da equipe pode usar sem precisar configurar o Claude Code localmente.

Para integrações com plataformas no-code como n8n, Make.com, Zapier e Lindy, os endpoints criados no Modal funcionam como webhooks padrão. Qualquer plataforma que suporte webhooks pode disparar e receber dados de automações construídas com Claude Code. Isso cria uma ponte entre o poder do Claude Code e a facilidade de uso de plataformas no-code.

## CHROME DEVTOOLS MCP — O MCP MAIS PODEROSO 1:15:55

O Chrome DevTools MCP é o MCP mais valioso disponível atualmente e é usado constantemente — praticamente todo dia. Ele permite que o agente de código controle e inspecione um navegador Chrome ao vivo.

A diferença entre o Chrome DevTools MCP e a capacidade embutida de controle de browser do Claude é enorme em termos de velocidade e versatilidade. O MCP é cerca de 100 vezes mais rápido. Não só isso, mas porque pode ser integrado em cenários baseados em skills, é possível executar coisas altamente procedurais no navegador que antes levariam muito tempo para automatizar.

Para instalar, basta encontrar o JSON de configuração do repositório oficial do Chrome DevTools MCP, colá-lo no Claude Code e pedir para instalar no workspace local. É necessário abrir uma nova instância do Claude Code após a instalação para que as ferramentas sejam reconhecidas.

Com o MCP instalado e a extensão Chrome ativa, as possibilidades são extensas: navegar para qualquer URL, tirar screenshots, extrair o texto completo de qualquer página, clicar em elementos específicos, preencher formulários, executar JavaScript personalizado, monitorar requisições de rede e mensagens do console, e lidar com diálogos e popups.

Um exemplo de caso de uso real: pedir ao Claude para “abrir o Chrome, ir para amazon.ca e encontrar lightboxes baratos mas eficazes para meu estúdio”. O Claude abre o Chrome, navega para Amazon, faz buscas, tira screenshots das páginas de resultados, lê as descrições e reviews, compara opções e apresenta uma lista curada das melhores escolhas com preços e links. O usuário apenas revisa e aprova a compra.

Outro exemplo prático: a skill “shop-amazon” instrui o Claude a fazer toda a pesquisa de produto na Amazon e apresentar opções para aprovação antes de qualquer compra. A instrução “stop — get purchase approval — do not skip this step” garante que o humano está sempre no loop antes de qualquer transação.

A combinação do Chrome DevTools MCP com skills cria automações de browser extremamente poderosas que seriam impossíveis sem essa integração. É essencialmente uma API para qualquer site que não tenha uma — uma capacidade extraordinária para automações de negócios.

## LINHA DE STATUS E PERSONALIZAÇÃO DO TERMINAL 1:18:29

Uma das vantagens de usar o Claude Code no terminal em vez da GUI é a capacidade de personalização muito maior. A linha de status — aquela barra de informações que aparece abaixo do prompt no terminal — pode ser completamente customizada.

Para configurar a linha de status, usar o comando `/status-line` no terminal (não disponível na versão GUI). O Claude vai perguntar o que se quer exibir. Uma opção popular é uma barra de carregamento mostrando a porcentagem de tokens usados do contexto total, o modelo atual e o branch Git em uso.

Para ter algo útil, pode-se pedir ao Claude algo como “atualize minha linha de status para que inclua uma barra de carregamento mostrando quantos tokens foram usados do contexto total”. O Claude vai converter isso em um prompt de configuração usando um agente de configuração de linha de status, e depois exibirá algo como “13% █░░░░░░░░░ claude-opus-4-6 (main)”.

Essa visibilidade constante do uso de contexto é extremamente útil para gerenciar eficientemente os tokens. Ver que se está a 80% do contexto antes mesmo de começar uma nova tarefa complexa é um sinal claro para fazer um `/compact` ou `/clear` antes de prosseguir.

A linha de status também pode ser configurada para exibir outras informações: custo acumulado da sessão, tempo decorrido, número de tool calls executadas, ou qualquer outra métrica que seja relevante para o workflow específico.

Para customizar os termos divertidos que o Claude usa quando está pensando — como “finagling”, “processing”, “considering” —, também é possível modificar isso nas configurações. Isso pode ser feito via o settings.json, onde é possível definir termos customizados de processamento que são exibidos durante as operações.

## GERENCIAMENTO AVANÇADO DE CONTEXTO E COMPACTAÇÃO 1:19:48

Um dos maiores desafios ao trabalhar com o Claude Code em sessões longas é a degradação do contexto — o famoso “context rot”. À medida que uma conversa cresce, os tokens mais antigos têm menos influência, e o modelo começa a perder o fio das instruções e decisões anteriores. Gerenciar esse contexto de forma proativa é uma das habilidades mais valiosas que um usuário avançado pode desenvolver.

A ferramenta principal para isso é o comando `/compact`. Quando você executa `/compact`, o Claude pega todo o histórico da conversa — cada mensagem, cada tool call, cada resultado — e comprime tudo em um resumo de alta densidade informacional. O que era milhares de tokens vira alguns centenas de tokens muito densos e bem organizados. O Claude é notavelmente bom em não perder informações críticas durante esse processo.

O que é interessante é que o próprio Claude Code explica o que aconteceu após uma compactação. Ao perguntar ao Claude logo depois de compactar “me diga o que está disponível no seu contexto agora”, ele vai descrever cronologicamente o que foi preservado: “O usuário abriu esse projeto, pediu isso, depois pediu aquilo, depois...” — e isso vai ser bem mais curto do que a conversa original, tipicamente 3 a 4 vezes menos tokens.

A Anthropic começou recentemente a implementar a compactação automática (auto compaction), onde as mensagens mais antigas são continuamente comprimidas em segundo plano. As mensagens mais velhas vão sendo transformadas em resumos de alta densidade enquanto a conversa continua. O efeito é como uma “cauda” de contexto comprimido atrás da conversa atual. Isso é notavelmente generoso da Anthropic, já que a compactação significa que eles faturam menos tokens — mas reflete o comprometimento deles com a qualidade do produto em vez de simplesmente maximizar receita.

O `/compact` pode receber instruções específicas de priorização. Em vez de apenas `/compact`, é possível escrever `/compact Priorize as decisões de arquitetura e os arquivos que foram modificados. Podem ser omitidas as sessões de brainstorming e as mensagens de erro já resolvidas.` Isso dá ao Claude instruções explícitas sobre o que preservar com mais fidelidade.

O `/clear` é diferente do `/compact`. Enquanto o `/compact` preserva o contexto em forma densa, o `/clear` zera completamente a conversa. Após um `/clear`, verificar `/context` mostrará apenas cerca de 152 tokens — basicamente o mínimo necessário para o sistema funcionar. Use `/clear` ao mudar para uma tarefa completamente não relacionada à anterior. Use `/compact` quando quiser preservar o contexto mas economizar tokens.

Para monitorar o uso de tokens em tempo real, o comando `/cost` mostra quanto de contexto já foi consumido. Configurar a linha de status com a barra de progresso de tokens é ainda mais útil pois você vê esse número continuamente sem precisar digitar um comando.

O site oficial da Anthropic tem uma seção dedicada a estratégias para reduzir o uso de tokens e minimizar o “context rot”. Essa documentação é constantemente atualizada, então vale consultá-la periodicamente. Algumas estratégias listadas incluem RAG (Retrieval Augmented Generation), compressão contínua do claude.md, instruções para o Claude escrever de forma concisa, e o uso de extended thinking.

Extended thinking é uma funcionalidade que pode parecer contraditória à primeira vista: habilitar o thinking aparentemente consome mais tokens. Mas a chave é que os tokens de raciocínio ficam em uma “aba de pensamento” separada e não fazem parte do contexto da conversa principal. O Claude pode raciocinar extensivamente usando milhares de tokens de thinking, e depois emitir uma resposta curta e precisa. O resultado final é que você paga pelos tokens de thinking (que são em geral mais baratos por token), mas o “spillage” na conversa principal é mínimo.

Para configurar o extended thinking, use o comando `/model`. Além de escolher o modelo, haverá uma aba de “thinking” que permite ligar e desligar o raciocínio, além de ajustar o orçamento de tokens — de 8.000 tokens mínimos até 32.000 tokens ou mais para tarefas muito complexas. Um bom ponto de partida é deixar em torno de 16.000 tokens de thinking para tarefas de codificação moderadamente complexas.

A seleção de modelo também tem impacto gigante no uso de tokens e custo. Para sub-agentes e tarefas de pesquisa que não precisam de inteligência máxima, o Sonnet é muito mais econômico que o Opus e ainda muito capaz. O Sonnet também tem uma janela de contexto maior que o Opus, o que significa que pode carregar mais informações de uma vez. A estratégia recomendada é usar Opus como o agente principal (o “CEO”) e Sonnet para tarefas de execução específicas (os “funcionários”).

O overhead dos servidores MCP é outro fator crítico. Alguns servidores MCP têm dezenas ou centenas de ferramentas, e apenas carregar as descrições dessas ferramentas pode consumir 20.000 tokens ou mais. O Claude Code tem um mecanismo de busca automática de ferramentas (automatic tool search) que entra em ação quando as descrições de ferramentas MCP excedem 10% da janela de contexto. Em vez de carregar tudo, o Claude primeiro busca qual ferramenta precisa usando uma ferramenta de busca interna, e só então carrega essa ferramenta específica. Mas a melhor estratégia ainda é ser seletivo sobre quais MCPs você mantém ativos.

## SKILLS — A FERRAMENTA MAIS ECONOMICAMENTE VALIOSA 1:23:14

Skills são provavelmente o recurso mais economicamente valioso do Claude Code. A ideia é simples: qualquer processo repetitivo que você executa regularmente pode ser transformado em um “checklist de IA” que o Claude segue automaticamente. Em vez de explicar o processo do zero toda vez, você o documenta uma vez e depois simplesmente diz “execute a skill X”.

A pasta `.claude/skills/` contém todas as suas skills. Cada skill é uma subpasta com dois componentes principais: um arquivo `skill.md` que atua como o orquestrador (o checklist de passos), e uma pasta `scripts/` com os programas Python ou outras ferramentas que executam tarefas específicas.

A melhor analogia é uma orquestra. O `skill.md` é o maestro — não é quem toca os instrumentos, mas quem coordena todos os músicos. Dentro de `scripts/`, temos os músicos: violinistas, pianistas, cellistas. O maestro diz quando cada um entra e o que tocar, mas a execução técnica fica com os scripts especializados.

O fluxo de execução de uma skill é assim: o Claude lê o `skill.md` e entende os passos. Quando chega ao passo 1, vê “execute o script de teste com esses parâmetros” e chama o script. Verifica o resultado. Se deu certo, avança para o passo 2. Se deu errado, usa sua inteligência nativa para diagnosticar e corrigir o problema. Após corrigir, atualiza o `skill.md` para que esse problema não ocorra de novo em execuções futuras. É um sistema que melhora sozinho com o tempo.

A skill de scraping de leads é um exemplo concreto e extremamente prático. O processo manual original levava mais de uma hora: configurar os filtros de busca, verificar uma amostra de leads manualmente para garantir qualidade, executar o scraper completo, verificar os resultados, fazer upload para uma planilha Google, fazer cross-reference para remover duplicatas e enriquecer os dados de email. Com a skill, tudo isso acontece em 87 segundos.

O que a skill de scraping faz internamente: primeiro, executa um teste com 25 leads para verificar qualidade — o Claude lê cada um desses 25 e decide se são do tipo certo. Se aprovados, inicia 4 scrapers em paralelo que coletam 250 leads cada (total: 1.000 leads). Enquanto isso acontece, o Claude monitora o progresso. Quando um problema acontece (como o arquivo não aceitar espaços no nome), o Claude detecta o erro, lê a documentação necessária da API, corrige o problema e continua. No final, enriquece os emails faltantes automaticamente e faz o upload para a planilha Google. Resultado: uma lista de 1.000 leads com telefones, endereços e dados completos, pronta para uso em campanhas de email frio.

Outro exemplo é a skill de pesquisa bibliográfica (literatura research). Quando se quer estudar, por exemplo, “a dose diária recomendada de vitamina D para homens na faixa dos 30 anos”, a skill automaticamente consulta databases científicos como o PubMed, executa um script de revisão profunda em paralelo, e retorna um resumo estruturado com as principais evidências científicas. O que antes exigiria horas de pesquisa manual em papers científicos é feito em minutos.

O ponto crucial sobre skills versus simplesmente pedir ao Claude para fazer algo: quando você usa uma skill, você define exatamente como quer que a tarefa seja executada. Você especifica quais bases de dados consultar, como paralelizar o trabalho para máxima velocidade, quais modelos usar para diferentes sub-tarefas. Você codifica seu próprio conhecimento e metodologia. A skill então executa exatamente da mesma forma toda vez, com a inteligência do Claude para lidar com problemas inesperados.

Como criar uma skill na prática? O processo é surpreendentemente simples. Você descreve o que quer fazer em pontos (bullets), fornece exemplos dos dados de entrada, exemplos de como devem ser os outputs, e qualquer código ou template que o Claude possa usar como referência. Uma boa skill começa com uma seção “front matter” em Markdown com campos `name:`, `description:` e `allowed-tools:`. Esse front matter é a única parte que é carregada no contexto por padrão — o Claude sabe que a skill existe e o que ela faz sem precisar carregar o documento inteiro.

Isso explica por que skills consomem tão poucos tokens. Uma skill completa como “scrape leads” pode ter centenas de linhas de instruções e scripts — mas no contexto da conversa, ela aparece como apenas 63 tokens (o front matter). Só quando você explicitamente pede para usar a skill é que o documento completo é carregado. Isso é uma diferença enorme comparado a MCPs, onde as descrições de todas as ferramentas são carregadas no contexto imediatamente ao abrir uma sessão.

Um caso de uso poderoso é a criação de websites personalizados para clientes potenciais. A skill recebe como entrada uma planilha Google com informações sobre um prospect (nome da empresa, setor, localização), tira um screenshot de um site template de referência para capturar o estilo visual, e gera um site completo e personalizado para esse prospect. O processo inteiro leva 30 segundos por site. Ao converter para sub-agentes que rodam em paralelo (10 ao mesmo tempo), o tempo médio por site cai para 3 segundos. Para uma lista de 10.000 leads, isso significa gerar 10.000 sites personalizados em aproximadamente 8 horas de processamento automatizado.

A skill de website personalizado não usa APIs pagas de imagens — ela busca imagens públicas disponíveis que sejam relevantes para o negócio em questão. O resultado não é perfeito (às vezes aparecem imagens não relacionadas se não houver uma chave da API do Unsplash), mas é surpreendentemente bom como ponto de partida. Uma ou duas iterações de feedback rapidamente elevam a qualidade ao nível de um site profissional.

A recomendação geral é: se você faz algo repetidamente, transforme em uma skill. Se você contrataria alguém para fazer essa tarefa, transforme em uma skill. O ROI (retorno sobre o investimento) de tempo para criar uma skill é altíssimo — você gasta talvez uma hora criando a skill e economiza horas toda semana a partir daí.

## MODEL CONTEXT PROTOCOL — MCP NA PRÁTICA 1:29:24

MCP (Model Context Protocol) é essencialmente o que skills são, mas criados por outras pessoas. Enquanto skills são automações que você mesmo constrói e mantém, MCPs são ferramentas desenvolvidas por equipes de desenvolvedores ou empresas que você simplesmente instala e usa. A analogia é direta: skills são como contratar um freelancer para fazer algo customizado para você; MCPs são como usar um SaaS pronto.

Para descobrir MCPs disponíveis, existem alguns repositórios e diretórios centrais. Os principais são mcpservers.org, o repositório oficial model-context-protocol/servers no GitHub, e o MCP Market. É importante saber que nem todos esses MCPs são 100% seguros — são bibliotecas de terceiros, então é prudente verificar a reputação e o número de usuários antes de instalar qualquer um.

Para instalar um MCP, o processo é simples. Cada MCP disponibiliza um JSON de configuração que se parece com:

```json

{

“mcpServers”: {

“nome-do-servidor”: {

“command”: “npx”,

“args”: [“-y”, “@pacote/mcp-servidor”]

}

}

}

```

Basta copiar esse JSON e pedir ao Claude: “instale este MCP no meu workspace local”. O Claude faz toda a configuração necessária. O ponto crucial de dizer “workspace local” é que o MCP fica disponível apenas para o projeto atual, não globalmente — o que é geralmente o comportamento desejado para não inflar o contexto em todos os projetos.

Após instalar um novo MCP, é sempre necessário abrir uma nova instância do Claude Code para que as novas ferramentas sejam reconhecidas. Isso é um ponto de atrito, mas é simplesmente como o sistema funciona por enquanto.

O Chrome DevTools MCP é o mais utilizado no dia-a-dia. Ele vem com uma extensão Chrome que cria uma conexão entre o Claude Code e o navegador. Com ele instalado, é possível: navegar para qualquer URL, tirar screenshots em qualquer viewport, extrair todo o texto de uma página, clicar em elementos específicos, preencher formulários, executar JavaScript personalizado, monitorar requisições de rede e mensagens do console. Tudo isso de dentro do Claude Code, sem precisar alternar entre janelas.

O ClickUp MCP é um exemplo de ferramenta de produtividade integrada ao Claude. Para configurar: ir ao ClickUp, navegar para a seção de API, copiar o token de API, fornecê-lo ao Claude junto com as instruções de instalação do MCP. Uma vez configurado, é possível criar tarefas, atualizar status, listar projetos e muito mais — tudo através de linguagem natural no Claude.

Um exemplo real de uso: “crie uma nova tarefa de conteúdo chamada Claude Code Course na minha fila principal do YouTube e defina o status como 'para gravar'”. O Claude encontra a lista correta no workspace, cria a tarefa com o título especificado, e atualiza o status — tudo em uma única instrução.

O problema com MCPs como o ClickUp é o custo em tokens. Ao verificar o uso de contexto com `/context`, descobre-se que apenas o ClickUp está consumindo quase 20.000 tokens no início da conversa — antes mesmo de digitar qualquer mensagem. Quando você soma o system prompt (≈15.000 tokens), os arquivos de memória, e as skills (apenas alguns centenas de tokens combinados), chega facilmente a 45.000 tokens iniciais. Isso é aproximadamente 22% do contexto total do Opus — 22% da sua “capacidade de raciocínio de alta qualidade” desperdiçada em descrições de ferramentas que você talvez use uma vez por semana.

Compare com skills: a skill “scrape leads” ocupa 63 tokens. “school monitor” ocupa 59 tokens. “cross niche outliers” ocupa 58 tokens. Todas as suas skills combinadas podem ocupar menos tokens do que uma única ferramenta do ClickUp MCP.

Dada essa ineficiência, a estratégia recomendada para MCPs é: use-os para explorar e prototipar. Quando você quer testar se é possível integrar com uma nova ferramenta, instale o MCP, teste em minutos se funciona, e depois, se funcionar bem, converta para uma skill com chamadas diretas à API. A skill resultante vai usar 1% dos tokens do MCP equivalente.

A exceção a essa regra é o Chrome DevTools MCP — esse merece ficar como MCP porque sua velocidade e versatilidade são difíceis de replicar com scripts puros, e o overhead de tokens vale a pena pelo que ele permite fazer.

Para MCPs que requerem autenticação (como Gmail, Google Drive, Notion), você precisará fornecer credenciais de OAuth ou API keys. O fluxo geralmente é: o Claude detecta que precisa de autenticação, fornece uma URL para você autorizar o acesso, você autoriza, e o Claude salva as credenciais criptografadas localmente. A partir daí, o MCP funciona transparentemente.

## GMAIL MCP E CONSTRUÇÃO DA SKILL DE LABELS 1:36:58

O processo de transformar um MCP em uma skill — passando de protótipo para produção — fica muito claro no exemplo do Gmail MCP. O objetivo era organizar uma caixa de entrada com labels, e o caminho foi: primeiro provar que é possível com o MCP, depois construir uma solução mais eficiente como skill.

A primeira etapa foi pedir ao Claude para sugerir um esquema de labels de alto ROI para uma caixa pessoal. Com o raciocínio (thinking) ativado, o Claude propõe três categorias principais: “Action Required” (requer ação), “Reference” (material de referência) e “Waiting On” (aguardando resposta de terceiros). Simples, prático, aplicável a quase qualquer caixa de entrada.

Para instalar o Gmail MCP: buscar um repositório de Gmail MCP bem avaliado no GitHub, copiar o JSON de configuração, fornecer as credenciais OAuth (o Claude orienta o processo completo de geração de credenciais no Google Cloud Console), e instalar no workspace local. Após reiniciar o Claude Code, as ferramentas do Gmail ficam disponíveis.

Com o MCP funcionando, a instrução é simples: “quero que você leia meus últimos 100 emails e os labels de acordo com o esquema que definimos”. O Claude usa o modo rápido (fast mode com Opus 4.6 em velocidade 2.5x) e classifica 100 emails em questão de minutos. Os resultados ficam visíveis diretamente na interface do Gmail — novas labels aparecem no painel lateral e os emails são organizados automaticamente.

A segunda etapa foi medir a eficiência e escalar. Para 100 emails, o processo via MCP levou um tempo razoável mas não otimizado. Para 1.000 emails, a escala do MCP começa a mostrar limitações de velocidade.

A conversão para skill é onde a magia acontece. A instrução ao Claude foi: “o Gmail MCP funcionou bem, mas skills são muito mais eficientes em tokens. Quero que você transforme esse fluxo de label numa skill chamada gmail-label que usa a API do Gmail diretamente, sem o MCP. Veja minha pasta de skills para entender como formatar. Crie também os scripts necessários.”

O Claude estudou os padrões de outras skills existentes, pesquisou a API do Gmail, criou os scripts Python necessários, configurou a autenticação OAuth de forma direta (sem depender do MCP como intermediário), e escreveu o `skill.md` com o checklist completo. O resultado: a skill “gmail-label” ocupa apenas alguns tokens no contexto (o front matter), enquanto o Gmail MCP ocupava milhares.

Com a skill pronta, a diferença de velocidade é dramática. A fase de “fetch” de 100 emails via skill demora 1 segundo (comparado a múltiplos segundos via MCP). A classificação e aplicação de labels de 100 emails completa em 36 segundos. O tempo por email: 0,36 segundos.

Para 1.000 emails, o desempenho ainda precisa de otimização — o overhead de retornar texto completo dos emails para o agente pai causou problemas de contexto muito longo. A solução foi modificar a skill para que os sub-agentes escrevam os resultados diretamente em arquivos em vez de retornar tudo para o agente pai. Com essa mudança, 987 de 989 emails foram classificados e labalizados com sucesso em aproximadamente 1 minuto.

Isso demonstra um padrão importante: skills combinadas com sub-agentes são a combinação mais poderosa para processar grandes volumes de dados. A skill define a lógica; os sub-agentes paralelizam a execução.

As possibilidades além de labels são enormes: responder automaticamente a certos tipos de emails (newsletters, notificações automáticas), priorizar emails de contatos importantes, extrair tarefas de emails e criar no ClickUp, arquivar automaticamente por categoria de assunto. Com a API do Gmail diretamente disponível via skill, qualquer automação é possível.

## PLUGINS DO CLAUDE CODE 1:39:10

Os plugins do Claude Code são outra camada de extensibilidade, embora atualmente menos utilizados do que skills e MCPs. A forma mais simples de acessar plugins é ir em “Customize” > “Manage plugins” na interface do Claude Code.

O único plugin instalado por padrão na configuração demonstrada é o “claude-mem” — um plugin simples que registra todas as mensagens enviadas em qualquer instância do Claude em um arquivo de memória, e permite ao Claude buscar nessas mensagens depois. Isso cria uma espécie de memória de longo prazo manual: “o que eu perguntei há duas semanas?”.

A Anthropic tem seu próprio diretório de plugins em um repositório chamado “claude-plugins-official”. Alguns exemplos notáveis incluem:

- **Frontend Design Plugin**: melhora a qualidade de design visual em projetos de frontend. O plugin adiciona um “prompt de estética” que orienta o Claude a criar designs mais limpos e modernos. A diferença visual existe, mas pode ser discreta — e a alternativa de tirar screenshots de sites que você quer imitar geralmente produz resultados superiores.

- **Context7**: permite buscar em documentação de APIs de qualquer biblioteca ou framework sem precisar conhecer a estrutura exata da documentação. Se você está trabalhando com três ou quatro ferramentas diferentes ao mesmo tempo, instale o Context7 e ele comprimirá a documentação relevante de cada uma de forma token-eficiente conforme necessário.

Além do repositório oficial, há marketplaces de terceiros como o Claude Plugin Marketplace, que agrega plugins criados pela comunidade. Existem plugins para revisão de código, SDK do agente, exemplos de plugins para linguagens específicas, e outros criados por desenvolvedores independentes.

A instalação de qualquer plugin é similar à de MCPs: encontrar o JSON de configuração no repositório do plugin e pedir ao Claude para instalá-lo. Uma vez instalado, o plugin fica ativo automaticamente em novas sessões.

A perspectiva de longo prazo para plugins é que eles provavelmente serão absorvidos por skills ou por funcionalidades nativas do Claude Code. O ecossistema de plugins ainda é jovem e em evolução. Por ora, o valor prático mais imediato está em skills e MCPs — plugins são um complemento interessante mas não essencial para a maioria dos workflows.

O Claude Code “vanilla” (sem plugins, MCPs ou skills customizadas) já é extremamente capaz para a maioria das tarefas. Plugins, MCPs e skills são multiplicadores de capacidade para casos de uso específicos, não requisitos para começar a trabalhar produtivamente.

## SUB-AGENTES — PARALELIZAÇÃO NA PRÁTICA 1:40:20

Sub-agentes não são uma solução mágica nem uma revolução na forma de trabalhar. São uma ferramenta específica para um problema específico: quando você tem tarefas que podem ser executadas simultaneamente e independentemente, sub-agentes permitem que isso aconteça. Para a maioria das tarefas do dia-a-dia, um agente único é mais eficiente e suficiente.

Um sub-agente é essencialmente uma instância separada do Claude, iniciada pelo agente pai para executar uma tarefa específica. O sub-agente tem sua própria janela de contexto isolada — ele só sabe o que o agente pai lhe contou. Quando termina, retorna os resultados para o agente pai, e seu contexto é descartado. É efêmero por design.

A forma mais simples de entender sub-agentes é pensar na diferença entre trabalho serial e paralelo. No trabalho serial, se você tem três tarefas que levam 1 minuto cada, você espera 3 minutos no total. Com três sub-agentes rodando em paralelo, você espera 1 minuto no total — porque todos os três trabalham ao mesmo tempo. Esse é o valor central dos sub-agentes.

O exemplo concreto com emails é esclarecedor. Classificar 100 emails de forma serial (um por um, ou em batches sequenciais) levou 36 segundos com a skill de Gmail. Ao transformar em sub-agentes — 10 agentes classificando 10 emails cada, em paralelo — a economia em 100 emails é de apenas 6 segundos. Modesta. Mas ao escalar para 1.000 emails com 10 agentes de 100 emails cada, a vantagem da paralelização se torna muito mais evidente.

Para criar sub-agentes, o Claude Code precisa que as definições de agentes estejam na pasta `.claude/agents/`. Cada sub-agente é definido por um arquivo Markdown com um `system prompt` que descreve o papel e as capacidades do agente. Após criar os arquivos, é necessário abrir uma nova instância do Claude Code para que os agentes sejam reconhecidos.

Os três sub-agentes mais úteis no dia-a-dia são:

**Code Reviewer**: um sub-agente que analisa código de forma objetiva, sem o viés do contexto de como o código foi escrito. Porque não sabe o histórico de decisões, ele avalia o código como um revisor externo — que é exatamente o que você quer. Ele identifica problemas de segurança, ineficiências, problemas de legibilidade, e sugere melhorias concretas.

**QA (Quality Assurance)**: gera testes para o código fornecido, executa esses testes, reporta os resultados e tenta corrigir falhas. O fluxo é: recebe o código > cria testes unitários > executa > se falhou, analisa o erro > corrige o código ou os testes > re-executa até tudo passar.

**Research**: especializado em buscar informações em fontes específicas. Você pode customizar quais fontes ele prioriza (documentação oficial, arXiv, StackOverflow, GitHub Issues), como estrutura os resultados, e quais modelos usa para diferentes tipos de pesquisa.

O fluxo de desenvolvimento com sub-agentes ficou assim: 1) o agente pai escreve ou edita o código; 2) spawna code reviewer e QA em paralelo; 3) ambos retornam feedback; 4) o agente pai incorpora as melhorias; 5) commit. Esse fluxo é especialmente valioso em código de produção onde segurança e qualidade são críticos.

Um exemplo real de valor: o code reviewer identificou que a skill de Gmail estava fazendo batches de 100 emails, mas a API do Gmail suporta até 1.000 por batch. Uma otimização simples que triplicaria a eficiência — algo que o agente pai provavelmente teria perdido por estar focado em fazer funcionar, não em otimizar.

A matemática da probabilidade é importante para entender as limitações dos sub-agentes. Se cada sub-agente tem 95% de chance de funcionar corretamente, ao rodar 10 em paralelo a probabilidade de que todos funcionem perfeitamente é 0,95^10 = 59,8%. Com 20 agentes: 35,8%. Com 50 agentes: 7,7%. Isso significa que para tarefas grandes com muitos sub-agentes, você deve esperar alguns falhas e projetar o sistema para lidar com elas.

A solução é manter as definições de tarefa de cada sub-agente simples e focadas. Quanto mais simples a tarefa de cada sub-agente, maior a probabilidade de sucesso. O sub-agente que classifica emails deve apenas classificar e retornar uma estrutura JSON simples — não deve tentar fazer o upload para a planilha também. O agente pai cuida da orquestração e da síntese dos resultados.

Sub-agentes são ephemerais — existem apenas pelo tempo necessário para completar sua tarefa. Se você precisar que um sub-agente use uma skill, precisa passar as instruções relevantes explicitamente no prompt do sub-agente. Ele não tem acesso automático ao histórico da conversa pai ou ao contexto mais amplo do projeto.

A recomendação final sobre sub-agentes: use-os quando o paralelismo realmente importa (grandes volumes de dados, múltiplas pesquisas independentes, geração de múltiplos outputs simultâneos). Não use para tarefas simples onde o overhead de criar e gerenciar o sub-agente seria maior do que simplesmente fazer o agente pai executar diretamente. Um sub-agente para uma tarefa de 5 segundos não é eficiente — o tempo de inicialização do sub-agente pode ser comparável ao tempo da tarefa.

## AGENT TEAMS — PARALELIZAÇÃO EM ESCALA 1:45:35

Agent Teams (equipes de agentes) é uma das funcionalidades mais comentadas e também mais mal compreendidas do Claude Code. Muitos vídeos no YouTube retratam agent teams como uma revolução que “toma conta de toda a sua vida” — essa é uma hipérbole. Agent teams são simplesmente sub-agentes com mais autonomia e capacidade de comunicação entre si.

A diferença entre sub-agentes e agent teams é de nível hierárquico. Com sub-agentes, você tem um agente pai que spawna filhos, os filhos executam, retornam para o pai. Com agent teams, você tem um “team lead” agent que spawna outros agents que por sua vez podem spawnar seus próprios sub-agentes. Além disso, os agents do time podem comunicar diretamente entre si — não apenas reportar ao pai.

Para visualizar a diferença: sub-agentes são como ter um gerente que delega para funcionários individuais. Agent teams são como ter uma empresa inteira operando em hierarquia, onde gerentes delegam para sub-gerentes que delegam para especialistas, e esses especialistas podem colaborar horizontalmente entre eles.

A comunicação entre agents do time acontece através de um “shared scratch pad” — um espaço de notas compartilhado que funciona como um fórum interno ou quadro Kanban. Um agent pode postar uma pergunta: “Encontrei uma função que pode estar relacionada ao módulo de autenticação — alguém está trabalhando nessa área?”. Outro agent lê isso e responde. Essa colaboração, embora custosa em tokens, pode evitar duplicação de esforço e revelar insights que o agente isolado não teria.

Como habilitar agent teams: o recurso é experimental e desabilitado por padrão. Para ativar, edite o arquivo `settings.json` no workspace atual e adicione:

```json

{

“env”: {

“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”

}

}

```

Após isso, abra uma nova instância do Claude Code no terminal (não na GUI — a experiência de agent teams é significativamente melhor no terminal). Com agent teams habilitado, qualquer instrução que o Claude interprete como necessitando de equipe resultará no spawn automático de agents especializados.

Um exemplo simples e demonstrativo: “crie um site pessoal para mim. Gere três agents usando o time, cada um criando um design fundamentalmente diferente. Quando terminarem, abra todos os três para eu comparar.” O Claude Opus age como team lead, faz pesquisa prévia sobre o dono do site (scraping de perfis públicos, LinkedIn, Twitter, vídeos), e então spawna três agents: design-minimalist, design-dark, e design-warm. Cada um trabalha de forma completamente independente em seu próprio contexto, gerando HTML completo com estilos distintos. Quando terminam, o team lead coleta os resultados e abre os três sites para comparação.

O resultado após alguns minutos é surpreendente: três sites completamente diferentes, cada um com uma identidade visual forte, com informações reais sobre a pessoa (obtidas na fase de pesquisa), cada um otimizado para uma persona específica de visitante. O que levaria um designer humano dias foi gerado em minutos.

A iteração é onde agent teams brilham. Após selecionar o design que mais agrada, você pode pedir: “ótimo, o design warm foi o melhor. Agora spin up mais três agents para iterar sobre esse design — cada um incorporando diferentes princípios de design e copywriting para conversão. Faça pesquisa em sites de alto desempenho como Justin Welsh, Dan Coe, e outros criadores de conteúdo para inspiração.”

O time spawna agentes de pesquisa (research agents) em paralelo para estudar: princípios de copywriting que convertem, princípios de design que convertem, e exemplos de sites de alta qualidade de criadores. Cada research agent opera em Sonnet (mais barato, contexto maior) enquanto o team lead opera em Opus. Quando as pesquisas terminam, o team lead usa todo esse material para spawnar agents de design que iteram sobre o design vencedor com base nos insights de pesquisa.

Em questão de 10-15 minutos, o processo completo (pesquisa + múltiplas rodadas de design + iteração) produz 6-9 sites candidatos diferentes. O custo foi significativo — potencialmente $80-150 dólares em tokens — mas o resultado seria equivalente a vários dias de trabalho de um designer humano.

O caso de uso de revisão de código em repositórios open source é particularmente interessante. Usando agent teams em um repositório como o OpenClaw (versão open source do Claude), o processo é: spawn de 10 scanner agents que analisam diferentes partes do código-base em paralelo (dividido por tamanho de arquivo e dependências), cada um procurando problemas de segurança; depois, 4 agents de documentação sintetizam os problemas encontrados; e finalmente, 2 “debate agents” — um que argumenta que os problemas são falsos positivos (devil's advocate), outro que argumenta que são problemas reais que precisam de correção. Esses dois debatem até chegarem a um consenso sobre quais problemas são reais e prioritários.

O debate adversarial entre dois agents é uma técnica poderosa derivada de machine learning. Redes Adversariais Generativas (GANs) funcionam exatamente assim — um gerador e um discriminador que competem até o gerador produzir outputs de alta qualidade que enganam o discriminador. O mesmo princípio aplicado a agents de código resulta em análises mais rigorosas e menos falsos positivos.

As limitações práticas de agent teams que vale conhecer: o custo é alto (em torno de 7x o uso de tokens de uma sessão normal, pois cada agent tem seu próprio contexto completo). Desligar agents quando não são mais necessários é crucial — agents ociosos continuam consumindo recursos de computação. O processo de shutdown não é imediato; pode levar alguns segundos ou minutos dependendo do que cada agent está fazendo. Para limitar gastos descontrolados, configure limites de gasto diário na conta da Anthropic antes de experimentar com agent teams.

A recomendação estratégica é reservar agent teams para situações onde: (a) você tem um grande volume de trabalho que pode ser paralelizado significativamente, (b) o custo em dinheiro é justificado pela economia de tempo, e (c) você precisa de iteração criativa rápida em múltiplas direções simultaneamente. Para desenvolvimento de software rotineiro, sub-agentes ou mesmo um único agente pai são mais eficientes.

## GIT WORKTREES — DESENVOLVIMENTO PARALELO SEM CONFLITOS 1:45:38

Git Worktrees eram, antes do lançamento dos agent teams, a forma principal de parallelizar o trabalho de desenvolvimento com o Claude Code. E mesmo com agent teams disponíveis, worktrees ainda têm seu lugar — especialmente quando você precisa de isolamento total entre branches de desenvolvimento.

A ideia central de git worktrees é simples: em vez de ter uma única pasta de projeto onde todos os agents trabalham (arriscando pisarem nos pés uns dos outros), você cria pastas separadas para cada branch de desenvolvimento. Cada pasta é uma cópia completa do projeto vinculada ao mesmo histórico git, mas trabalhando em um branch diferente. Os agents em cada pasta trabalham de forma completamente isolada.

Para visualizar: você tem um repositório main com sua base de código. Você quer adicionar três novas páginas ao site — about, contact, e services. Em vez de um único agent trabalhar nas três páginas sequencialmente, você cria três worktrees:

- `left-click-agency-about/` — branch `feature/about`

- `left-click-agency-contact/` — branch `feature/contact`

- `left-click-agency-services/` — branch `feature/services`

Três instances do Claude Code abrem, uma em cada worktree. Cada uma trabalha independentemente na sua página. Quando terminam, você faz o merge de volta para o main.

O benefício principal é eliminar conflitos de arquivos. Em desenvolvimento paralelo sem worktrees, dois agents podem editar o mesmo arquivo — um para adicionar funcionalidade A, outro para adicionar funcionalidade B — e o resultado é um conflito de merge que requer revisão manual. Com worktrees, cada agent só tem acesso à sua própria pasta. Fisicamente impossível pisar no pé do outro.

O prompt do claude.md para trabalhar com worktrees é algo como: “Use git worktrees para desenvolvimento paralelo. Cada worktree é um diretório isolado compartilhando o mesmo histórico git, permitindo que múltiplas instâncias do Claude Code trabalhem em tarefas diferentes simultaneamente sem interferência.” Com isso no claude.md, o Claude automaticamente sabe criar worktrees quando a situação exige.

Um exemplo concreto: ao pedir para criar três novas páginas para um site de agência, o Claude automaticamente: (1) cria três novos branches no git, (2) cria três novos diretórios com git worktree add para cada branch, (3) spawna agent teams ou sub-agentes para trabalhar em cada diretório, (4) dá a cada agent um prompt específico como “você está construindo services.html para a Left Click Agency. Trabalhe no worktree em /caminho/para/services-worktree. Não modifique index.html”.

O resultado é que cada página é desenvolvida de forma totalmente independente, com risco zero de conflito entre elas. Os prompts específicos garantem que cada agent sabe exatamente o que deve e não deve tocar.

Após o desenvolvimento, o passo final é o merge. O merge combina as mudanças de cada branch de volta ao main. Em geral, como cada agent trabalhou em arquivos diferentes (about.html, contact.html, services.html), o merge é limpo e automático. Em casos mais complexos onde diferentes agents precisaram modificar arquivos compartilhados (como um arquivo CSS comum), pode haver conflitos de merge que precisam de revisão manual — mas isso é a exceção, não a regra, se o escopo de cada agent foi bem definido.

Para quem não é programador e nunca usou git antes: a parte essencial é entender que git é um sistema de controle de versão que permite rastrear mudanças em arquivos ao longo do tempo. Branches são como cópias paralelas do projeto onde você experimenta sem mexer na versão principal. Merge é o processo de incorporar as mudanças de um branch experimental de volta à versão principal. O Claude Code gerencia tudo isso automaticamente — você não precisa entender os comandos git para se beneficiar dessa funcionalidade.

A diferença prática entre worktrees e agent teams para desenvolvimento paralelo é sutil mas importante: agent teams usam a infraestrutura do Claude Code para comunicação entre agents e compartilham o mesmo diretório de trabalho (com risco de conflitos). Git worktrees criam isolamento total no nível do sistema de arquivos, eliminando qualquer possibilidade de conflito. Para funcionalidades completamente independentes (como páginas separadas de um site), worktrees com agent teams ou sub-agentes são a combinação mais robusta.

## DEPLOY COM NETLIFY E MODAL — PUBLICANDO NA INTERNET 1:46:54

Construir localmente é apenas metade do caminho. Para que o que você construiu seja utilizável por outros, por clientes, ou integrado em automações, precisa estar acessível na internet. O Claude Code facilita enormemente o processo de deploy graças a integrações com serviços modernos de hospedagem.

Para sites estáticos (HTML, CSS, JavaScript sem backend), o Netlify é o serviço mais recomendado. O processo é simples ao ponto de ser quase instantâneo: conecte um repositório GitHub ao Netlify, configure qual pasta contém os arquivos do site, e em minutos o site está ao vivo em uma URL pública. O plano gratuito do Netlify é suficiente para a grande maioria dos casos de uso pessoais e de pequenas equipes.

O fluxo completo com o Claude Code é: (1) construir o site localmente com o Claude; (2) criar um repositório no GitHub; (3) fazer push do código para o GitHub; (4) conectar o repositório ao Netlify; (5) o Netlify detecta automaticamente o tipo de projeto e faz o build; (6) a URL pública fica disponível. Passos 2 a 6 podem ser delegados completamente ao Claude Code.

Para variáveis de ambiente sensíveis (chaves de API, credenciais de banco de dados), o Netlify tem uma seção específica nas configurações do site onde você adiciona essas variáveis. Elas ficam disponíveis para o código em build time e runtime sem precisar estar expostas no código-fonte no GitHub.

Para backends, APIs, e scripts Python que precisam rodar como funções serverless acessíveis via URL, o Modal é a ferramenta ideal. O Modal se apresenta como “infraestrutura de IA que desenvolvedores adoram” — a proposta é implantar qualquer função Python como um endpoint web em segundos, sem configurar servidores.

Para começar com o Modal: (1) criar conta em modal.com (ou usar login Google); (2) completar o onboarding básico; (3) o Modal oferece 5 dólares em créditos gratuitos, com possibilidade de 30 dólares ao completar tarefas de onboarding. O custo do Modal é extraordinariamente baixo na prática — após meses de uso com um endpoint sendo acessado diariamente, o saldo ainda estava em aproximadamente 4,50 dólares.

Para integrar o Modal com o Claude Code, crie um token de API no painel do Modal e forneça-o ao Claude junto com as instruções de configuração. O claude.md pode ter instruções específicas sobre como usar o Modal que o Claude seguirá automaticamente.

O exemplo demonstrado no curso foi criar um endpoint que verifica se é o aniversário do usuário e retorna uma mensagem engraçada. A instrução foi: “crie um endpoint que retorne 'happy birthday nick' se for meu aniversário ou 'no birthday today mf' se não for”. Em menos de 2 minutos, um endpoint estava ao vivo em uma URL pública. Inicialmente requeria autenticação via curl, mas uma instrução adicional (“remova a autenticação e deixe acessível via browser com um simples GET”) resolveu isso em segundos.

O caso de uso mais poderoso é transformar skills em endpoints web. A skill de scraping de leads foi transformada em um formulário web: acessar a URL mostra um formulário com campos “tipo de lead”, “localização” e “quantidade”. O usuário preenche, clica em executar, e após alguns segundos faz o download de um CSV com os leads. Todo o processamento pesado (chamadas à API do scraper, enriquecimento de emails, formatação do CSV) acontece no servidor Modal.

Para automações mais complexas, os endpoints Modal funcionam como webhooks padrão. Qualquer plataforma que suporte webhooks — n8n, Make.com (anteriormente Integromat), Zapier, Lindy — pode disparar e receber dados de automações construídas com Claude Code. Isso cria uma ponte entre o poder do Claude Code e a facilidade de uso de plataformas no-code.

Um padrão de negócio valioso: construa a automação com Claude Code (que tem a inteligência para lidar com casos complexos), faça o deploy no Modal, e então conecte via webhook em uma plataforma no-code para orquestração de fluxo mais visual. Você obtém o melhor dos dois mundos: a inteligência do Claude Code e a facilidade de conexão do no-code.

## HOOKS — AUTOMAÇÃO DE EVENTOS E VALIDAÇÃO 1:51:59

Hooks são um recurso poderoso do Claude Code que permite executar scripts automaticamente em resposta a eventos específicos dentro do workflow do agente. São gatilhos: quando X acontece, execute Y automaticamente.

Os quatro hooks principais do Claude Code são:

**PreToolUse**: executado antes de qualquer tool call. Permite validar ou modificar o que o Claude está prestes a fazer. Por exemplo: antes de o Claude executar qualquer comando bash, verifique se o comando contém operações destrutivas (rm -rf, drop table) e bloqueie ou peça confirmação se contiver.

**PostToolUse**: executado depois de cada tool call. Útil para logging, monitoramento, ou pós-processamento de resultados. Por exemplo: após cada operação de escrita em arquivo, faça um commit automático no git com uma mensagem descritiva.

**UserPromptSubmit**: executado quando o usuário submete um prompt, antes de o Claude processá-lo. Permite adicionar contexto automático a cada mensagem. Por exemplo: automaticamente inclua o output de `git status` em cada prompt para que o Claude sempre saiba o estado atual do repositório.

**Notification**: executado quando o Claude envia uma notificação (como “aguardando resposta” ou “tarefa concluída”). Permite criar alertas ou ações em resposta.

Hooks são scripts Python, bash, ou qualquer linguagem que você queira, definidos no `settings.json`. O formato é simples:

```json

{

“hooks”: {

“PreToolUse”: [

{

“matcher”: “Bash”,

“hooks”: [

{

“type”: “command”,

“command”: “python3 /caminho/para/validador.py”

}

]

}

]

}

}

```

Um caso de uso prático e comum é o hook de segurança: antes de qualquer execução de bash, um script Python verifica se o comando contém padrões perigosos (como apagar diretórios inteiros, desabilitar autenticação, expor dados sensíveis). Se detectar, o hook pode bloquear a execução e solicitar confirmação explícita do usuário.

Outro hook muito útil é o de formatação automática: após qualquer escrita de arquivo Python, execute automaticamente `black` para formatar o código no estilo correto. Isso garante que todo código gerado pelo Claude sempre segue os padrões de estilo do projeto, sem precisar lembrar de pedir ao Claude para formatar.

O hook de logging é valioso para equipes: registre em um arquivo de log cada tool call que o Claude executa, com timestamp, tipo de tool, parâmetros, e resultado. Isso cria um audit trail completo de tudo que o agente fez durante a sessão — extremamente útil para debugging e para entender o que aconteceu em sessões longas.

Hooks também podem ser usados para injetar contexto dinamicamente. Um hook PreToolUse pode, antes de qualquer chamada, verificar se há novos arquivos no diretório de saída de uma etapa anterior e injetá-los no contexto. Isso cria pipelines automáticos onde a conclusão de uma etapa automaticamente alimenta a próxima.

Para equipes que usam o Claude Code em ambiente corporativo, hooks são a solução para compliance e governança. O hook de segurança pode verificar que nenhum dado sensível (como credenciais, dados de produção) está sendo lido ou enviado. O hook de logging garante auditabilidade. O hook de formatação garante consistência de código.

A configuração de hooks pode ser local (no `settings.json` do workspace) ou global (no arquivo de configuração do usuário). Hooks locais são ideais para regras específicas do projeto; hooks globais para convenções pessoais que você quer em todos os projetos.

## SELEÇÃO DE MODELOS E EXTENDED THINKING 1:52:33

Uma das configurações mais impactantes no Claude Code é a escolha do modelo. O Claude Code suporta múltiplos modelos da Anthropic com diferentes capacidades, velocidades, e preços. Fazer a escolha certa pode significar a diferença entre uma sessão de trabalho eficiente e cara versus uma que seja mais lenta mas mais econômica.

Para trocar de modelo, use o comando `/model` no Claude Code. Você verá uma lista dos modelos disponíveis. Os principais são:

**Claude Opus** (o modelo mais capaz): maior inteligência, melhor raciocínio complexo, mais adequado para tarefas que exigem julgamento sofisticado. Também o mais caro por token. Ideal para: planejamento arquitetural, debugging de problemas complexos, tarefas criativas que exigem nuance.

**Claude Sonnet** (o modelo de equilíbrio): muito capaz, context window maior que o Opus, significativamente mais barato. Ideal para: sub-agentes de execução, tarefas de pesquisa extensas que precisam ler muitos documentos, desenvolvimento de funcionalidades bem definidas.

**Claude Haiku** (o modelo mais rápido): menor latência, menor custo, adequado para tarefas simples e repetitivas. Ideal para: classificações em volume, transformações de dados estruturadas, tarefas com instruções muito bem definidas.

A estratégia recomendada é usar Opus como o “CEO” — para planejamento, síntese, e decisões complexas. Usar Sonnet para sub-agentes que executam tarefas bem definidas. Usar Haiku para operações de volume muito alto onde velocidade e custo importam mais que sofisticação.

O extended thinking (raciocínio estendido) é um modo especial disponível em alguns modelos que permite ao Claude “pensar em voz alta” antes de responder. Quando habilitado, o Claude usa tokens adicionais em uma “aba de pensamento” separada onde processa o problema, considera diferentes abordagens, avalia trade-offs, e chega a uma resposta mais fundamentada.

A aparente contradição do extended thinking — “mais tokens = mais caro” — se resolve quando você olha o resultado. Com extended thinking, o Claude normalmente dá respostas mais curtas e precisas na conversa principal porque já resolveu toda a complexidade internamente. Sem extended thinking, o Claude pode “pensar em voz alta” na conversa (o que consome tokens do contexto principal), tornando o contexto mais longo e futuras respostas mais caras.

Para configurar o extended thinking: vá em `/model`, procure a aba de “thinking”, e configure o orçamento de tokens. O mínimo recomendado é 8.000 tokens. Para problemas muito complexos (arquitetura de sistema, debugging de falhas sutis, decisões estratégicas), 16.000 a 32.000 tokens de thinking produzem resultados notavelmente melhores.

Um detalhe técnico importante: tokens de thinking são faturados de forma diferente dos tokens de conversação em alguns contextos. Verifique a documentação atual de preços da Anthropic para entender exatamente como está sendo cobrado.

O modo rápido (fast mode) mencionado no curso é o Claude Opus 4.6 com a capacidade de rodar em velocidade 2,5x pelo custo de aproximadamente 3x normal. Para situações onde tempo é dinheiro — como numa demonstração ao vivo ou quando você precisa iterar rapidamente — o fast mode elimina o tempo de espera que às vezes torna o Claude frustrante para uso intensivo.

Para verificar qual modelo está sendo usado em qualquer momento, olhe para a linha de status no terminal (se configurada) — ela exibe o modelo atual continuamente. Alternativamente, use `/model` para ver e trocar.

## FLUXO DE TRABALHO COMPLETO — DO CONCEITO AO DEPLOY 1:54:55

Depois de aprender todos os componentes individuais, é útil ver como eles se encaixam em um fluxo de trabalho completo. Um projeto típico vai desde a ideia inicial até o produto funcionando na internet, e cada etapa pode ser assistida pelo Claude Code de formas específicas.

**Fase 1: Exploração e Design (com screenshot loop)**

O ponto de partida não é código — é visão. Use o loop de screenshots descrito anteriormente: abra sites de referência, tire screenshots, cole no Claude com a instrução “quero algo com esse visual e sensação, mas para [meu caso de uso]”. O Claude cria protótipos visuais rapidamente, você dá feedback visual, e em 5-10 iterações você tem um design que realmente agrada.

**Fase 2: Planejamento (com plano mode)**

Para funcionalidades além de simples páginas estáticas, ative o modo plano: “antes de implementar, me dá um plano passo a passo do que você vai fazer”. Revise o plano. Identifique problemas antes que sejam escritas linhas de código. Ajuste a abordagem se necessário. Só depois aprove a execução.

**Fase 3: Implementação (com bypass permissions se necessário)**

Com o plano aprovado, a implementação pode ser acelerada com bypass permissions habilitado — o Claude executa sem pedir confirmação a cada passo. Para projetos simples, o agentic loop padrão é suficiente. Para projetos com muitos arquivos ou que requerem instalação de dependências, bypass é mais eficiente.

**Fase 4: Revisão de Qualidade (com sub-agentes)**

Após a implementação, spawn de um code reviewer sub-agent para olhar o código com olhos frescos, e um QA sub-agent para gerar e executar testes. Os problemas identificados são corrigidos pelo agente pai. Isso é especialmente importante para código que vai para produção.

**Fase 5: Iteração com Agent Teams (quando necessário)**

Se o resultado inicial não é satisfatório, use agent teams para explorar rapidamente múltiplas direções. Spawne 3-5 agents com abordagens diferentes, compare os resultados, escolha o mais promissor, e itere novamente. Esse processo de seleção rápida de variantes é onde agent teams entregam valor real.

**Fase 6: Deploy (com Netlify ou Modal)**

Sites estáticos vão para o Netlify em minutos. Backends e APIs Python vão para o Modal. Em ambos os casos, o Claude Code pode gerenciar o processo de deploy completo: criar o repositório GitHub, fazer push, configurar o serviço de hospedagem, e fornecer a URL final.

**Fase 7: Automação e Skills (para processos repetitivos)**

Se o que você construiu é algo que vai ser executado regularmente, transforme em uma skill. A skill documenta o processo, cria os scripts necessários, e permite executar tudo com uma única instrução nas próximas vezes. Se precisar de escala, converta a skill em endpoints Modal acessíveis via URL ou webhook.

Esse fluxo não é rígido — cada projeto tem suas particularidades. Mas entender os componentes e quando aplicar cada um é o que separa usuários básicos de usuários avançados do Claude Code. A chave é não tentar usar todos os recursos em todos os projetos: use o que o projeto realmente precisa, nada mais.

## CASOS DE USO DE NEGÓCIO E APLICAÇÕES PRÁTICAS 1:57:11

O valor do Claude Code vai muito além de programação. Para empreendedores, freelancers e profissionais que não são desenvolvedores, as possibilidades são extensas. A pergunta mais útil é: “o que eu faço repetidamente que consome meu tempo e poderia ser automatizado?”

**Cold email e prospecção**: o fluxo completo de scraping de leads, enriquecimento, personalização de emails e upload para plataformas de cold email pode ser transformado em um sistema semi-automatizado. A skill de scraping coleta os leads. Uma segunda skill ou endpoint Modal enriquece com informações adicionais da empresa. Uma terceira faz a personalização do email com base nas características de cada lead. O resultado sai pronto para ser importado no Instantly, Lemlist, ou similar.

**Pesquisa e análise**: para qualquer tarefa que envolva ler muito material e extrair insights — seja monitorar concorrentes, pesquisar um nicho antes de lançar um produto, ou preparar para uma reunião com um cliente potencial — a skill de literatura research ou um sub-agente de pesquisa pode fazer esse trabalho em minutos. Você define as fontes confiáveis, o Claude coleta e sintetiza.

**Geração de conteúdo personalizado**: assim como os websites personalizados para dentistas, qualquer tipo de asset de vendas pode ser gerado em escala. Propostas personalizadas, apresentações, relatórios, mensagens de follow-up — tudo com informações específicas do prospect inseridas automaticamente.

**Automação de tarefas administrativas**: labels de Gmail são o exemplo mais simples. Mas a mesma abordagem se aplica a: organizar pastas, renomear arquivos por convenção, extrair dados de PDFs e organizar em planilhas, sincronizar informações entre diferentes ferramentas via API.

**Análise de planilhas e dados**: para quem trabalha muito com Excel ou Google Sheets, o Claude Code pode ser um analista de dados. Descreva o que você quer entender sobre seus dados, forneça o arquivo (ou a URL de uma planilha Google), e o Claude escreve e executa o código necessário para produzir a análise ou visualização que você precisa.

**Monitoramento e alertas**: um cron job (tarefa agendada) que roda diariamente pode monitorar preços de concorrentes, verificar se um site ficou fora do ar, checar se novas avaliações foram deixadas no Google Maps, ou qualquer outra condição que seja importante para o negócio. Quando algo muda, um webhook dispara e você recebe uma notificação no Slack ou email.

**Onboarding de clientes**: uma skill de onboarding pode, a partir de informações básicas de um novo cliente, criar automaticamente: o espaço de trabalho no ClickUp, a pasta no Google Drive com a estrutura padrão do projeto, o contrato a partir de um template, o email de boas-vindas personalizado, e o primeiro rascunho do plano de projeto. O que antes levava horas de configuração manual agora leva minutos.

A mentalidade certa para identificar oportunidades de automação com Claude Code é: pense em termos de conhecimento que você tem e que poderia ser documentado como um checklist. Qualquer processo que você consegue explicar passo a passo para um assistente humano, você consegue transformar em uma skill. A grande vantagem é que a skill executa consistentemente, sem variação de qualidade entre diferentes dias ou diferentes executores.

## MODO PLANO E ESTRATÉGIA DE DESENVOLVIMENTO 1:59:14

O modo plano (plan mode) é um dos recursos mais subestimados do Claude Code para desenvolvimento de software. A ideia é simples: antes de escrever qualquer código, o Claude apresenta um plano detalhado do que vai fazer, e você aprova ou ajusta esse plano antes que qualquer mudança seja feita.

Para ativar o modo plano, use a combinação de teclas Shift+Tab no terminal, ou escreva explicitamente “use plan mode” na instrução. No modo plano, o Claude está em um estado de leitura: ele pode ler arquivos, analisar o código-base, pesquisar informações, mas não faz nenhuma modificação até você aprovar.

O output do modo plano é um documento estruturado que tipicamente inclui: (1) entendimento do problema; (2) arquivos que precisam ser modificados; (3) novos arquivos que serão criados; (4) a sequência de mudanças; (5) dependências e riscos potenciais. Para tarefas complexas, esse documento pode ter 10-20 itens detalhados.

O valor do modo plano se torna óbvio quando você compara duas abordagens. Sem modo plano, o Claude começa a implementar imediatamente e você só descobre que a abordagem está errada depois de 20 minutos de trabalho. Com modo plano, você identifica o problema no plano em 2 minutos e ajusta antes de qualquer código ser escrito.

Uma técnica avançada é combinar o modo plano com a instrução de fazer múltiplos planos alternativos: “antes de implementar, me dê três abordagens diferentes para resolver esse problema, com pros e contras de cada uma”. O Claude apresenta três estratégias diferentes, você escolhe a mais adequada para o seu contexto, e então a implementação segue essa estratégia específica.

Para o ciclo de desenvolvimento ideal em tarefas complexas:

1. **Você**: “Analisa o problema e me dá um plano detalhado”

2. **Claude**: apresenta o plano

3. **Você**: revisa, faz perguntas, ajusta o plano

4. **Você**: “Executa o plano conforme discutido”

5. **Claude**: implementa sem desviar do plano aprovado

6. **Você**: “Revise o código implementado e liste o que precisa ajuste”

7. **Claude**: critica o próprio trabalho com olhos frescos e sugere melhorias

Esse ciclo minimiza retrabalho e produz resultados muito mais alinhados com o que você realmente precisa. A tendência natural é pular direto para a implementação — resistir a isso e investir no planejamento paga dividendos enormes em projetos de qualquer tamanho.

O modo proposta (proposal mode) é uma variante do modo plano aplicada a projetos maiores. Em vez de um plano técnico, o Claude gera um documento de “proposta de projeto” completo que inclui: escopo, arquitetura sugerida, tecnologias recomendadas, estimativa de tempo de desenvolvimento, e próximos passos. Isso é especialmente útil quando você está pensando em construir algo novo e quer uma visão 360 graus antes de comprometer tempo.

A proposta de projeto gerada pelo Claude pode ser usada diretamente como base para uma conversa com um cliente ou stakeholder. Com linguagem clara e estrutura profissional, ela comunica o que será construído, como, e por quê — sem exigir que o desenvolvedor (você) escreva esse documento manualmente.

## SEGURANÇA E MELHORES PRÁTICAS 2:01:44

Trabalhar com um agente que tem acesso a arquivos, terminal, browser e APIs externas exige atenção à segurança. Não é para deixar você paralisado, mas para usar o poder disponível de forma consciente e responsável.

O princípio mais importante é o do menor privilégio: dê ao Claude apenas o acesso que ele realmente precisa para a tarefa em questão. Se está construindo um site estático, não é necessário ter MCPs de Gmail e ClickUp ativos — cada ferramenta adicional é uma superfície de risco adicional.

Os modos de permissão oferecem controle granular:

- **Modo default**: pergunta antes de qualquer operação potencialmente impactante

- **Modo auto-approve**: aprova automaticamente ações consideradas seguras

- **Bypass permissions**: aprovação máxima — use apenas quando você confia completamente no que o Claude vai fazer

Para sessões de desenvolvimento ativo onde você está acompanhando cada passo, o modo auto-approve é confortável. Para operações críticas como modificar banco de dados de produção ou enviar emails em massa, o modo default com confirmações é mandatório.

Nunca coloque credenciais, chaves de API, ou dados sensíveis diretamente no claude.md ou em arquivos de configuração que vão para o controle de versão. Use variáveis de ambiente ou arquivos `.env` (que devem estar no `.gitignore`). Quando precisar fornecer credenciais ao Claude, faça isso via terminal em uma única sessão, não em arquivos persistentes.

A revisão de código gerado é sempre recomendável antes de fazer deploy em produção. O Claude geralmente produz código funcional e seguro, mas erros acontecem — especialmente com lógica de autenticação, validação de entrada, e manipulação de dados sensíveis. O sub-agente code reviewer é exatamente para isso.

Para projetos em equipe, estabeleça convenções claras no claude.md sobre:

- Quais arquivos o Claude pode e não pode modificar

- Quais tipos de operações sempre requerem confirmação humana

- Como deve ser feito commit de mudanças geradas pelo Claude

- Qual o processo de code review antes de merge

O custo financeiro também é um aspecto de “segurança” — segurança do orçamento. Configure limites de gasto diário e mensal na conta da Anthropic. Para agent teams em particular, um limite de gasto diário de $50 é razoável para começar — permite explorar mas evita surpresas de fatura.

Logs e auditoria: para uso em negócios, considere configurar hooks que registrem todas as operações do Claude em um arquivo de log. Isso cria um registro de auditoria de tudo que foi feito, útil tanto para debugging quanto para compliance.

## RESUMO E PRÓXIMOS PASSOS 2:03:36

Este curso cobriu o Claude Code do zero ao avançado. Se você começou sem nenhum conhecimento de programação e acompanhou até aqui, agora tem todas as bases necessárias para começar a usar o Claude Code de forma produtiva para projetos pessoais, profissionais e de negócios.

Os conceitos fundamentais que merecem ser revisitados e praticados:

**Interface e configuração**: entender a diferença entre a GUI e o terminal, quando usar cada um, e como configurar o ambiente de desenvolvimento (VS Code, Cursor, ou qualquer IDE com integração ao Claude Code).

**Claude.md**: o arquivo mais importante do seu setup. Um bom claude.md é a diferença entre um Claude que produz resultados mediocres e um Claude que entende profundamente o contexto do seu projeto e entrega outputs de alta qualidade.

**Screenshot loop**: o método mais rápido para chegar a um design visual que você gosta. Tire screenshot, cole no Claude, itere. Repetir esse ciclo 5-10 vezes costuma produzir resultados profissionais.

**Modo plano + bypass permissions**: para projetos maiores, sempre planeje antes de implementar. Uma vez que o plano está aprovado, o bypass permissions acelera drasticamente a execução.

**Skills**: qualquer processo repetitivo que você faz regularmente merece virar uma skill. O investimento inicial de criar a skill se paga rapidamente em tempo economizado.

**MCPs**: use para prototipagem rápida de integrações. Se algo funciona via MCP, considere converter para uma skill com chamadas diretas à API para máxima eficiência.

**Sub-agentes e Agent Teams**: use com critério. Mais não é sempre melhor — mais agents significa mais tokens, mais custo, e mais complexidade. Use quando o paralelismo realmente importa.

**Deploy**: Netlify para estático, Modal para backend Python. Em ambos os casos, o Claude Code pode gerenciar o processo completo.

Para continuar aprendendo: a documentação oficial da Anthropic em docs.anthropic.com é constantemente atualizada com novos recursos e melhores práticas. O Twitter/X (e o Grok) são excelentes para acompanhar as últimas descobertas da comunidade sobre uso avançado do Claude Code. Procure por `@AnthropicAI` e pelo termo “Claude Code” no Twitter para ver o que usuários avançados estão construindo e descobrindo.

Se você quiser monetizar as habilidades aprendidas aqui — seja desenvolvendo para clientes, construindo produtos digitais, ou criando automações de negócio — existe uma trajetória bem definida. O primeiro passo é construir projetos reais que resolvam problemas reais, mesmo que pequenos. Esses projetos viram seu portfólio. O portfólio atrai seus primeiros clientes. Os primeiros clientes validam o modelo de negócio e permitem que você refine o processo.

O Claude Code não é mágica. É uma ferramenta extremamente poderosa que amplifica o que você já é capaz de fazer. Se você tem boas ideias, senso estético, habilidade de comunicação, e entendimento de problemas de negócio — tudo isso continua sendo seu diferencial. O Claude Code simplesmente remove a barreira técnica que antes impedia de transformar essas capacidades em produtos e serviços concretos.

Bom trabalho chegando até aqui. Agora é hora de construir.

## INSTALAÇÃO E CONFIGURAÇÃO INICIAL 2:05:28

Para começar a usar o Claude Code, o primeiro passo é ter uma conta na Anthropic com um plano pago. O Claude Code não está disponível no plano gratuito — é necessário o plano Pro ($17/mês nos EUA, aproximadamente $28 CAD) no mínimo. Para uso profissional intenso, os planos Pro, Max, Team ou Enterprise são todos adequados.

Após criar a conta em claude.ai, a instalação do Claude Code no computador é feita via linha de comando. Na documentação oficial em code.anthropic.com/docs, você encontra o comando de instalação específico para cada sistema operacional. Para macOS/Linux, é um comando `curl` que você cola no terminal. Para Windows PowerShell ou CMD, há variantes específicas.

O processo no macOS: abra o Terminal (pesquise “Terminal” no Spotlight ou Applications > Utilities), cole o comando de instalação, e pressione enter. A instalação demora alguns minutos. Quando concluída, o Claude Code está disponível globalmente no sistema — basta digitar `claude` em qualquer terminal para abrir.

No primeiro acesso, o Claude Code pedirá autenticação. Você pode fazer isso clicando no link que abre no navegador, ou usando o comando `claude /login`. Escolha a opção de usar sua assinatura existente (Pro/Max/Team) em vez da opção baseada em uso de API, que é mais cara para uso intenso.

Após a autenticação, a interface do terminal do Claude Code mostra: o logo do Claude Code (um pequeno ícone), a versão atual, o modelo em uso (ex: Claude Opus 4.6), o plano da conta (ex: claude-max), e o diretório de trabalho atual (a pasta em que o terminal está aberto). Essa última informação é crucial — o Claude Code opera dentro da pasta atual, então você precisa navegar para o projeto correto antes de abrir o Claude Code.

Para usuários que preferem uma interface gráfica (GUI), o Claude Code se integra perfeitamente com duas IDEs principais: Visual Studio Code (VS Code) e Cursor (anteriormente chamado de “Antigravity” no curso). Ambas são gratuitas para download.

A instalação do Claude Code no VS Code: abra o VS Code, clique no ícone de extensões (os blocos no menu lateral esquerdo), pesquise “Claude Code”, e instale a extensão oficial da Anthropic (identificada pelo ícone de verificação). Depois de instalar, o Claude Code aparece como um painel no lado direito da interface.

O Cursor (antigravity.google) é uma alternativa mais moderna, construída sobre a base do VS Code mas com foco muito maior em IA. A interface é visualmente mais limpa e tem algumas funcionalidades específicas para trabalho com IA que o VS Code padrão não tem. Para instalar o Claude Code no Cursor, o processo é idêntico ao do VS Code.

A principal vantagem de usar o Claude Code no terminal em vez da GUI é o acesso a funcionalidades avançadas. A linha de status customizável, certos comandos como `/status-line`, e algumas configurações de hooks só são possíveis via terminal. A GUI é mais amigável para iniciantes, mas o terminal é mais poderoso para usuários avançados.

Uma diferença importante entre a GUI e o terminal: na GUI, o Claude Code só vê o arquivo aberto na aba ativa do editor, a menos que você explicitamente forneça outros arquivos. No terminal, o Claude Code tem acesso a todos os arquivos no diretório de trabalho atual e pode navegar pela estrutura do projeto livremente. Para projetos complexos com múltiplos arquivos, trabalhar no terminal é mais eficiente.

Para verificar se a instalação foi bem-sucedida, abra um terminal em qualquer pasta e digite `claude --version`. Você deve ver a versão instalada. Se aparecer um erro “command not found”, pode ser necessário adicionar o caminho de instalação ao PATH do sistema — a documentação da Anthropic tem instruções específicas para cada sistema operacional.

## INTERFACE DO TERMINAL — ANATOMIA COMPLETA 2:09:00

O terminal do Claude Code tem uma anatomia específica que vale entender bem, mesmo que pareça intimidador no início. Uma vez familiarizado com cada elemento, a interface se torna extremamente intuitiva.

No canto superior esquerdo, fica o logo do Claude Code — um ícone que parece um caranguejo ou uma água-viva, dependendo de quem olha. Ao lado, o nome “Claude Code” e o número da versão atual. Abaixo, o modelo ativo (como “claude-opus-4-6”) e o plano da conta.

A informação mais importante na tela inicial é o diretório de trabalho atual. O Claude Code funciona dentro de um contexto específico de pasta — ele “vive” nessa pasta. Todos os arquivos que ele cria, lê ou modifica são por padrão relativos a essa pasta. Se você abrir o Claude Code na pasta `/Users/nick/projetos/meu-site/`, é aí que ele vai trabalhar.

O campo de entrada de texto fica na parte inferior da tela. É aqui que você digita suas instruções. Para enviar, pressione Enter. Para adicionar uma nova linha sem enviar (para instruções longas), pressione Shift+Enter.

A área de saída é a parte maior da tela, que mostra o histórico da conversa. Cada “turno” da conversa é claramente separado: suas mensagens aparecem com destaque diferente das respostas do Claude. As tool calls (quando o Claude executa comandos, lê arquivos, etc.) aparecem em caixas específicas com o nome da ferramenta e o resultado.

Os “thinking words” — os termos divertidos que aparecem enquanto o Claude está processando — incluem palavras como “finagling”, “processing”, “considering”, “rumpeting”, “cogitating”, e muitas outras. Esses termos têm um contador ao lado mostrando quantos segundos a operação está tomando. Também há um contador de tokens mostrando quantos tokens foram gerados até o momento.

Os modos de permissão são exibidos na parte inferior, com o modo atual em destaque. Ao pressionar Shift+Tab, você cicla entre os modos. Os modos disponíveis são:

- **Auto-approve** (padrão): o Claude pede confirmação antes de operações potencialmente impactantes

- **Edit automatically**: o Claude faz edições em arquivos sem pedir confirmação

- **Bypass permissions**: aprovação total de todas as operações (mais poderoso, use com discernimento)

- **Plan mode**: o Claude só lê e planeja, não faz modificações

A aba de “thinking” (pensamento) só aparece quando o extended thinking está ativo. Clicando nela, você pode acompanhar o raciocínio interno do Claude em tempo real — uma janela interessante sobre como o modelo está processando o problema antes de responder.

O botão de pausa (ícone de dois traços verticais) aparece durante execuções. Ele permite interromper o Claude no meio de uma operação. Isso é extremamente útil quando você percebe que a abordagem está errada ou precisa corrigir algo antes que o Claude continue. Após pausar, você pode dar novas instruções ou simplesmente cancelar a operação.

Na parte inferior, há também informações sobre o contexto atual: quantos tokens já foram usados e qual porcentagem isso representa da janela de contexto total. Essa barra de contexto é um indicador valioso para saber quando usar `/compact` ou `/clear`.

Comandos de barra (slash commands) são acessados digitando `/` — uma lista de todos os comandos disponíveis aparece automaticamente. Os mais importantes são: `/clear`, `/compact`, `/model`, `/cost`, `/context`, `/status-line`, `/memory`. Cada um tem sua função específica no gerenciamento da sessão.

## TRÊS ABORDAGENS PARA DESIGN DE SITES E APPS 2:11:42

Antes de construir qualquer coisa, é importante entender que existem três abordagens principais para o design de sites e aplicações com o Claude Code. Cada uma tem seus pontos fortes e é adequada para diferentes situações.

**Abordagem 1: Screenshot Loop (a mais recomendada)**

A abordagem de screenshot loop é a mais eficiente para criar designs visualmente atraentes. O processo: encontre um site de referência com um design que você ama (sites como godly.website, Awwwards, Dribbble são ótimas fontes de inspiração), tire um screenshot completo do site, forneça esse screenshot ao Claude Code junto com o CSS do site de referência, e peça para criar algo no mesmo estilo com o seu conteúdo.

Para tirar um screenshot completo de qualquer página web: abra o Chrome DevTools (Cmd+Shift+I no Mac, Ctrl+Shift+I no Windows), mude as dimensões para 1920x1080 (desktop padrão), pressione Cmd+Shift+P (Ctrl+Shift+P no Windows), e digite “screenshot” > selecione “Capture full size screenshot”. O Chrome vai fazer scroll pela página inteira e capturar tudo em um arquivo de imagem.

Como o arquivo de screenshot pode ser grande demais (acima de 10MB pode causar problemas), use um serviço como iloveimage.com para redimensioná-lo para 50-75% do tamanho original. O objetivo é um arquivo menor que 4-5MB mantendo qualidade visual suficiente para o Claude reconhecer os detalhes de design.

Com o screenshot pronto, copie também o CSS do site de referência (clique com botão direito em qualquer elemento da página, selecione “Copy > Copy Styles”). Cole o screenshot e o CSS no Claude Code com uma instrução como: “use essa referência visual e o CSS fornecido para criar um site para [minha empresa/projeto]. O conteúdo será diferente mas o estilo e sensação visual deve ser similar”.

O Claude Code vai gerar a primeira versão do site (geralmente 80% de similaridade visual), tirar um screenshot do que criou, comparar com o original, identificar as diferenças, e iterar. Em 5-10 iterações desse loop, o resultado é surpreendentemente próximo do original mas com todo o seu conteúdo.

**Abordagem 2: Dump de transcrição de voz**

Para quem pensa mais em termos de narrativa do que de design, a abordagem de dump de voz é muito eficaz. Use a ferramenta de transcrição de voz do sistema (no Mac, pressione a tecla Fn para ativar o ditado) e descreva verbalmente tudo que você quer no site: o propósito do negócio, o público-alvo, as seções que precisa, o tom de comunicação, exemplos de empresas similares, qualquer detalhe relevante.

Você fala muito mais rápido do que digita (≈200 palavras/minuto falando vs 50-70 digitando), então em 5 minutos de narração você pode fornecer ao Claude um briefing extremamente detalhado. O Claude Code é muito bom em extrair a intenção e estrutura de texto falado, mesmo com imperfeições.

A limitação dessa abordagem é que sem uma referência visual, os primeiros resultados são mais genéricos. É necessário mais iteração de feedback para chegar no look-and-feel desejado. Mas funciona muito bem para quem tem dificuldade de encontrar referências visuais ou prefere descrever tudo.

**Abordagem 3: Componentes de bibliotecas**

A terceira abordagem usa bibliotecas de componentes de UI como 21st.dev, shadcn/ui, ou Radix UI. Essas bibliotecas têm componentes pré-construídos visualmente impressionantes: botões animados, cards, formulários, navbars, e muito mais. Na maioria dessas bibliotecas, há um botão “Copy prompt” que copia a instrução necessária para o Claude reproduzir aquele componente exatamente.

O processo: você navega pela biblioteca, encontra um componente que gosta, copia o prompt, cola no Claude Code, e pede para integrá-lo ao seu projeto. O Claude instala as dependências necessárias, adapta o componente ao contexto do projeto, e o integra ao código existente.

A desvantagem dessa abordagem é que ela funciona melhor para projetos que usam frameworks como React, Vue, ou Next.js — para sites estáticos em HTML puro, pode ser mais complicado. Também há uma curva de aprendizado para entender quais componentes usar onde.

**Qual abordagem escolher?**

Para a maioria das pessoas começando, a abordagem 1 (screenshot loop) é a mais rápida para chegar a um resultado que realmente agrada. A abordagem 2 é boa como complemento — depois de ter um design base com o screenshot loop, use narração de voz para detalhar o conteúdo específico. A abordagem 3 é mais para quem já tem experiência com desenvolvimento frontend e quer componentes de qualidade profissional.

Dito isso, a melhor abordagem é a que funciona para você no projeto específico. Experimente as três e decida com base nos resultados que cada uma produz para o seu caso de uso.

## FILOSOFIA DE TRABALHO COM O CLAUDE CODE — O LOOP CORRETO 2:14:47

Uma das razões mais comuns pelas quais pessoas ficam insatisfeitas com o Claude Code é porque estão usando o loop errado. Entender a filosofia correta de trabalho transforma completamente os resultados que você obtém.

O loop incorreto (o que a maioria faz): instrução > execução > instrução > execução. Cada ciclo é apenas “me dê algo novo” sem permitir que o Claude verifique e melhore o próprio trabalho. O resultado é uma cadeia de mudanças incrementais onde o Claude nunca tem a chance de avaliar se o que produziu está realmente correto ou adequado.

O loop correto: instrução > execução > verificação > iteração. Após executar uma tarefa, o Claude deve ser capaz de tomar um screenshot (para trabalho visual), ler a saída, comparar com o objetivo, identificar gaps, e fazer melhorias automaticamente. Esse ciclo de auto-avaliação é o que separa o Claude Code básico do Claude Code avançado.

Para trabalho de design, o loop correto é explicitado no claude.md. Uma instrução no claude.md como: “quando produzir um design visual, tire um screenshot do resultado, compare com a referência, e itere autonomamente até alcançar pelo menos 90% de fidelidade” permite que o Claude opere em modo de melhoria contínua sem precisar de intervenção constante do usuário.

Para trabalho de código, o loop correto envolve testes. O Claude escreve código, executa os testes, lê os resultados, corrige os erros, e re-executa — tudo automaticamente. Um claude.md bem configurado pode instruir: “após qualquer modificação de código, execute o conjunto de testes completo e corrija qualquer falha antes de reportar que a tarefa está concluída”.

Para pesquisa e análise, o loop correto envolve verificação cruzada. O Claude não deve apenas apresentar a primeira informação que encontra. Deve buscar em múltiplas fontes, comparar, identificar contradições, e sintetizar um entendimento coeso antes de responder.

A chave para esse loop correto é o que o instrutor chama de “verify and refine” — verificar e refinar. O Claude tem a capacidade cognitiva para avaliar a qualidade do próprio trabalho. Mas essa capacidade só é ativada quando as instruções explicitamente pedem isso. “Faça X e depois avalie se X foi feito corretamente” produz resultados dramaticamente melhores do que simplesmente “faça X”.

Outro aspecto da filosofia correta é o escopo das instruções. Instruções muito amplas como “construa um site para minha empresa” resultam em outputs genéricos. Instruções específicas como “construa a seção de hero com: título em 72px bold, subtítulo em 20px, botão CTA em gradiente laranja, e uma imagem de fundo abstrata relacionada a IA” resultam em outputs muito mais próximos do que você realmente quer.

A balança ideal é: específico o suficiente para guiar a qualidade, mas aberto o suficiente para permitir que o Claude use sua criatividade e capacidades. Microgerenciar cada pixel é tão ineficiente quanto instruções vagas demais.

## DESENVOLVIMENTO PARALELO — MÚLTIPLOS AGENTES SIMULTÂNEOS 2:16:27

Uma das técnicas mais poderosas (e subutilizadas) do Claude Code é rodar múltiplas instâncias simultaneamente. Como o Claude Code opera dentro de uma janela do terminal ou aba da IDE, você pode literalmente abrir quantas abas quiser — cada uma com seu próprio Claude Code trabalhando em uma tarefa diferente ao mesmo tempo.

A mecânica é simples: abra uma segunda janela do terminal, navegue para o mesmo diretório de projeto (ou um diferente), e abra o Claude Code. Agora você tem dois agentes trabalhando em paralelo. Um pode estar refinando o design da página home enquanto o outro desenvolve a página sobre. Ambos progridem simultaneamente sem precisar que você fique alternando instruções.

O número ideal de instâncias simultâneas depende de dois fatores: sua capacidade de monitoramento e a natureza das tarefas. Para tarefas de design visual (onde você precisa avaliar screenshots periodicamente), 2-3 instâncias é o limite prático antes de você não conseguir acompanhar tudo. Para tarefas mais autônomas (como processamento de dados ou pesquisa), você pode ter mais instâncias já que elas precisam de menos supervisão.

O sistema de “chimes” (sons de notificação) mencionado no curso é uma solução elegante para o problema de monitoramento. Você configura um hook no Claude Code que toca um som específico quando uma tarefa é concluída. Som 1 = instância do canto superior esquerdo. Som 2 = instância do canto inferior direito. Quando você ouve o som, você sabe exatamente para onde olhar sem precisar verificar cada janela manualmente.

Para máxima eficiência com múltiplos agentes, a dica principal é garantir que cada agente esteja sempre trabalhando — nunca esperando suas instruções. Se você perceber que uma instância ficou parada por mais de 10-20% do tempo esperando input seu, você provavelmente tem instâncias demais abertas para gerenciar eficientemente.

A regra prática sugerida é: se você tem tarefas que são completamente independentes (página A e página B de um site), abra duas instâncias. Se as tarefas têm dependências (o design da página B depende de decisões tomadas na página A), trabalhe sequencialmente. A paralelização só ajuda quando as tarefas realmente podem ser feitas de forma independente.

Outro padrão de desenvolvimento paralelo é usar uma instância para construção e outra para revisão. Enquanto instância A constrói uma nova funcionalidade, instância B está revisando e testando o que foi construído anteriormente. Esse pipeline de “build + review em paralelo” é muito mais eficiente que o ciclo serial de build > esperar > review > build.

## A PASTA .CLAUDE — ESTRUTURA AVANÇADA DO WORKSPACE 2:19:15

A pasta `.claude` (com ponto na frente) é o centro nervoso do seu setup avançado do Claude Code. Em sistemas Unix (macOS, Linux), pastas que começam com ponto são ocultas por padrão no explorador de arquivos — você não as vê a menos que ative a visualização de arquivos ocultos. Isso é intencional: são arquivos de configuração que não devem poluir a visualização do projeto.

Dentro da pasta `.claude` de um workspace totalmente configurado, você encontra:

**`settings.json`**: arquivo de configurações gerais do projeto, incluindo permissões de hooks e outras configurações de comportamento. Por exemplo, aqui você configura quais hooks devem ser executados em quais eventos.

**`settings.local.json`**: versão local (não commitada no git) das configurações. Útil para credenciais e configurações pessoais que não devem ser compartilhadas com a equipe.

**`CLAUDE.md`**: o arquivo principal de instruções do projeto (pode estar aqui ou na raiz do projeto).

**`CLAUDE.local.md`**: versão local do CLAUDE.md, também ignorada pelo git. Ideal para instruções pessoais que só se aplicam à sua máquina.

**`/agents/`**: subpasta onde ficam as definições de sub-agentes. Cada arquivo Markdown aqui define um agente especializado que pode ser invocado.

**`/skills/`**: subpasta onde ficam as skills. Cada pasta dentro desta contém um `skill.md` e possivelmente uma pasta `scripts/`.

**`/rules/`**: subpasta para fragmentar o CLAUDE.md em regras modulares. Útil para projetos grandes onde diferentes pessoas podem precisar gerenciar diferentes seções das regras.

**`.mcp.json`**: arquivo de configuração de servidores MCP. Aqui ficam as definições dos MCPs instalados para este workspace específico.

A organização em regras modulares dentro de `/rules/` é uma prática recomendada para equipes. Em vez de um único CLAUDE.md monolítico com dezenas de seções, você fragmenta em arquivos separados:

- `code-style.md` — convenções de nomenclatura, formatação, estrutura de código

- `testing.md` — como escrever e rodar testes, cobertura mínima esperada

- `security.md` — checklist de segurança, coisas que nunca devem ser feitas

- `frontend.md` — padrões específicos de frontend, frameworks usados

- `deployment.md` — processo de deploy, branches, ambientes

Cada regra tem um “front matter” no início do arquivo que indica quando ela deve ser aplicada. Isso permite ao Claude Code carregar apenas as regras relevantes para a tarefa atual — por exemplo, carregar apenas as regras de segurança durante uma revisão de código de autenticação, sem precisar processar todas as regras de frontend que não são relevantes.

A hierarquia de contexto tem três níveis, ordenados do mais global ao mais local:

1. **Global** (`~/.claude/CLAUDE.md`): regras que se aplicam a TODOS os projetos. Suas preferências pessoais de código, atalhos que você sempre usa, instruções sobre seu estilo de trabalho.

2. **Por projeto** (`.claude/CLAUDE.md` ou `CLAUDE.md` na raiz): regras específicas do projeto. Contexto técnico, convenções da equipe, arquitetura do sistema.

3. **Enterprise** (gerenciado pela empresa para licenças enterprise): políticas corporativas, conformidade, restrições de segurança.

Quando o Claude Code inicializa, ele carrega todos os três níveis em ordem, com os mais específicos sobrescrevendo os mais gerais quando há conflito.

O comando `/init` é um atalho valioso para novos projetos. Ao digitar `/init` em um projeto sem CLAUDE.md, o Claude analisa todos os arquivos do diretório, entende a arquitetura, e gera automaticamente um CLAUDE.md contextualmente relevante. Esse arquivo gerado não é perfeito, mas é um ótimo ponto de partida que você pode refinar com o tempo.

A principal razão para ter um CLAUDE.md bem escrito vai além de “dar instruções ao Claude”. O CLAUDE.md reduz o número de tokens necessários por sessão porque elimina a necessidade do Claude ler todos os arquivos para entender o contexto. Em vez de ler 10 arquivos para descobrir que o projeto usa React com TypeScript, o CLAUDE.md informa isso em 2 linhas. Menos tokens = menor custo + melhor qualidade de raciocínio.

Boas práticas para o CLAUDE.md:

- Coloque as informações mais críticas (o que NUNCA fazer, a arquitetura central) no início

- Use bullet points e headings para alta densidade informacional

- Mantenha abaixo de 200-500 linhas — um CLAUDE.md de 10.000 palavras é contraproducente

- Revise e pode periodicamente — remova instruções desatualizadas

- Não cole documentação de APIs inteiras — referencie a documentação quando necessário

## REGRAS E MEMÓRIA AUTOMÁTICA 2:22:20

Além do CLAUDE.md e das regras em `/rules/`, o Claude Code tem um sistema de memória que pode ser usado para armazenar contexto persistente de forma mais granular.

O comando `/memory` abre a interface de gerenciamento de memória. A memória do Claude Code se divide em dois tipos:

**Memória de sessão**: existe apenas durante a conversa atual. Qualquer informação que você fornecer ao Claude nesta sessão fica disponível até você usar `/clear` ou fechar o terminal.

**Memória persistente**: sobrevive entre sessões. Você pode pedir ao Claude para “salvar isso em memória” ou “lembre-se disso para futuras sessões” e o Claude armazenará essa informação em um arquivo de memória que é carregado automaticamente em futuras sessões.

O sistema de memória automática (auto memory) funciona de forma inteligente: o Claude identifica padrões recorrentes nas suas interações e automaticamente sugere ou salva informações que parecem ser preferências consistentes do usuário. Por exemplo, se você sempre pede formatação de código em um estilo específico, o Claude pode sugerir salvar isso como uma memória persistente.

As informações salvas na memória ficam armazenadas em arquivos no diretório `~/.claude/` ou na pasta de memória do projeto. Esses arquivos são carregados como parte do contexto inicial de cada nova sessão, junto com o CLAUDE.md global e do projeto.

Para projetos de equipe, a memória pode ser segregada em:

- Memória pessoal (fica apenas na sua máquina, no `~/.claude/`)

- Memória do projeto (no `.claude/` do projeto, commitada no git e compartilhada com a equipe)

Uma dica prática: use a memória para armazenar coisas como “o projeto X usa o cliente Y para conexão com banco de dados” ou “sempre que trabalharmos em autenticação, lembre de verificar o middleware de rate limiting”. Isso cria um contexto acumulado que torna o Claude progressivamente mais eficiente em projetos de longo prazo.

O limite de memória é prático: não sobrecarregue o sistema com memorias longas e detalhadas. A memória deve ser concisa — algumas frases por item, não parágrafos inteiros. O objetivo é fornecer context o suficiente para o Claude conectar os pontos, não dumpar toda a documentação do projeto.

## CONSTRUINDO APLICAÇÕES COMPLEXAS — GERADOR DE PROPOSTAS 2:23:58

Para demonstrar o poder do Claude Code em projetos mais complexos, o curso mostra a construção de um gerador automático de propostas de negócio. Esse projeto vai além de um site estático — envolve backend, integração com APIs externas, e lógica de negócio real.

O problema que o gerador de propostas resolve: criar propostas personalizadas para clientes potenciais é um processo que costuma levar horas. Você precisa pesquisar sobre a empresa, entender o nicho, calcular preços, escrever o documento, formatar tudo. Com uma skill ou aplicação automatizada, esse processo pode ser reduzido para alguns minutos.

O fluxo do gerador de propostas é:

1. Usuário fornece o URL do site do potencial cliente (ou nome da empresa)

2. O sistema faz scraping do site para extrair informações relevantes (serviços, tamanho, setor)

3. Com base nas informações coletadas, gera uma proposta personalizada usando templates pre-definidos

4. Calcula preços baseados em parâmetros configuráveis (tamanho da empresa, complexidade estimada)

5. Formata tudo como um PDF ou página HTML profissional

Para construir isso com o Claude Code usando o modo plano primeiro: ativar plan mode, descrever o que o sistema deve fazer, e pedir ao Claude para propor a arquitetura. O Claude sugere tipicamente uma estrutura com: um script Python para scraping (usando requests + BeautifulSoup), um template HTML/CSS para a proposta, um módulo de lógica de preços, e um script de geração de PDF.

Após aprovar o plano, ativar bypass permissions e deixar o Claude construir. Em uma sessão típica de 20-30 minutos, o Claude Code cria todos os arquivos, instala as dependências, testa cada componente, e apresenta um sistema funcionando.

Um aspecto interessante desse projeto é como o Claude Code lida com problemas durante a construção. Por exemplo, se o site de um potencial cliente usa JavaScript para renderizar conteúdo (o que impede o scraping básico com requests), o Claude detecta o problema, pesquisa alternativas, implementa uma solução com Playwright ou Selenium, e continua. Esse auto-recovery de erros é onde o Claude Code realmente brilha.

Após o sistema básico estar funcionando, as iterações de melhoria são rápidas. Você pode pedir: “adicione suporte para incluir estudos de caso relevantes do nosso portfólio com base no setor do cliente” ou “gere também uma versão em formato LinkedIn DM para uso em outreach”. Cada pedido de melhoria é implementado em minutos.

O produto final — depois de algumas horas de desenvolvimento assistido por IA — é uma ferramenta que a equipe comercial pode usar diariamente, que personaliza propostas de forma convincente, e que economiza horas de trabalho por semana. E o código todo foi escrito pelo Claude Code, não por um desenvolvedor humano.

## COMANDOS SLASH — REFERÊNCIA COMPLETA 2:25:13

O Claude Code tem um sistema abrangente de comandos slash que cobrem todas as funcionalidades de gerenciamento de sessão. Digitar `/` abre uma lista interativa de todos os comandos disponíveis. Aqui está uma referência dos mais importantes:

**/clear**: limpa completamente o histórico da conversa atual. Útil quando você quer começar uma nova tarefa completamente não relacionada. Após um `/clear`, o contexto volta para praticamente zero tokens — apenas os arquivos de configuração base são mantidos.

**/compact**: comprime o histórico da conversa em um resumo de alta densidade informacional. Diferente do `/clear`, o `/compact` preserva o contexto mas de forma mais eficiente em tokens. Use quando o contexto está ficando longo mas você ainda precisa das informações da sessão.

**/compact [instrução]**: versão com instrução personalizada. Exemplo: `/compact priorize as decisões de arquitetura e os arquivos modificados, ignore os erros já resolvidos`. Dá ao Claude diretrizes sobre o que preservar com mais fidelidade no resumo.

**/model**: abre a interface de seleção de modelo. Permite trocar entre Claude Opus, Sonnet, e Haiku sem precisar reiniciar a sessão. Também mostra configurações de extended thinking (thinking mode).

**/cost**: exibe o custo em tokens (e às vezes em dólares) da sessão atual. Útil para monitorar o consumo antes de fazer operações pesadas.

**/context**: mostra um breakdown detalhado de quantos tokens estão sendo usados por cada componente: CLAUDE.md global, CLAUDE.md local, definições de ferramentas MCP, memória, histórico da conversa. Extremamente útil para entender onde os tokens estão indo.

**/status-line**: permite configurar a barra de status que aparece no terminal. Você pode customizar para mostrar porcentagem de contexto usado, modelo atual, branch git, custo acumulado, ou qualquer outra métrica.

**/memory**: acessa e gerencia a memória persistente. Permite ver o que está salvo, adicionar novas memórias, ou remover memórias antigas.

**/init**: analisa o diretório atual e gera automaticamente um CLAUDE.md contextualmente relevante. Use em projetos que ainda não têm um CLAUDE.md.

**/resume**: retoma a última sessão não finalizada. Útil quando uma sessão foi interrompida inesperadamente.

**/login**: autentica ou re-autentica com a conta Anthropic. Necessário na primeira instalação ou quando o token de autenticação expira.

**/logout**: desloga da conta atual. Útil ao mudar entre contas diferentes.

**/help**: exibe a lista completa de comandos disponíveis com breve descrição de cada um. A referência mais atualizada sempre disponível diretamente no Claude Code.

Para navegar pelo histórico de sessões: nas configurações do Claude Code, há uma opção para ver todas as sessões anteriores. Você pode retomar qualquer sessão anterior — o contexto é preservado exatamente como estava quando a sessão terminou.

## MODOS DE PERMISSÃO — DO MAIS SEGURO AO MAIS PODEROSO 2:27:06

O Claude Code opera em diferentes modos de permissão que determinam o quanto ele pode fazer autonomamente. Entender cada modo e quando usar cada um é fundamental para trabalhar com eficiência e segurança.

**Modo Default — “Ask before edits”**: o modo mais conservador. Antes de fazer qualquer modificação em arquivos, o Claude pede confirmação explícita. Você vê exatamente o que ele quer fazer e pode aprovar, rejeitar, ou pedir modificações. O ícone de limite da sessão fica em azul claro na GUI.

Quando usar: quando você está explorando um novo codebase pela primeira vez, quando está aprendendo como o Claude funciona, ou quando está trabalhando em código crítico de produção onde você quer supervisionar cada mudança.

**Modo Auto-approve — “Edit automatically”**: o Claude faz edições em arquivos diretamente sem pedir confirmação a cada passo. Ele ainda pode pedir confirmação para operações mais drásticas (como deletar arquivos ou executar comandos que afetam o sistema).

Quando usar: para sessões de desenvolvimento ativo onde você está acompanhando o progresso. É o equilíbrio entre segurança e velocidade para a maioria das tarefas do dia-a-dia.

**Modo Bypass Permissions — “Dangerously skip permissions”**: aprovação completa de todas as operações sem confirmação. O Claude pode criar, modificar, deletar arquivos, executar comandos no terminal, instalar pacotes, e fazer praticamente qualquer coisa automaticamente. O ícone fica vermelho para indicar que está no modo mais permissivo.

Quando usar: quando você confia completamente no que o Claude vai fazer (porque você planejou explicitamente a tarefa), quando está em sessões de desenvolvimento intenso onde interrupções constantes quebram o fluxo, e quando você está em uma sessão de testes onde quer que o Claude iterate rapidamente.

Quando NÃO usar bypass: em repositórios de produção sem backup, quando há credenciais ou dados sensíveis no diretório, quando você não tem certeza do que o Claude vai fazer.

Para alternar entre modos: pressione **Shift+Tab** no terminal para ciclar pelos modos. Na GUI (VS Code, Cursor), clique no indicador de modo no canto inferior esquerdo.

**Plan Mode**: modo especial onde o Claude só lê e analisa — não faz nenhuma modificação. Ideal para planejar antes de implementar. Ative com Shift+Tab ou escrevendo explicitamente “use plan mode” na instrução.

A configuração de modos pode ser feita via CLAUDE.md para estabelecer um comportamento padrão. Por exemplo, você pode especificar: “sempre use plan mode para qualquer tarefa que envolva modificar mais de 3 arquivos” ou “para tarefas de refatoração, sempre peça confirmação antes de deletar código existente”.

## DESENVOLVIMENTO DE PRODUTO COM IA — ESTRATÉGIAS AVANÇADAS 2:29:30

Quando o objetivo vai além de “fazer um site” e entra em “construir um produto real com backend, banco de dados, e lógica de negócio complexa”, o Claude Code mostra seu verdadeiro potencial — mas também requer uma abordagem mais estratégica.

**Começando com a arquitetura correta**

O maior erro em projetos de produto com Claude Code é começar a codificar antes de ter uma arquitetura clara. Uma sessão de 30 minutos de planejamento no início economiza dias de retrabalho. Use o modo plano para uma sessão dedicada de arquitetura: “Quero construir um sistema de [descrição do produto]. Me ajude a definir a arquitetura, escolher as tecnologias, e identificar os principais componentes antes de escrever qualquer código.”

O resultado dessa sessão deve ser um documento de arquitetura com: escolha de stack tecnológico com justificativas, diagrama de entidades e relacionamentos, fluxos principais de usuário, identificação de dependências externas (APIs, serviços), e uma estimativa de complexidade por componente.

**Stack recomendado para não-programadores**

Para projetos que precisam de backend mas você não tem experiência com desenvolvimento: Python com FastAPI para o backend (simples, bem documentado, ótima integração com IA), SQLite ou PostgreSQL para banco de dados (SQLite para projetos simples, PostgreSQL para projetos que vão escalar), e HTML/CSS/JS puro ou um framework simples para frontend. O Claude Code é muito bom com essa stack e raramente tem problemas para encontrar soluções.

Evite começar com stacks complexas como Next.js + TypeScript + Prisma + tRPC se você é iniciante — a complexidade acidentald de configuração pode consumir horas que deveriam ser gastas construindo funcionalidades.

**TDD com Claude Code — Test Driven Development**

O TDD (desenvolvimento guiado por testes) é a melhor prática para garantir qualidade quando trabalhando com Claude Code. O ciclo é: (1) escreva o teste que descreve o comportamento esperado; (2) o teste falha porque a funcionalidade não existe; (3) implemente a funcionalidade; (4) o teste passa; (5) refatore se necessário.

O Claude Code pode escrever os testes por você: “escreva os testes unitários para a função que calcula o desconto progressivo baseado no volume de compra. Não implemente a função ainda, apenas os testes.” Com os testes escritos e falhando, você então pede a implementação.

**Iteração e debugging**

Quando algo não funciona como esperado, a abordagem mais eficiente é: copie o erro completo (incluindo o stack trace), cole no Claude Code com o contexto “esse erro está ocorrendo quando faço X, que é o comportamento Y que estou tentando alcançar”. O Claude Code é excelente em debugging quando tem o erro completo e o contexto do que deveria acontecer.

Para bugs difíceis de reproduzir, peça ao Claude para adicionar logging detalhado primeiro: “adicione logs em cada etapa desse fluxo para que eu possa ver exatamente onde o processo está falhando”. Com os logs, o debugging se torna muito mais direto.

**Segurança de dados em projetos reais**

Para qualquer projeto que lida com dados de usuários reais, configure desde o início: variáveis de ambiente para credenciais (nunca hardcoded), validação de entrada em todas as APIs, autenticação antes de qualquer operação de escrita, e backups regulares. Peça ao Claude para implementar esses controles explicitamente: “antes de implementar o endpoint de criação de usuário, me dê um checklist de segurança que devemos seguir e implemente cada item”.

## DICAS AVANÇADAS DE CONTEXTO E TOKENS — GUIA COMPLETO 2:31:26

A gestão de contexto e tokens é provavelmente o skill mais importante para uso avançado do Claude Code. Aqui está um guia consolidado com as principais estratégias, reunindo as melhores práticas documentadas pela Anthropic e descobertas pela comunidade.

**Estratégia 1 — RAG (Retrieval Augmented Generation)**

RAG é a técnica de buscar informações relevantes antes de fazer uma pergunta, em vez de carregar todas as informações no contexto. Em vez de colocar 10 arquivos inteiros no CLAUDE.md, você mantém um índice e usa scripts de busca para encontrar e carregar apenas os trechos relevantes para cada tarefa.

Na prática com Claude Code: em vez de colar a documentação inteira de uma API no contexto, você pede ao Claude para “buscar na documentação da API do ClickUp o endpoint específico para criar tarefas” — o Claude usa ferramentas de busca para encontrar apenas o trecho relevante.

**Estratégia 2 — Compressão contínua do CLAUDE.md**

O CLAUDE.md tende a crescer ao longo do tempo à medida que você adiciona instruções novas. Periodicamente (a cada 2-3 semanas), revise e comprima: remova instruções que o Claude já internalizou, consolide regras similares, e converta regras detalhadas em skills (que são carregadas on-demand).

**Estratégia 3 — Instruções de concisão estratégica com extended thinking**

Inclua no CLAUDE.md: “escreva respostas de forma sucinta e direta. Raciocine internamente tanto quanto precisar (isso não afeta o contexto), mas quando apresentar resultados, seja conciso.” Com extended thinking ativo, o Claude raciocina extensivamente internamente mas produz outputs curtos e densos, reduzindo o tamanho do histórico da conversa.

**Estratégia 4 — Escolha de modelo por tarefa**

Mapeie explicitamente qual modelo usar para cada tipo de tarefa:

- Análise de arquitetura e decisões complexas: Opus

- Implementação de funcionalidades bem definidas: Sonnet

- Classificações e transformações de dados em volume: Sonnet ou Haiku

- Research e scraping de documentação longa: Sonnet (contexto maior)

**Estratégia 5 — Gestão de overhead de MCP**

Quando as descrições de ferramentas MCP excedem 10% do contexto, o Claude Code ativa automaticamente a busca lazy de ferramentas. Mas você pode ser proativo: desative MCPs que não usa no projeto atual, prefira skills sobre MCPs para operações repetitivas, e use o `/context` regularmente para monitorar quanto os MCPs estão consumindo.

**Estratégia 6 — Migração de instruções para skills**

Qualquer instrução no CLAUDE.md que seja mais uma receita passo-a-passo do que uma regra geral deve virar uma skill. Regras gerais ficam no CLAUDE.md (“use Python 3.11+”). Receitas vão para skills (“para rodar o pipeline de análise: passo 1, passo 2, ...”). Skills são carregadas on-demand, economizando tokens em todas as sessões onde você não precisa dela.

**Estratégia 7 — Planejamento front-loaded**

O planejamento consome poucos tokens mas economiza muitos. Uma sessão de planejamento de 5 minutos com extended thinking pode evitar 50 minutos de implementação e retrabalho. A regra: para qualquer tarefa que envolva mais de 3 arquivos ou mais de 30 minutos de trabalho estimado, sempre planeje primeiro.

**Estratégia 8 — Prompts específicos e focados**

“Melhore esse código” → muitos tokens, resultado genérico

“No arquivo auth.py, função `validate_token()`, adicione verificação se o token está na lista negra antes de decodificar o JWT” → poucos tokens, resultado preciso

A especificidade não é apenas sobre qualidade — é sobre economia. Quanto mais específico o prompt, menos o Claude precisa explorar possibilidades, e menos tokens são gastos no raciocínio.

**Estratégia 9 — Agent teams e tokens**

Agent teams custam aproximadamente 7x mais tokens do que uma sessão única porque cada agente tem seu próprio contexto completo. Use apenas quando o benefício de paralelização justifica o custo. Para a maioria das tarefas, um único agente com sub-agentes bem definidos é mais econômico.

**Estratégia 10 — Sessões curtas e focadas**

Sessões longas acumulam contexto de decisões e erros anteriores que podem enviesar respostas futuras. Para projetos longos, prefira múltiplas sessões curtas focadas em um componente cada, com um CLAUDE.md que preserve o contexto de decisões arquiteturais importantes.

## CASO DE ESTUDO — AGÊNCIA DE AUTOMAÇÃO DE IA 2:34:24

Para contextualizar tudo que foi abordado no curso, é útil ver como todas essas ferramentas se combinam em um negócio real. O instrutor gerencia múltiplas empresas com faturamento conjunto superior a $4 milhões anuais usando principalmente Claude Code. Aqui está uma visão de como isso funciona na prática.

**O modelo de negócio**

A Left Click é uma agência de automação de IA que instala sistemas de crescimento em empresas B2B. Os clientes são agências, empresas de SaaS, e negócios de serviços profissionais que querem automatizar aquisição de clientes, processos internos, ou ambos.

O trabalho para cada cliente envolve: diagnóstico de processos manuais que podem ser automatizados, design de workflows de automação, implementação com as ferramentas certas (n8n, Make.com, Zapier para no-code; Python + Claude Code para soluções customizadas), e monitoramento contínuo.

**Como o Claude Code se encaixa**

Prospecção: a skill de scraping de leads coleta 1.000 prospects em menos de 2 minutos. A skill de website personalizado gera um site customizado para cada prospect em 30 segundos. Isso é enviado como “lead magnet” — um presente inesperado que demonstra capacidade técnica e inicia conversas.

Proposta: quando um prospect demonstra interesse, a skill de gerador de proposta cria automaticamente uma proposta personalizada com base no tamanho da empresa, setor, e desafios identificados. Em vez de horas de trabalho manual, leva minutos.

Onboarding: ao confirmar um cliente, a skill de onboarding cria automaticamente todos os espaços de trabalho, documentos, e configurações iniciais.

Entrega: automações construídas com Claude Code + skills são mais robustas que automações no-code porque lidam com exceções de forma inteligente. Quando algo dá errado, o Claude Code detecta e corrige — o no-code simplesmente para.

Relatórios: a skill de compilação de relatórios analisa os dados de todas as automações rodando para clientes e gera relatórios de ROI mensais. O que levaria um dia de trabalho agora é automatizado.

**A lição central**

O Claude Code não substitui julgamento humano — ele amplifica a capacidade de executar. As decisões estratégicas, a leitura de clientes, a identificação de oportunidades, a comunicação — tudo isso ainda é humano. O que mudou é que cada decisão estratégica se traduz em execução 10-100x mais rápida.

Você não precisa de uma equipe de 10 pessoas para executar o trabalho que antes exigia 10 pessoas. Você precisa de boas habilidades de pensamento, experiência na área em que você atua, e domínio das ferramentas que o Claude Code oferece. As pessoas que entenderem isso cedo têm uma vantagem enorme nos próximos anos.

## ANÁLISE DO TRANSCRIPT ORIGINAL — O QUE FOI ABORDADO NO CURSO 2:36:43

Este é um curso de 4 horas sobre Claude Code criado por Marco Fernández (Nick Sarayev), um empreendedor canadense que usa Claude Code para gerenciar negócios gerando mais de $4 milhões anuais em lucro. O curso foi originalmente gravado em inglês e é voltado tanto para iniciantes absolutos quanto para usuários intermediários que querem dominar funcionalidades avançadas.

A progressão do curso segue uma estrutura lógica de fundamentos para avançado:

**Parte 1 — Fundamentos (0:00 - 1:00)**

- O que é Claude Code e por que ele é transformador

- Como assinar e instalar Claude Code

- A anatomia da interface do terminal

- IDEs: VS Code e Cursor/Antigravity

- Comparação GUI vs terminal

**Parte 2 — Construção prática (1:00 - 2:00)**

- O papel do CLAUDE.md como “cérebro do workspace”

- Três abordagens de design (screenshot loop, voice dump, componentes)

- Loop de verificação: por que AI precisa verificar o próprio trabalho

- Desenvolvimento paralelo com múltiplas instâncias

- A pasta .claude e sua estrutura avançada

- Regras, memória automática, e sub-agentes básicos

- Modos de permissão e quando usar cada um

- Modo plano para projetos complexos

- Construção de aplicação completa: gerador de propostas

**Parte 3 — Contexto e otimização (2:00 - 2:30)**

- Compactação manual e automática

- Estratégias para reduzir context rot

- Comandos `/compact`, `/clear`, `/cost`, `/context`

- Linha de status customizável

- Seleção de modelo e extended thinking

**Parte 4 — Skills e automação (2:30 - 3:15)**

- O que são skills e por que são economicamente valiosas

- Estrutura de uma skill: skill.md + scripts/

- Demo ao vivo: skill de scraping de 1.000 leads em 87 segundos

- Criação de skill ao vivo: website personalizado por cliente

- MCP: o que é, onde encontrar, como instalar

- Diferença entre MCP e skills (custo em tokens)

- Chrome DevTools MCP: o MCP mais valioso

- ClickUp MCP: instalação e uso

- Gmail MCP → conversão para skill

- Plugins do Claude Code

**Parte 5 — Agentes e times (3:15 - 4:00)**

- Sub-agentes: como funcionam, casos de uso

- Demo: classificação de emails com sub-agentes em paralelo

- Sub-agentes vs agent teams

- Agent teams: habilitação, uso, custos

- Demo: geração de websites com 3 agentes em paralelo

- Demo: iteração de design com múltiplas rodadas de agents

- Demo: análise de segurança em repositório open source com 10+ agents

- Git worktrees para desenvolvimento sem conflitos

- Deploy com Netlify e Modal

- Conclusão e próximos passos

O curso é notável pela quantidade de demonstrações ao vivo em tempo real. Ao longo das 4 horas, o instrutor não apenas explica os conceitos mas os executa em frente à câmera, mostrando tanto os sucessos quanto os problemas que surgem no caminho. Isso torna o conteúdo muito mais aplicável do que tutoriais teóricos.

## PERGUNTAS FREQUENTES E DÚVIDAS COMUNS 2:39:12

Após ensinar Claude Code para mais de 2.000 alunos, o instrutor identifica padrões de dúvidas que surgem repetidamente. Aqui estão as mais comuns com respostas diretas.

**P: Preciso saber programar para usar Claude Code?**

R: Não. O curso demonstra isso explicitamente — sites completos, backends funcionais, e automações de negócio foram construídos em frente à câmera sem que o instrutor escrevesse uma única linha de código manualmente. O que você precisa é de clareza sobre o que quer construir e comunicação clara com o Claude. Ter noções básicas de lógica (if/then, loops, funções) ajuda a entender o que o Claude está fazendo, mas não é requisito.

**P: Claude Code vai substituir desenvolvedores?**

R: Para a maioria das tarefas de desenvolvimento de software, o Claude Code já pode executar o que um desenvolvedor júnior faria — e mais rápido. Para arquitetura de sistemas complexos, decisões de negócio embutidas em código, segurança em nível enterprise, e performance crítica, a experiência humana ainda é essencial. A visão mais realista é que o Claude Code multiplica a produtividade de desenvolvedores existentes e democratiza a construção de software para não-desenvolvedores.

**P: Quanto custa usar Claude Code intensamente?**

R: O plano Pro ($17/mês) inclui créditos para uso normal. Para uso intenso com agent teams ou muitas sessões longas diárias, pode ser necessário o plano Max ou consumo via API. O instrutor menciona gastar $173 adicionais além da assinatura em uma sessão intensa de demonstração que incluiu agent teams com dezenas de agents. No uso diário normal (sem agent teams), o plano Pro geralmente é suficiente.

**P: O que acontece quando o Claude comete erros?**

R: Erros acontecem — essa é a realidade. A questão é como o sistema lida com eles. Quando o Claude comete um erro em código, geralmente detecta o problema ao testar, diagnostica a causa, corrige, e continua. O usuário só precisa intervir quando o erro está além da capacidade de auto-correção do Claude (o que é raro para problemas comuns). Para projetos críticos, o ciclo de code review com sub-agentes é a melhor proteção.

**P: Posso usar Claude Code para projetos comerciais?**

R: Sim. Os termos de serviço da Anthropic permitem uso comercial. O instrutor usa Claude Code para negócios que geram $4M+ anuais sem restrições. É responsabilidade do usuário revisar o código gerado antes de colocar em produção, especialmente para aspectos de segurança e privacidade.

**P: Como lidar com projetos muito grandes?**

R: Use git worktrees para dividir o trabalho em branches independentes, agent teams para paralelizar análise e desenvolvimento, e sesões focadas em componentes específicos. O CLAUDE.md deve documentar as decisões arquiteturais importantes para que o contexto seja preservado entre sessões.

**P: Claude Code funciona em Windows?**

R: Sim, mas com algumas limitações. O Claude Code tem melhor suporte nativo para macOS e Linux. No Windows, o uso via WSL2 (Windows Subsystem for Linux) é muito mais robusto do que usar diretamente no CMD ou PowerShell. A instalação e uso básico funcionam bem no Windows, mas algumas funcionalidades avançadas (especialmente hooks e certas integrações de terminal) funcionam melhor no ambiente Unix.

**P: Como manter skills atualizadas quando as ferramentas mudam?**

R: As skills têm um mecanismo de auto-atualização: quando o Claude detecta que uma parte da skill falhou por uma mudança na API ou ferramenta, ele corrige o script e atualiza a skill para que a próxima execução não tenha o mesmo problema. Para mudanças maiores, você pode pedir ao Claude para revisar e atualizar uma skill específica.

## CONSTRUINDO O GERADOR DE PROPOSTAS — PASSO A PASSO DETALHADO 2:41:20

O gerador de propostas é o projeto mais complexo demonstrado no curso. É uma aplicação web completa com: autenticação de usuários, dashboard, integração com IA para geração de conteúdo, assinatura eletrônica, processamento de pagamentos via Stripe, e banco de dados na nuvem (Supabase). Construir isso de forma tradicional levaria semanas ou meses. Com Claude Code em modo plano + bypass permissions, levou cerca de 30-40 minutos.

**A especificação inicial**

O processo começa não com código, mas com uma especificação em linguagem natural criada via narração de voz. A especificação foi narrada em tempo real e incluiu:

- Quero um sistema similar ao PandaDoc ou DocuSign

- Os usuários devem poder fazer login com conta própria

- Devem poder criar novas propostas preenchendo um formulário simples

- A IA deve gerar o conteúdo da proposta baseado nas informações fornecidas

- Clientes recebem um link público para ver, assinar e pagar

- Design limpo e minimalista no estilo Apple

- As propostas devem seguir um template predefinido em PDF

Essa especificação foi fornecida ao Claude em modo plano (para que ele analisasse sem fazer nada), e o Claude fez perguntas de esclarecimento em um formato interativo elegante:

- “Qual framework de frontend você prefere?” — com opções

- “As assinaturas eletrônicas precisam ser legalmente robustas ou simplificadas?”

- “Os preços são fixos ou variáveis por proposta?”

Cada resposta refinou o plano sem consumir tempo com implementações erradas.

**O documento de plano gerado**

Após as perguntas de esclarecimento e análise do template de proposta em PDF fornecido, o Claude gerou um documento de plano completo com:

- Stack tecnológico detalhado: Next.js (frontend), Supabase (banco de dados + autenticação), Stripe (pagamentos), Tailwind CSS + shadcn/ui (design)

- Mapeamento de todas as páginas: login, dashboard, nova proposta, visualização de proposta, assinatura, pagamento

- Schema do banco de dados com todas as tabelas necessárias

- Rotas de API necessárias

- Estrutura de arquivos do projeto

- Fluxo completo de usuário, da criação à assinatura e pagamento

Esse plano serviu como a “planta” da construção. Com o plano aprovado, o Claude teve um guia claro para trabalhar, o que reduziu exploração desnecessária de abordagens alternativas.

**A fase de construção**

Com o modo trocado de plano para bypass permissions, o Claude começou a construir. Em paralelo, o instrutor completou duas tarefas necessárias: criar uma conta no Supabase e criar um projeto de banco de dados, e criar uma conta de sandbox no Stripe para testes de pagamento.

O Claude solicitou as credenciais necessárias (chaves de API do Supabase e do Stripe) através de mensagens no chat. Elas foram fornecidas e o Claude as incorporou nos arquivos de configuração automaticamente.

Após cerca de 7-8 minutos de construção autônoma, o Claude apresentou uma lista de ações pendentes do usuário: fornecer o URL do projeto Supabase, rodar um SQL de migração no Supabase SQL Editor, configurar um webhook no Stripe. Para usuários não-técnicos, cada item veio com instruções explícitas de onde encontrar e o que fazer.

**Testando e iterando**

O produto inicial funcionou. Login criou uma conta no Supabase. Dashboard apareceu. Criar nova proposta abriu um formulário com campos para: nome do cliente, email, serviços, preço, e uma descrição da necessidade do cliente. Após preencher e clicar em “Gerar Proposta”, o Claude Opus foi chamado via API para gerar o conteúdo completo da proposta baseado nas informações fornecidas.

As iterações necessárias foram menores do que o esperado:

1. Confirmação de email após cadastro estava mostrando erro sem mensagem amigável — corrigido com uma única instrução

2. Botão “Gerar Proposta” sem feedback visual sobre o progresso — corrigido para mostrar loading state

3. Design da proposta gerada precisava de refinamento — ajustado com feedback visual

O produto final tem uma proposta gerada automaticamente com: logo da empresa, seções estruturadas (problema, solução, por que nós, equipe, investimento, contrato), assinatura eletrônica canvas, e botão de pagamento via Stripe. O cliente recebe um link único e pode assinar e pagar diretamente naquela página.

**Lições aprendidas do projeto**

A lição mais importante: o valor do modo plano é incalculável para projetos complexos. A fase de planejamento durou menos de 10 minutos mas eliminou potencialmente horas de retrabalho. Cada decisão sobre a arquitetura (qual banco de dados, qual framework, como estruturar as tabelas) foi feita no plano — não descoberta dolorosamente no meio da implementação.

A segunda lição: você não precisa entender o código gerado para dirigir o desenvolvimento. O instrutor explicitamente disse “não sei o que isso significa” várias vezes ao ver termos técnicos, mas isso não impediu de entregar um produto funcional. O que importa é saber o que o produto deve fazer, não como está implementado.

A terceira lição: o Claude lida bem com o ambiente imperfeito. Credenciais faltando, SQLs que precisam ser rodados manualmente, configurações de webhook — cada obstáculo foi detectado e comunicado claramente, com instruções específicas de como resolver.

## DEPLOY DO GERADOR DE PROPOSTAS — DO LOCAL AO LIVE 2:45:41

Depois de ter o projeto rodando localmente e validado, o próximo passo é publicar na internet. Para o gerador de propostas (uma aplicação Next.js com Supabase), o deploy foi feito no Netlify.

O processo de deploy com Claude Code:

1. **Preparação do repositório**: o Claude Code verifica se o projeto tem um `.gitignore` adequado (para garantir que credenciais e arquivos temporários não sejam commitados), inicializa o git se necessário, e faz o primeiro commit com uma mensagem descritiva.

2. **Criação do repositório no GitHub**: via linha de comando (`gh repo create`) ou instrução ao Claude (“crie um novo repositório público no GitHub chamado proposal-generator-app”). O Claude gerencia todo o processo.

3. **Push inicial**: o Claude faz o push do código para o GitHub e confirma que tudo foi enviado corretamente.

4. **Configuração no Netlify**: ao conectar o repositório GitHub ao Netlify, o sistema detecta automaticamente que é um projeto Next.js e configura o build automaticamente. As variáveis de ambiente (chaves do Supabase, Stripe, Anthropic) são adicionadas nas configurações do site no Netlify.

5. **Deploy automático**: após a configuração, qualquer push para o branch main dispara automaticamente um novo deploy no Netlify. Em menos de 2 minutos, a versão mais recente está ao vivo.

O Netlify oferece um domínio gratuito no formato `nome-do-projeto.netlify.app`. Para usar um domínio customizado (como `propostas.minhaempresa.com`), é necessário apontar o DNS do domínio para o Netlify — processo que leva menos de 10 minutos e também pode ser guiado pelo Claude Code.

Uma vez no ar, o sistema completo funciona: criação de conta, login, geração de proposta com IA, link compartilhável, assinatura eletrônica, e cobrança via Stripe. Tudo em uma aplicação web profissional construída em menos de uma hora a partir de uma ideia verbal.

O custo operacional do sistema em produção é baixo: Supabase tem plano gratuito generoso (500MB de banco de dados, 50.000 usuários ativos por mês), Netlify tem plano gratuito para sites estáticos e projetos pequenos, e Stripe cobra apenas quando há transações (2.9% + $0.30 por transação nos EUA). O único custo fixo é o uso da API do Claude para geração de propostas.

## ENTENDENDO O /CONTEXT — ANATOMIA DO USO DE TOKENS 2:46:39

Um dos recursos mais reveladores do Claude Code é o comando `/context`. Executá-lo mostra exatamente onde cada token do seu contexto está sendo usado. Para a maioria dos usuários, o resultado é surpreendente.

Em uma sessão recém-iniciada onde a única instrução dada foi `/context`, já havia 26.400 tokens consumidos — 13% do contexto total do Opus 4.6 (200.000 tokens). De onde vieram esses tokens?

O breakdown típico de uma sessão mostra:

**System prompt**: O Claude Code tem um system prompt interno grande que define capacidades, comportamentos, e limitações do agente. Isso consume vários milhares de tokens em toda sessão.

**CLAUDE.md global** (`~/.claude/CLAUDE.md`): as instruções pessoais que se aplicam a todos os projetos. Quanto maior esse arquivo, mais tokens consome em toda sessão.

**CLAUDE.md local** (`.claude/CLAUDE.md` do projeto): as instruções específicas do projeto atual. Em projetos com CLAUDE.md detalhado, pode consumir vários milhares de tokens.

**Arquivos de regras** (`.claude/rules/*.md`): cada arquivo de regras é carregado em cada sessão, adicionando ao total.

**Definições de ferramentas**: todas as ferramentas disponíveis para o Claude (bash, web fetch, read file, etc.) têm descrições que são carregadas no contexto. Com muitos MCPs instalados, isso pode chegar a 20.000+ tokens.

**Memória** (`memory.md`): o arquivo de memória persistente é carregado em cada sessão.

**Histórico da conversa**: cada mensagem da sessão atual (suas perguntas e as respostas do Claude) ocupa tokens. Em sessões longas, isso pode facilmente chegar a 100.000+ tokens.

O que isso significa na prática: antes mesmo de você digitar a primeira instrução em uma sessão, você já está gastando tokens. Uma sessão com CLAUDE.md detalhado + vários MCPs instalados + memória rica pode começar já com 40.000-50.000 tokens consumidos — 20-25% do contexto total do Opus.

Isso tem implicações diretas para a qualidade: as respostas do Claude são mais precisas e inteligentes quando o contexto está “limpo” no início de uma sessão. À medida que a sessão avança e mais tokens são consumidos, a qualidade tende a cair ligeiramente. Isso é o “context rot” — não é uma queda dramática, mas é real e mensurável.

A estratégia de minimização: mantenha o CLAUDE.md global conciso (idealmente abaixo de 500 linhas), remova MCPs que não usa, use skills em vez de MCPs para operações repetitivas, e faça `/compact` periodicamente em sessões longas.

## CRIAÇÃO DE SKILLS — PROCESSO DETALHADO 2:48:14

A criação de skills é um processo iterativo que combina documentação, scripts, e aprendizado contínuo. Aqui está o processo detalhado de como criar uma skill do zero.

**Passo 1: Identificar o processo a automatizar**

Antes de criar uma skill, documente o processo que você executa manualmente. Anote: o objetivo final, os inputs necessários, as etapas em ordem, as possíveis falhas e como tratá-las, e os outputs esperados. Quanto mais detalhado esse documento, melhor será a skill.

**Passo 2: Criar a estrutura de pastas**

Na pasta `.claude/skills/`, crie uma nova pasta com o nome da skill em kebab-case (palavras separadas por hífens, sem acentos). Exemplo: `pesquisa-leads/`. Dentro, crie o arquivo `skill.md` e opcionalmente uma pasta `scripts/`.

**Passo 3: Escrever o front matter**

O arquivo `skill.md` começa com um bloco de front matter em YAML que define o metadado da skill:

```yaml

---

name: Pesquisa de Leads

description: Busca e qualifica leads para campanha de email frio dado um nicho e localização

allowed-tools: bash, web_search, read_file, write_file

---

```

O front matter é o único trecho carregado no contexto por padrão. O Claude sabe que a skill existe e o que ela faz, mas não carrega o documento completo. Isso é fundamental para eficiência de tokens.

**Passo 4: Documentar o processo no skill.md**

Após o front matter, documente o processo em seções claras:

- **Objetivo**: o que a skill produz ao final

- **Inputs**: o que o usuário deve fornecer (e em que formato)

- **Processo**: as etapas numeradas, com condicionais e tratamento de erros

- **Outputs**: o que é produzido (arquivos, dados, URLs, etc.)

- **Notas**: exceções, limitações, boas práticas

O nível de detalhe deve ser como se você estivesse explicando para um novo funcionário. Cada ambiguidade que você não resolver aqui vai resultar em comportamento inesperado do Claude.

**Passo 5: Criar scripts de suporte (opcional mas recomendado)**

Para operações repetitivas e pesadas (scraping, processamento de dados, upload para planilhas), crie scripts Python na pasta `scripts/`. Esses scripts são chamados pelo Claude como ferramentas, não como código que o Claude escreve do zero toda vez.

Benefícios de scripts: execução determinística (mesmo resultado toda vez), mais rápido (sem overhead de geração de código), e mais fácil de debugar quando algo dá errado.

**Passo 6: Testar e iterar**

Teste a skill em uma sessão nova. Observe onde o Claude se desvia do esperado ou comete erros. Atualize o `skill.md` para clarificar esses pontos. Adicione exemplos de casos de borda que encontrou. Repita até atingir uma taxa de sucesso de 90%+.

O Claude Code tem um mecanismo de auto-aprendizado para skills: quando ele encontra um erro e o resolve, atualiza o `skill.md` automaticamente para prevenir o mesmo erro no futuro. Isso significa que skills ficam progressivamente mais robustas com o uso.

**Passo 7: Invocar a skill**

Para usar a skill, simplesmente mencione o nome dela na instrução: “use a skill de pesquisa de leads para encontrar 500 dentistas no estado de São Paulo” ou mais diretamente: “execute a skill pesquisa-leads com: nicho=dentistas, localização=São Paulo, quantidade=500”.

O Claude detecta que uma skill existe para essa tarefa, carrega o `skill.md` completo, e segue o processo documentado.

**Exemplo completo: skill “pesquisa-academica”**

Uma skill de pesquisa acadêmica que o instrutor usa consulta o PubMed, extrai artigos relevantes, resume cada um usando um modelo menor (Sonnet), e entrega um relatório estruturado com citações. O processo que levava 3-4 horas manualmente agora leva 10-15 minutos com a skill.

A estrutura da skill inclui: um script Python que faz queries no PubMed via API, um script que extrai o texto completo dos artigos mais relevantes, e o skill.md que orquestra tudo isso e define como formatar o relatório final.

## FERRAMENTAS NATIVAS DO CLAUDE CODE — LISTA COMPLETA 2:51:43

O Claude Code vem com um conjunto de ferramentas nativas que consomem tokens mesmo antes de você digitar qualquer mensagem. Entender essas ferramentas explica por que uma sessão recém-iniciada já tem 16.000+ tokens consumidos.

Quando você digita `/context` e scroll para “system tools”, você vê todas as ferramentas disponíveis e o custo em tokens de cada descrição. As principais são:

**task**: a ferramenta que cria sub-agentes. Toda vez que o Claude spawna um sub-agente, é esse tool que é chamado.

**task_output**: recupera o output de um sub-agente que já completou sua tarefa.

**bash**: executa comandos de shell no terminal. É como o Claude instala pacotes, executa scripts, e faz qualquer operação no sistema operacional.

**glob**: encontra arquivos por padrão (como `*.py` para encontrar todos os arquivos Python, ou `**/*.html` para encontrar todos os arquivos HTML recursivamente).

**grep**: busca conteúdo dentro de arquivos. Permite ao Claude encontrar onde uma função específica está definida, onde uma variável é usada, etc.

**read**: lê o conteúdo de um arquivo específico. Sem essa ferramenta, o Claude não pode ver o que está nos arquivos do projeto.

**edit**: faz alterações cirúrgicas em arquivos (substitui texto específico). Mais eficiente do que reescrever o arquivo inteiro.

**write**: cria novos arquivos ou sobrescreve completamente arquivos existentes.

**notebook_edit**: ferramenta específica para Jupyter notebooks, muito usados em ciência de dados e machine learning.

**web_fetch**: busca o conteúdo de uma URL da internet. Permite ao Claude ler documentação, pesquisar informações, e verificar APIs.

**web_search**: realiza buscas no Google (ou mecanismo similar). Diferente do web_fetch, este encontra URLs relevantes; web_fetch as lê.

**todo_write**: cria e atualiza aquelas listas de tarefas (todo lists) que aparecem quando o Claude está trabalhando em tarefas complexas. É o mecanismo de planejamento interno.

**ask_user_question**: gera aquelas interfaces de múltipla escolha interativas que o Claude usa quando precisa de informações específicas do usuário. Foi usada no início do projeto de gerador de propostas para perguntar sobre preferências técnicas.

**enter_plan_mode** / **exit_plan_mode**: ferramentas para transições entre modos programaticamente.

**skill**: a meta-ferramenta que orquestra o carregamento e execução de skills. Quando você pede para usar uma skill, essa ferramenta é invocada.

**task_stop**: para a execução de um sub-agente em andamento.

Essas ferramentas têm descrições detalhadas que o Claude precisa carregar para saber quando e como usar cada uma. Isso explica o custo fixo de ~16.000-17.000 tokens em toda sessão — é o “preço de entrada” do Claude Code.

O auto compact buffer é um espaço reservado no final da janela de contexto. Quando o uso de tokens atinge o limite (deixando apenas ~33.000 tokens livres), o sistema automático de compactação entra em ação e comprime o histórico da conversa, mantendo espaço para novas interações. Isso acontece transparentemente — você verá uma nota no chat indicando que houve compactação automática.

## SEGURANÇA EM APLICAÇÕES — AVISO IMPORTANTE 2:53:35

O Claude Code é uma ferramenta extraordinariamente poderosa, e com grande poder vem grande responsabilidade. Especialmente para aplicações que lidam com dados de usuários reais, há precauções importantes que não devem ser ignoradas.

**O risco real do “vibe coding”**

Aplicações construídas puramente por IA sem revisão de segurança têm riscos reais. O caso mais famoso citado no curso foi o do CloudBot (depois OpenClaw), que sofreu múltiplas vulnerabilidades de segurança graves incluindo prompt injection — onde usuários conseguiam manipular o comportamento do agente inserindo instruções maliciosas nos inputs.

Vulnerabilidades comuns em código gerado por IA incluem:

- **SQL Injection**: código que constrói queries SQL com inputs do usuário diretamente, sem sanitização adequada

- **Autenticação fraca**: tokens JWT mal implementados, senhas armazenadas em plain text, sessões que não expiram

- **Exposição de credenciais**: chaves de API hardcoded no código em vez de variáveis de ambiente

- **IDOR (Insecure Direct Object Reference)**: acessar recursos de outros usuários simplesmente mudando um ID na URL

- **Falta de rate limiting**: APIs sem proteção contra abuso e força bruta

**Recomendações práticas**

Para uso interno (só você e sua equipe): as proteções básicas que o Claude Code implementa por padrão são geralmente suficientes. Use uma URL não-óbvia (não algo como `minhafirma-proposta.netlify.app`), limite o acesso via autenticação básica se possível.

Para uso com clientes externos ou dados sensíveis: antes de lançar, contrate um desenvolvedor para revisar pelo menos a camada de autenticação e as rotas de API. Esse é um trabalho de algumas horas que pode prevenir incidentes sérios. O custo de uma revisão de segurança básica é muito menor que o dano reputacional ou legal de uma violação de dados.

Para aplicações que processam pagamentos ou dados médicos/financeiros: há regulamentações específicas (PCI DSS para pagamentos, HIPAA para saúde nos EUA, LGPD no Brasil) que impõem requisitos técnicos específicos. Nenhuma dessas regulamentações deve ser ignorada.

**Onde o Claude Code se sai bem em segurança**

O Claude Code normalmente implementa corretamente: hash de senhas com bcrypt, HTTPS em deploys no Netlify, autenticação baseada em JWT com expiração, proteção CSRF básica em formulários. Mas “normalmente” não é suficiente para ambientes de produção críticos.

**A abordagem pragmática**

Use Claude Code para construir o produto e iterar rapidamente. Quando o produto estiver validado e antes de escalar, invista em uma revisão de segurança por um profissional. O código gerado pelo Claude Code é um excelente ponto de partida — limpo, bem estruturado, com padrões modernos. Mas precisa de olhos humanos especializados antes de proteger dados de pessoas reais.

## SKILLS AVANÇADAS — DEMONSTRAÇÃO COMPLETA COM LEAD SCRAPING 2:55:06

Vamos ver uma demonstração completa de como as skills funcionam na prática. O instrutor tem uma skill chamada “Scrape Leads” que extrai e verifica leads de negócios, classifica com um modelo de linguagem, enriquece os e-mails e salva tudo numa planilha do Google. A skill é acionada quando você pede para encontrar leads, fazer scraping de empresas, gerar listas de prospects ou construir bases de dados para qualquer nicho ou localização.

A estrutura da skill inclui um objetivo principal no topo (fazer scraping usando uma fonte específica), uma lista de inputs necessários, alguns scripts prontos para execução e um checklist de processos detalhado: começar com um scrape de teste, depois verificação, depois scrape completo, classificação por LLM, upload para o Google Sheets, enriquecimento de e-mails faltantes, e assim por diante.

Quando o usuário executa o comando “raspe 1000 dentistas nos Estados Unidos”, o Claude carrega a skill automaticamente. Ele inicia com um scrape de teste de 25 dentistas para verificar a qualidade. Encontra automaticamente os filtros corretos e começa a trabalhar. Segundo o processo definido na skill, o Claude vai:

1. Ler os 25 leads iniciais e fazer uma pesquisa de fundo para confirmar se são o tipo de lead desejado

2. Se aprovado, proceder com um scrape completo e paralelo de 1000 leads

3. Nesse caso específico, foram iniciados 4 scrapers em paralelo, cada um buscando 250 leads

O processo que antes levaria de 15 a 20 minutos só para configurar os filtros, mais 10 a 15 minutos de verificação manual, mais o trabalho de upload para planilha, cruzamento de dados e execução de fluxos de IA adicionais, agora acontece em apenas 87 segundos. O resultado é uma planilha com centenas de dentistas dos EUA, incluindo telefones, endereços e outros dados de contato.

No meio do processo houve um problema técnico: a API do Google Sheets não aceita espaços e caracteres especiais em certos campos. O Claude identificou o erro, consultou a documentação da API e fez o upload com a solução correta, sem precisar de intervenção humana. Esse loop de tentativa e correção, que antes consumia muito tempo de um desenvolvedor ou operador, aconteceu automaticamente.

O resultado final vai direto para o Instantly ou outra plataforma de cold email para iniciar campanhas imediatamente. Em termos de impacto econômico: um processo que consumia mais de 30 minutos de trabalho manual agora leva menos de 2 minutos, e o custo de API é uma fração do que custaria contratar alguém para fazer o mesmo.

## ESTRUTURA INTERNA DAS SKILLS — ORQUESTRADOR E SCRIPTS 2:56:56

Para entender como skills funcionam internamente, é preciso compreender a separação entre duas camadas: o skill.md e a pasta scripts/.

O skill.md funciona como o orquestrador — é como um maestro que não toca os instrumentos mas coordena quem toca o quê e quando. Ele contém a lógica, o checklist de passos e as referências. A pasta scripts/ contém os músicos: os scripts Python reais que executam cada ação específica.

Quando o Claude recebe um pedido como “raspe 1000 leads”, ele:

1. Lê o skill.md e identifica o fluxo: primeiro teste, depois verificação, depois scrape completo

2. Chama o script correto para cada etapa: `scrape_apify.py` com parâmetro max_items=25 para o teste

3. Verifica o resultado de cada passo antes de avançar

4. Usa inteligência nativa para lidar com erros inesperados, sem travar

5. Atualiza o skill.md automaticamente se encontrar um problema recorrente, para que instâncias futuras não repitam o erro

O instrutor confessa que nunca olhou para o código dentro da pasta scripts/. Disse que foi a primeira vez que abriu aquele arquivo durante a demonstração. O Claude criou todos aqueles scripts Python por conta própria, com base no checklist que recebeu no skill.md. Isso ilustra um ponto fundamental: você não precisa saber programar para criar skills poderosas. Você precisa saber descrever o processo com clareza.

A analogia com um funcionário júnior é precisa: você dá um checklist, o funcionário executa, e quando tem um problema, ele usa seu próprio julgamento para resolver antes de te acionar. A diferença é que o Claude nunca fica entediado, nunca chega atrasado, e custa centavos por execução.

Outro exemplo do instrutor é a skill “literature research” — pesquisa de literatura científica. Quando ele quer saber sobre dosagem diária de vitamina D para homens na faixa dos 30 anos, ele simplesmente diz “faça uma revisão de literatura sobre isso”. A skill automaticamente consulta o PubMed, executa consultas paralelas usando diferentes termos de busca, aplica um script de análise profunda em cada artigo e retorna um relatório estruturado.

No processo, algumas queries iniciais falharam — mas o Claude tentou novamente com diferentes variações até encontrar o que precisava. Essa flexibilidade para tentar, errar e corrigir sem travar é o que torna as skills diferentes de scripts rígidos tradicionais.

Por que usar isso em vez de simplesmente pedir ao Claude para buscar a informação? Porque na skill você já definiu com antecedência: quais bancos de dados consultar, como paralelizar as queries, quais modelos usar (às vezes um modelo menor mas com janela de contexto maior é mais eficiente para processar muitos artigos), e qual formato de output esperar. Você transforma seu conhecimento operacional em um sistema repetível.

## CRIANDO UMA SKILL DO ZERO — GERADOR DE SITES PARA PROSPECTS 2:59:40

A demonstração mais detalhada de criação de skill ao vivo envolve construir um sistema que gera sites personalizados para prospects de uma agência. A ideia: receber uma planilha do Google com informações sobre um prospect e gerar automaticamente um site bonito e personalizado para ele, que serve como isca de captação ou apresentação de proposta.

O processo de criação começa com uma mensagem detalhada descrevendo o que a skill deve fazer:

- Receber informações de um prospect via URL de planilha do Google

- Gerar um site baseado em um template específico (o instrutor escolheu um do godly.website)

- Usar imagens da API do Unsplash para ilustrar o site

- Produzir um HTML local como output

- Seguir o template o mais próximo possível visualmente

O instrutor cola o HTML do template (474 linhas), uma screenshot do design, e alguns dados de exemplo da planilha de dentistas gerada pela skill anterior. Isso é uma quantidade enorme de contexto, mas com o fast mode ativado, o processamento acontece em poucos minutos.

O Claude faz algumas perguntas clarificadoras antes de começar a construir:

- “O output deve ser um HTML local ou hospedado?” → HTML local por enquanto

- “Como você vai fornecer os dados do prospect?” → URL da planilha do Google

- “Para imagens, qual abordagem prefere?” → API do Unsplash

- “O site deve ser um mockup de como ficaria o site deles, ou uma página de pitch dos seus serviços?” → mockup do site deles

Interessante: o Claude iniciou o modo de planejamento espontaneamente, sem que o usuário pedisse. Isso acontece frequentemente quando o bypass de permissões está ativo e a tarefa é mais complexa. O agente percebe que precisa estruturar bem a execução antes de começar a escrever código.

A primeira versão do site gerado não ficou exatamente como o template. O instrutor diz que não está satisfeito com a fidelidade visual e pede: “quero que você faça screenshots do site atual e do template e compare os dois, iterando até chegar na precisão pixel a pixel”. O Claude começa a fazer esse loop de screenshot → comparação → ajuste até chegar numa versão muito mais próxima do template.

Depois de alguns ajustes e pedindo imagens diferentes (as primeiras ficaram repetidas), o resultado é um site limpo e bonito com informações reais do prospect: nome do consultório, telefone, endereço, e imagens de qualidade do bairro ou cidade. Em 30 segundos de execução por site.

O instrutor então mostra o poder de escalar isso: com sub-agentes (que ele vai mostrar depois), você pode rodar 10 dessas skills em paralelo. Em vez de 30 segundos por site, você gera 10 sites a cada 30 segundos — 3 segundos por site. Para uma lista de 10.000 leads, isso seria cerca de 500 minutos, ou 8 horas de processamento totalmente autônomo. Combinado com a skill de scraping de leads e uma ferramenta de cold email, você tem um sistema completo de prospecção rodando sozinho.

## MCPs — MODEL CONTEXT PROTOCOL NA PRÁTICA 3:02:09

Agora que entendemos skills, o instrutor explica MCPs (Model Context Protocol) com uma definição direta: são basicamente skills que outras pessoas criaram para você. Em vez de você ter que construir o script de integração com o ClickUp ou o Gmail, alguém já fez esse trabalho e disponibilizou como um MCP server que você pode instalar em segundos.

Existem três lugares principais para encontrar MCPs:

- **mcpservers.org**: diretório geral com centenas de servidores

- **modelcontextprotocol/servers** (repositório oficial da Anthropic no GitHub): lista curada de servidores verificados

- **MCP Market**: marketplace alternativo com outros servidores

Uma advertência importante: nem todos esses servidores são seguros. São bibliotecas de terceiros, e embora muitas sejam bem avaliadas pela comunidade, você está instalando código externo que vai ter acesso ao seu sistema e aos seus dados. Verifique a reputação do servidor antes de instalar.

**Instalando um MCP server**

O processo de instalação é surpreendentemente simples. Todo servidor MCP fornece um snippet JSON que se parece com isto:

```json

{

“mcpServers”: {

“nome-do-servidor”: {

“command”: “npx”,

“args”: [“-y”, “@nome/pacote-mcp”]

}

}

}

```

Você copia esse JSON e cola diretamente no Claude dizendo “instale isso no meu workspace local”. O Claude encontra ou cria o arquivo de configuração adequado e adiciona o servidor. Na próxima sessão, as ferramentas estarão disponíveis.

É importante especificar “workspace local” para não instalar globalmente em todas as sessões.

**Demonstração: Chrome DevTools MCP**

O MCP mais valioso que o instrutor usa é o Chrome DevTools MCP. Desenvolvido pela própria equipe do Claude, ele permite que o agente de código controle e inspecione um navegador Chrome ao vivo.

Comparado às ferramentas de navegador nativas do Claude, o Chrome DevTools MCP é descrito como “100 vezes mais rápido”. Enquanto a ferramenta nativa tira screenshots e age passo a passo, o Chrome DevTools MCP tem acesso direto ao DOM, pode executar JavaScript, ler o console, monitorar requisições de rede e interagir com elementos muito mais eficientemente.

Após instalar e abrir uma nova sessão do Claude, o instrutor demonstra:

- “Abra leftclick.ai, tire um screenshot e me fale sobre o site visualmente” → O Claude navega, tira screenshot, analisa e descreve o header, hero section, CTAs, etc.

- “Vá para amazon.ca e encontre light boxes baratas mas eficazes para meu estúdio” → O Claude vai para a Amazon, pesquisa diferentes termos, tira screenshots das páginas de resultados, e recomenda opções com preço e características

Nas ferramentas de MCP, você consegue ver nos logs que cada chamada indica: o nome do MCP server, a ferramenta específica sendo usada, e o resultado. Isso dá transparência total sobre o que o agente está fazendo.

**Demonstração: ClickUp MCP**

Para integrar com o ClickUp, o instrutor busca por “ClickUp MCP server” e encontra um servidor oficial. Copia o JSON, cola no Claude, e em segundos o servidor está instalado. O Claude pede um API token, que é gerado nas configurações do ClickUp e colado de volta.

Após autenticar, o instrutor demonstra:

- “Crie uma nova ideia de conteúdo chamada Claude Code Course” → O Claude navega pelos espaços e listas do ClickUp, encontra a fila de YouTube, e cria a tarefa

- “O status está como 'arquivado', mude para 'a gravar'” → O Claude atualiza o status

Funciona perfeitamente — mas há um custo. Quando você examina o uso de tokens com `/context`, você vê que só as ferramentas do ClickUp MCP consomem quase 20.000 tokens. A ferramenta de busca do ClickUp: 1.600 tokens. Get workspace hierarchy: 419 tokens. Várias outras ao redor de 1.000 tokens cada.

Isso significa que, antes mesmo de você digitar qualquer mensagem, você já está com 35-40.000 tokens consumidos (system prompt + ferramentas MCP + memória). Numa janela de contexto de 200.000 tokens, isso representa quase 20% só de overhead.

Para fins de comparação: as skills do usuário (scrape leads, monitor escola, etc.) consomem apenas 58-63 tokens cada, porque somente o front matter (nome, descrição, ferramentas permitidas) é carregado no contexto inicialmente. O corpo completo da skill só é carregado quando explicitamente invocado.

Isso leva a uma estratégia prática: use MCPs para prototipagem e testes rápidos. Quando encontrar um workflow que funciona, converta para uma skill que faz as mesmas chamadas de API diretamente, sem o overhead do MCP server. Você fica com o melhor dos dois mundos: velocidade de setup do MCP + eficiência de tokens da skill.

## GMAIL MCP — ORGANIZAÇÃO DE E-MAILS COM IA 3:04:23

Uma demonstração prática de ciclo completo MCP → Skill envolve a organização de e-mails por labels. O objetivo: usar o Gmail MCP para prototipar a solução, verificar que funciona, e depois converter para uma skill que faz o mesmo com muito menos tokens.

**Fase 1: Planejamento com o Claude**

Antes de qualquer código, o instrutor pede ao Claude que sugira um esquema de labels de alto ROI para uma caixa pessoal. Com o modo thinking ativado, o Claude sugere um esquema baseado em ações:

- **Action Required**: e-mails que precisam de resposta ou ação

- **Reference**: informações úteis mas sem ação necessária

- **Waiting On**: e-mails onde você está aguardando resposta de alguém

Simples, mas eficaz. O instrutor aprova e parte para a implementação.

**Fase 2: Instalando o Gmail MCP**

O instrutor procura por um Gmail MCP server, encontra um repositório com boa reputação e copia o JSON de configuração. Cola no Claude e instala no workspace. O Claude vai orientando o processo de autenticação OAuth, que requer:

1. Criar credenciais no Google Cloud Console

2. Baixar o arquivo credentials.json

3. Fazer upload para o Claude Code

4. Autorizar o acesso à conta Gmail

Após reiniciar a sessão para carregar o novo MCP, o Claude tem acesso às ferramentas do Gmail.

**Fase 3: Testando com 15 e-mails**

O instrutor pede para o Claude classificar e aplicar labels nos últimos 15 e-mails. Com o fast mode ativado, a classificação acontece rapidamente. O Claude lê cada e-mail, determina a categoria correta e aplica a label via API do Gmail.

Resultado: labels aparecem corretamente na interface do Gmail — “Action Required”, “Reference”, “Waiting On”. Funciona perfeitamente.

**Fase 4: Convertendo para skill**

Agora a parte inteligente. O instrutor pede: “converta isso em uma skill chamada gmail_label que usa a API do Gmail diretamente em vez do MCP server, porque skills são muito mais eficientes em tokens”.

O Claude examina as outras skills existentes para entender o padrão de formatação, depois constrói a nova skill com scripts Python que fazem as chamadas diretas à API do Gmail usando as credenciais OAuth já configuradas.

**Fase 5: Testando a skill com 100 e-mails**

Com a skill pronta, o instrutor pede para classificar 100 e-mails. A diferença de velocidade é dramática:

- Com o MCP: processava com algum overhead entre chamadas

- Com a skill (API direta): busca 100 e-mails em 1 segundo

O total de 100 e-mails foi buscado, classificado e com labels aplicadas em 36 segundos. Isso dá 0.36 segundos por e-mail.

**Fase 6: Escalando para 1000 e-mails**

“Ótimo trabalho, agora faça 1000 e-mails.” O Claude executa o mesmo fluxo para a caixa inteira. O resultado: 987 de 989 e-mails classificados corretamente. Dois falharam por algum problema de encoding, mas 98.8% de sucesso num processamento totalmente autônomo é excelente.

O instrutor observa que poderia ainda ir além: com sub-agentes (próximo tópico), seria possível paralelizar a classificação, dividindo os 1000 e-mails em 10 chunks de 100, processados simultaneamente. Em vez de processar sequencialmente em cerca de 6 minutos, processaria tudo em menos de 40 segundos.

## PLUGINS DO CLAUDE CODE — VISÃO GERAL 3:07:38

Antes de entrar em sub-agentes, o instrutor faz uma parada rápida para cobrir os plugins do Claude Code. A distinção entre plugins e MCPs pode ser confusa, então aqui vai a simplificação:

- **MCPs**: integrações com serviços externos (ClickUp, Gmail, etc.) — ferramentas que o Claude usa para fazer coisas

- **Plugins**: extensões que modificam o comportamento do próprio Claude Code — geralmente adicionam instruções, conhecimento ou capacidades ao agente

O instrutor tem apenas um plugin instalado: **claude-mem** (ou similar), que registra todas as mensagens enviadas em qualquer instância do Claude e permite pesquisas sobre conversas passadas. Útil, mas não essencial.

**Plugins oficiais disponíveis**

Na seção de plugins do Claude Code, você encontra alguns que a Anthropic disponibiliza:

**Frontend Design Plugin**: supostamente melhora a qualidade de interfaces geradas. A Anthropic mostra comparações antes/depois, e embora o “depois” seja visivelmente melhor, o instrutor é cético: “ambas são ruins, uma é menos pior”. Sua opinião é que o workflow de copiar templates de sites como godly.website produz resultados muito superiores.

**Context7**: plugin interessante que indexa documentação de APIs automaticamente. Quando você está trabalhando com 3-4 ferramentas diferentes, o Context7 busca e comprime a documentação relevante de forma token-eficiente para o Claude ler. Elimina a necessidade de você colar manualmente a documentação da API no chat.

**Outros plugins**: há uma lista na pasta oficial `claude-plugins-official` no GitHub, incluindo Agent SDK Dev, Code Review, exemplos de LSP para C#, entre outros. Também existe um marketplace não-oficial de terceiros (o instrutor menciona que a Anthropic queria que ele tirasse do ar, mas estava lá no momento da gravação).

**Perspectiva sobre plugins**

O instrutor acredita que plugins são uma categoria que vai ser absorvida por skills no futuro próximo. A distinção entre “plugin” e “skill” está se tornando cada vez mais tênue. Não recomenda gastar muito tempo explorando plugins agora — foque em entender skills profundamente, que é onde o valor real está.

## SUB-AGENTES — COMO FUNCIONAM E QUANDO USAR 3:08:49

Sub-agentes são uma das funcionalidades mais comentadas do Claude Code, mas o instrutor abre esta seção com uma dose de realismo: “sub-agentes não são uma solução mágica. Você pode fazer praticamente tudo com um agente normal. Sub-agentes são úteis para paralelização — e só.”

**O que são sub-agentes**

Quando você faz uma tarefa no Claude Code normalmente, há um único thread de execução: o agente faz a coisa A, depois a coisa B, depois a coisa C, sequencialmente. Com sub-agentes, o agente principal pode dividir uma tarefa em partes e delegar cada parte para um agente filho que executa em paralelo.

Os sub-agentes têm sua própria janela de contexto, isolada do agente pai. Eles recebem uma tarefa específica, executam, e retornam o resultado para o agente que os criou. É exatamente como o exemplo de paralelização que o instrutor usa ao longo do curso: em vez de fazer A → B → C em série (3 minutos), você faz A + B + C em paralelo (1 minuto).

**Transformando a skill de e-mail em sub-agente**

A demonstração parte da skill gmail_label que acabamos de criar. O instrutor pede: “converta o fluxo gmail-label em um sub-agente. Em vez de classificar 100 e-mails sequencialmente, quero spawnar 10 sub-agentes que fazem 10 lotes de 10 e-mails simultaneamente e retornam os resultados.”

Instruções adicionais importantes:

- Use o sonnet-4.5 para os sub-agentes (modelos menores são mais baratos e têm janela de contexto maior)

- Adicione timing instrumentation para medir o speedup

- Teste primeiro com 100 e-mails para validar, depois escale

O Claude pesquisa como sub-agentes funcionam (usa um sub-agente para pesquisar sobre sub-agentes — meta!), cria uma pasta `.claude/agents/` com a especificação, e depois cria uma nova sessão Claude para executar o sistema.

**Resultados do teste**

Com 100 e-mails e 10 sub-agentes paralelos:

- Versão sequencial (skill): ~36 segundos

- Versão paralela (sub-agentes): ~19 segundos

- Speedup: 1.9x (salvo 17 segundos, não exatamente 10x porque há overhead de coordenação)

Com 1000 e-mails e 10 sub-agentes paralelos:

- O instrutor estima que levou cerca de 1 minuto

- Versus 6 minutos que levaria sequencialmente

- Speedup próximo de 6x nesse volume maior

O speedup aumenta com o volume porque o overhead fixo de coordenação se dilui. Para 100 e-mails, o overhead é proporcionalmente grande. Para 1000, ele se torna insignificante.

**Problema encontrado: overflow de contexto**

Durante o teste com 1000 e-mails, o agente encontrou um erro: “prompt too long”. O problema é que cada sub-agente estava retornando o texto completo de todos os e-mails classificados, e quando o agente principal tentou agregar todas essas respostas, o contexto explodiu.

A solução foi instruir os sub-agentes a aplicar as labels diretamente e retornar apenas um resumo (quantos e-mails classificados em cada categoria), sem retornar o texto completo. O agente pai só precisa saber que “sub-agente 3 classificou 100 e-mails: 15 action required, 70 reference, 15 waiting on” — não precisa dos textos.

**Boas práticas para sub-agentes**

O instrutor destaca alguns princípios importantes:

1. **Tarefas simples e bem definidas**: cada sub-agente deve ter uma tarefa clara e pequena. Sub-agentes são menos inteligentes que o agente pai. Se você der instruções complexas para muitos sub-agentes em paralelo, a probabilidade de pelo menos um falhar aumenta exponencialmente.

Matemática: se cada sub-agente tem 95% de chance de sucesso, 10 sub-agentes têm 0.95^10 = 59% de chance de todos completarem corretamente. Com 50 sub-agentes, essa probabilidade cai para 7%.

2. **Sub-agentes não são para tudo**: o overhead de iniciar um sub-agente para uma tarefa simples pode ser maior do que simplesmente fazer a tarefa no agente pai. Reserve para casos de paralelização real.

3. **Os outputs são efêmeros**: a janela de contexto dos sub-agentes existe apenas enquanto eles estão rodando. Não guarde informação importante só no contexto de um sub-agente — certifique-se que o resultado seja persistido (em arquivo ou retornado ao pai).

4. **Use modelos menores para sub-agentes**: Sonnet ou Haiku são ideais. São mais baratos, têm janelas de contexto maiores, e para tarefas específicas e bem definidas, são tão bons quanto o Opus.

## OS TRÊS SUB-AGENTES MAIS ÚTEIS 3:12:19

O instrutor constrói ao vivo três sub-agentes que considera essencialmente úteis para qualquer desenvolvedor usando o Claude Code em projetos sérios: Code Reviewer, QA e Researcher. Eles ficam na pasta `.claude/agents/` e são referenciados no claude.md.

**Agente: Code Reviewer**

Responsabilidade: revisar código modificado em busca de problemas de segurança, legibilidade e boas práticas. Recebe os arquivos alterados como input, retorna uma lista de issues categorizadas por severidade (bloqueante, sugestão, cosmético) e recomendações de melhoria específicas.

O valor: o Code Reviewer não tem o contexto de “por que” o código foi escrito dessa forma — ele vê apenas o código em si. Isso elimina o viés de confirmação que o agente pai poderia ter. Às vezes, um olhar fresco e objetivamente crítico encontra problemas óbvios que quem escreveu o código não consegue ver.

**Agente: QA**

Responsabilidade: gerar e executar testes automatizados para o código novo. Ele lê os arquivos modificados, escreve testes unitários e de integração, executa os testes e reporta os resultados. Se algum teste falhar, tenta corrigir o problema ou escala para o agente pai com uma explicação clara do que está quebrando.

**Agente: Researcher**

Responsabilidade: fazer pesquisa especializada em fontes específicas. O instrutor configurou o seu para priorizar: documentação oficial de APIs, repositórios do GitHub, arXiv (para papers científicos) e alguns sites de referência técnica que ele confia. Quando precisa descobrir como uma API funciona, qual é a melhor biblioteca para algo, ou se existe um MCP server para determinado serviço, ele spawna o Research sub-agent em vez de pesquisar ele mesmo.

A demonstração do Researcher: o instrutor pede “use o sub-agente de pesquisa para encontrar o melhor MCP server disponível para PandaDoc”. O sub-agente spawna, faz múltiplas buscas em paralelo (diferentes queries de busca simultaneamente), acessa documentação, GitHub repos, páginas de MCP marketplaces, e retorna uma análise comparativa dos servidores encontrados. Mais rápido e mais sistemático do que uma pesquisa manual.

**Workflow integrado**

Com os três sub-agentes configurados, o instrutor define o workflow padrão de desenvolvimento de software:

1. **Implementar**: o agente pai escreve e edita o código

2. **Code Review**: spawnar o Code Reviewer nos arquivos modificados, corrigir issues bloqueantes

3. **QA**: spawnar o QA Agent no código, gerar e rodar testes, corrigir falhas

4. **Ship**: fazer commit e push

Para testar esse workflow, o instrutor aplica ele na skill gmail_label que criou anteriormente. O Code Reviewer identifica imediatamente uma oportunidade de melhoria: o código estava fazendo batches de 100 e-mails por vez, mas a API do Gmail suporta batches de até 1000 — uma oportunidade de performance de 10x ignorada.

Também identifica um problema de callback que poderia causar erros intermitentes, e sugere melhorias de legibilidade e comentários.

Os testes do QA passam quase todos — há apenas um que falha por um problema de validação de formato de ID. O agente pai recebe todos esses feedbacks e aplica as correções, produzindo código significativamente melhor do que o inicial.

O instrutor é honesto: para projetos pessoais e uso interno, esse nível de rigor provavelmente não é necessário. Mas para código empresarial, sistemas críticos ou qualquer coisa que vai para produção com usuários reais, ter esses agentes de revisão e QA pode ser a diferença entre um sistema confiável e um que quebra em produção.

## AGENT TEAMS — TIMES DE AGENTES EM DETALHES 3:14:11

Agent teams são uma extensão mais avançada do conceito de sub-agentes. Se sub-agentes permitem que um agente pai spawne filhos para paralelizar trabalho, os agent teams permitem uma estrutura ainda mais complexa: múltiplos agentes totalmente independentes, cada um com seu próprio Claude Code completo, que podem se comunicar entre si e com um agente líder.

**A diferença fundamental**

Sub-agentes:

- São filhos do agente pai

- Retornam resultados de volta ao pai

- Existem para tarefas focadas onde apenas um resultado importa

- Custo de tokens: relativamente baixo

Agent teams:

- São instâncias completamente independentes do Claude Code

- Têm sua própria janela de contexto completa

- Podem se comunicar diretamente entre si (não só com o líder)

- Compartilham um “scratch pad” — como um fórum interno onde postam updates, fazem perguntas, respondem

- Custo de tokens: muito alto — 7 vezes o custo de uma sessão normal, por ser proporcional ao número de agentes

- Indicados para trabalho complexo que requer discussão e colaboração

**Habilitando agent teams**

Estão desativados por padrão porque são experimentais e podem ser muito caros. Para ativar, você adiciona ao seu settings.json:

```json

{

“env”: {

“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”

}

}

```

Faça isso no workspace onde você quer usar os teams, não globalmente (a menos que queira que esteja disponível em todos os projetos).

**Demonstração 1: Três sites pessoais em paralelo**

O instrutor começa com uma tarefa simples para ilustrar o conceito: “Estou desenhando um site pessoal para Nick Sarayev. Gere três agentes usando um team e crie três designs fundamentalmente diferentes. Abra todos os três quando terminar para que eu possa comparar e dar feedback.”

Antes de spawnar os agentes de design, o agente líder toma uma decisão autônoma interessante: primeiro faz uma pesquisa sobre quem é Nick Sarayev. Sem nenhuma instrução específica, ele entendeu que para criar sites personalizados, precisa de informação sobre a pessoa. Essa iniciativa de pesquisa prévia demonstra o raciocínio de mais alto nível dos agent teams.

Após a pesquisa, spawna três agentes:

1. **design-minimalist**: site limpo e minimalista

2. **design-dark**: site com tema escuro e técnico

3. **design-warm**: site com estilo caloroso e narrativo

Você pode navegar entre os agentes no terminal usando shift+up/down. Cada um está construindo seu site de forma independente e simultânea. O agente líder monitora o progresso e reporta quando cada um termina.

**Resultados comparados**

Após alguns minutos, três sites completamente diferentes estão prontos:

- Minimalist: “Construindo na interseção de IA e ambição humana” — limpo, links sociais, tipografia elegante

- Dark: tema escuro com estética de desenvolvedor/tech, destaca projetos de código

- Warm: narrativa pessoal, seções contando a história, tom mais humano

O instrutor escolhe o warm como favorito e pede para iterar: “Gosta do design warm. Agora spawne mais três agentes, faça pesquisa sobre princípios de design eficazes e copywriting que converte, depois itere sobre este design e venha com suas próprias versões melhoradas.”

O agente líder spawna três agentes de pesquisa paralelos:

- **research-copy**: pesquisa melhores fórmulas de headline, copywriting pessoal, princípios de David Ogilvy

- **research-design**: pesquisa design para landing pages de criadores, uso de espaço negativo, hierarquia visual

- **research-examples**: analisa os sites de Ali Abdaal, Alex Hormozi, Dan Koe, Justin Welsh — extrai o que funciona

Os três pesquisam em paralelo (cada um com ~50.000 tokens de contexto), sintetizam seus achados, e reportam ao líder. O líder então spawna novos agentes de design usando essa inteligência. O resultado: sites muito mais refinados com:

- Copywriting orientado a conversão (“Você quer construir um negócio de automação, mas não sabe por onde começar”)

- Layout baseado em padrões de alta conversão (Z-pattern, F-pattern)

- Inspiração visual dos melhores sites de criadores

O custo de tudo isso: ~150.000 tokens. Para o instrutor, isso foi um investimento válido porque em dois minutos gerou designs que teriam levado horas para conceber manualmente. Mas o alerta permanece: use com discernimento.

**Comunicação entre agentes**

Uma funcionalidade diferenciadora dos agent teams é que os agentes podem se comunicar entre si. O instrutor mostra os logs onde um agente envia uma mensagem para o agente líder, o líder responde, e um segundo agente responde ao primeiro. É como um Slack ou fórum interno.

Esse scratch pad compartilhado permite:

- Agente 1 descobrir algo que economiza tempo para o Agente 2 e comunicar diretamente

- Agente 3 fazer uma pergunta ao Agente 1 sobre a abordagem dele

- O líder redirecionando recursos de agentes ociosos para tarefas urgentes

O custo de todo esse overhead de comunicação é tokens adicionais, mas pode resultar em um produto final de maior qualidade quando os agentes têm informações complementares.

**Recomendações práticas**

- Use Sonnet para os teammates, não Opus — é muito mais barato e para tarefas específicas é suficiente

- Mantenha teams pequenos — cada agente extra multiplica o custo

- Desligue os agentes quando terminar o trabalho — eles consomem recursos mesmo quando ociosos

- Não use para tarefas que podem ser feitas por um único agente

- Agent teams brilham em exploração de espaço de possibilidades: designs diferentes, abordagens diferentes, perspectivas diferentes

## AGENT TEAMS — ANÁLISE DE SEGURANÇA EM CODEBASE REAL 3:17:48

A demonstração mais impressionante do curso usa agent teams para analisar um repositório real de código aberto em busca de vulnerabilidades de segurança. O instrutor escolhe o repositório OpenClaw — um projeto open source relacionado ao Claude — para a demonstração.

O processo começa com o clone do repositório:

```bash

git clone [url-do-repositorio]

```

Depois, o instrutor abre o Claude Code dentro desse diretório e envia o seguinte prompt:

"OpenClaw é um projeto interessante, mas suspeito que tem vários problemas de segurança. Quero que você:

1. Crie um team com 10 agentes para analisar o codebase rapidamente, dividindo logicamente por tamanho de arquivo

2. Depois, spawne 4 agentes para documentar todos os problemas de segurança

3. Crie um 5º e 6º agente que joguem o papel de 'advogado do diabo' — um argumentando que os problemas não são reais, outro argumentando que são reais e precisam ser corrigidos

4. Use Sonnet para cada agente (janela de contexto maior)

5. Quando todos os problemas forem identificados, spawne um agente por problema de segurança para fazer as correções"

**O que aconteceu na execução**

O agente líder primeiro mapeou os arquivos do repositório e dividiu o trabalho de forma inteligente: não por quantidade igual de arquivos, mas por linhas de código (o que melhor representa o trabalho real). Os 10 agentes scanner receberam porções de 35.000 a 83.000 linhas cada.

Em paralelo, os 10 scanners começaram a trabalhar. O token counter estava em 1,3 milhões quando o instrutor olhou — e ainda subindo. Cada scanner tinha seu próprio contexto de 50.000-80.000 tokens.

Após os scanners terminarem, os resultados foram consolidados e passados para os 4 agentes documentadores que categorizaram as vulnerabilidades:

- Command injection e execução de código arbitrário

- Problemas de autenticação e autorização

- Path traversal, SSRF e disclosure de informações

- Criptografia fraca, race conditions e problemas de configuração

Então vieram os agentes de debate. “Devil #1” argumentava que as vulnerabilidades encontradas não eram reais ou não eram exploráveis. “Devil #2” argumentava que eram reais e precisavam de correção urgente. Os dois foram literalmente ter uma conversa — rounds de argumentação e contra-argumentação registrados no scratch pad do team.

O instrutor mostrou um trecho dessa conversa. Os agentes estavam debatendo tecnicamente: “esse path traversal requer que o atacante já tenha acesso ao servidor, então a superfície de ataque é mínima” versus “mesmo assim, segue o princípio de menor privilégio e deve ser corrigido”. Esse debate adversarial melhorou a qualidade da lista final de issues.

**Custo e resultado**

Apenas os 15 minutos dessa demonstração custaram cerca de 80 dólares em tokens. O instrutor foi explícito sobre isso. Mas compara: uma equipe de desenvolvedores levaria semanas para fazer o mesmo nível de análise de segurança em todo o codebase. Trocar 80 dólares por tempo de desenvolvimento é frequentemente um bom negócio — mas precisa ser uma decisão consciente.

O processo identificou 15 vulnerabilidades reais. O próximo passo seria spawnar 15 agentes de correção, um por problema, para fazer os fixes em paralelo. O instrutor cancelou antes disso para não gastar ainda mais tokens na demonstração.

**Cancelando agent teams**

Quando você precisa parar, você digita “SHUT” (em maiúsculas) no terminal. Os agentes não param instantaneamente — cada um precisa terminar a consulta atual antes de receber o sinal de shutdown. Há um delay de alguns segundos a minutos dependendo de onde cada agente está na execução. Tokens continuam sendo consumidos durante esse período.

**A metáfora da arma nuclear**

O instrutor usa uma metáfora colorida: agent teams são como uma arma nuclear apontada diretamente para sua carteira. Extremamente poderosos quando usados com precisão e propósito claro. Devastadores quando acionados por impulso.

Antes de criar um agent team, pergunte: isso realmente requer múltiplos agentes trabalhando colaborativamente, ou um único agente com boas instruções faz o mesmo trabalho? Na maioria dos casos, a resposta é “um único agente é suficiente”.

## GIT WORKTREES — DESENVOLVIMENTO PARALELO COM ISOLAMENTO 3:21:43

Git worktrees eram a forma principal de fazer desenvolvimento paralelo com Claude Code antes dos agent teams existirem. Mesmo agora, continuam sendo úteis como uma camada adicional de isolamento quando múltiplos agentes trabalham no mesmo repositório.

**O problema que worktrees resolvem**

Quando você tem múltiplos agentes trabalhando no mesmo codebase simultaneamente, eles inevitavelmente vão editar alguns dos mesmos arquivos. Mesmo que cada agente esteja trabalhando em uma feature diferente, há sempre arquivos compartilhados: configurações, utilitários, tipos base. Quando dois agentes editam o mesmo arquivo simultaneamente, você tem um conflito.

Git worktrees eliminam esse problema ao criar diretórios de trabalho completamente separados para cada branch. Cada agente trabalha em sua própria pasta — fisicamente separada no disco — que compartilha o histórico git mas não interfere nas outras.

**Como funciona na prática**

A demonstração usa um site chamado `leftclick-agency`. O instrutor quer adicionar três páginas novas: About, Contact e Services. Em vez de ter um único agente fazer as três páginas sequencialmente, ele usa agent teams com worktrees para fazer as três em paralelo.

Quando você configura o claude.md para referenciar o workflow de git worktrees, o Claude entende o padrão: para desenvolvimento paralelo, crie uma branch separada para cada feature, abra-a em sua própria pasta (worktree), e trabalhe lá sem tocar na pasta principal.

O resultado após executar o comando:

```

leftclick-agency/ ← pasta principal (main branch)

leftclick-agency-about/ ← branch about (worktree)

leftclick-agency-contact/ ← branch contact (worktree)

leftclick-agency-services/ ← branch services (worktree)

```

Três agentes diferentes trabalham em três pastas diferentes simultaneamente. Cada um recebe um prompt específico sobre o que construir e instruções explícitas para não modificar o index.html da pasta principal.

**Os resultados**

**About page**: design limpo com história da empresa, valores, e placeholders para imagens (o agente não sabia quais imagens usar). Inclui seções “Ready to work with us?”.

**Contact page**: formulário de contato funcional com validação JavaScript — você digita, campos com formato inválido ficam vermelhos, formulário só envia quando tudo está correto.

**Services page**: página mais longa e detalhada, com estimativas de preço para diferentes serviços. A mais elaborada das três.

**O passo de merge**

Após as três páginas ficarem prontas em suas branches separadas, o Claude coordena o processo de merge de volta para a main branch. Este é o ponto onde conflitos poderiam ocorrer, mas como cada agente trabalhou exclusivamente em seu próprio arquivo HTML e não tocou em arquivos compartilhados, o merge acontece sem conflitos.

**Quando usar worktrees vs agent teams sozinhos**

Agent teams sem worktrees: ideal para tarefas que não compartilham arquivos — pesquisa, análise, geração de conteúdo, coisas que ficam em arquivos distintos.

Agent teams com worktrees: ideal para desenvolvimento de software onde múltiplos agentes precisam trabalhar no mesmo repositório sem interferir uns nos outros.

A regra prática: se você está desenvolvendo em paralelo e há qualquer chance de dois agentes precisarem editar o mesmo arquivo, use worktrees. O overhead de configurar worktrees é mínimo e evita dores de cabeça com merges conflituosos.

**Claude.md para worktrees**

O instrutor disponibiliza seu claude.md que define o workflow de worktrees. A configuração basicamente explica ao Claude:

- O que são worktrees e como criar um

- Como nomear branches e pastas de forma consistente

- Quais arquivos cada agente tem permissão de modificar

- Como coordenar o merge final

Com esse contexto no claude.md, o Claude sabe exatamente o que fazer quando você pede “use o workflow de git worktrees para desenvolver estas três páginas em paralelo”.

## DEPLOY COM MODAL — PUBLICANDO FUNCIONALIDADES NA INTERNET 3:24:04

A última parte do curso técnico cobre algo que o instrutor chama de “a ponte entre o que você construiu localmente e o mundo”: como publicar suas skills, scripts e APIs na internet de forma rápida e acessível, mesmo sem ser um desenvolvedor web experiente.

O serviço recomendado é o **Modal** (modal.com) — “infraestrutura de IA que desenvolvedores amam”. A promessa: você consegue colocar código Python rodando na nuvem com uma URL acessível publicamente em questão de minutos, não horas ou dias.

**Por que Modal?**

Comparado a serviços como AWS Lambda, Google Cloud Functions ou Azure Functions, o Modal é dramaticamente mais simples de configurar. Comparado a plataformas no-code como Make.com ou n8n, é muito mais barato para volume de uso real.

O instrutor menciona que usa Modal há alguns meses e ainda tem quase 4,50 dólares de crédito restantes de um crédito inicial de 5 dólares — mesmo com uma requisição chegando a cada dia ou dois. Isso ilustra o custo extremamente baixo para casos de uso pessoal.

**Criando uma conta e primeiros passos**

1. Acesse modal.com e crie uma conta (Google sign-in disponível)

2. Complete o onboarding rapidamente (tipo de uso, como conheceu o serviço)

3. Você recebe 5 dólares de crédito imediato, com possibilidade de até 30 dólares completando tarefas de onboarding

4. Crie um API token em Settings → Tokens → New Token

5. Copie o token

**Integrando Modal com o Claude Code**

No claude.md do projeto, o instrutor tem um seção que explica como usar o Modal. Quando você cola seu API token no chat e diz “implante usando Modal”, o Claude sabe exatamente o que fazer.

A primeira demonstração: “implante um endpoint simples que retorna 'Feliz aniversário Nick' se for meu aniversário, ou 'Sem aniversário hoje mf' se não for”.

O Claude:

1. Cria um arquivo Python com o decorador `@modal.web_endpoint`

2. Adiciona a lógica de verificação da data

3. Roda `modal deploy` para publicar

4. Retorna uma URL pública no formato: `nome-usuario--nome-funcao.modal.run`

Testando com curl, a resposta chega imediatamente com a mensagem correta. O instrutor então pede para remover a autenticação e tornar acessível via browser com um GET simples, e também tornar a mensagem mais visual com HTML bonitinho. Em segundos, há uma página web funcional com a mensagem de aniversário, acessível para qualquer pessoa no mundo com a URL.

**O poder real: publicando skills como APIs**

A demonstração mais poderosa é pegar a skill de scrape de leads que construímos anteriormente e torná-la acessível via web. O instrutor copia a skill inteira para dentro do projeto Modal e pede: “coloque o workflow scrape-leads online. Quero que quando eu acesse a URL, apareça um formulário perguntando o que eu quer raspar. Eu preencho, você executa o workflow e retorna os leads em CSV.”

Em menos de dois minutos, o resultado é:

- Uma URL pública com um formulário HTML

- Campos para: termos de busca, país/estado, número de resultados desejados

- Botão “Raspar Leads”

- Após execução: download automático do CSV com os leads

O instrutor testa: preenche “dentistas, Estados Unidos, 100 resultados”, clica raspar, espera alguns segundos, e recebe o download do CSV com 100 dentistas, incluindo telefones, endereços e dados de contato. Tudo funcionando.

**Casos de uso práticos**

Uma vez que você tem uma URL que aciona um workflow, as possibilidades se multiplicam:

- **Webhooks**: plataformas como Make.com, n8n, Zapier e Lindy podem enviar dados para sua URL e receber resultados, integrando suas skills em fluxos de automação maiores

- **Ferramentas internas**: compartilhe a URL com sua equipe para que possam usar as ferramentas sem precisar configurar o ambiente de desenvolvimento

- **Automações programadas**: use serviços de cron para chamar sua URL periodicamente (ex: raspar leads toda segunda-feira de manhã)

- **Notificações**: configure um endpoint que você chama manualmente quando precisa de algo específico

A combinação Modal + Claude Code cria um ecossistema poderoso: você constrói a inteligência com Claude Code (skills, workflows), e usa Modal para transformá-la em serviços acessíveis que outras ferramentas podem consumir.

**Recomendação final**

Para não-programadores que querem usar suas skills em automações mais complexas, Modal é a peça que faltava. Você não precisa entender servidores, containerização ou infraestrutura de nuvem — o Claude Code + Modal cuida de tudo, e você fica com a URL que faz o que você precisa.

## EXTENDED THINKING — MODO DE RACIOCÍNIO PROFUNDO 3:27:34

Um tópico importante que foi abordado ao longo do curso mas merece uma seção dedicada é o Extended Thinking (pensamento estendido). Esta funcionalidade altera fundamentalmente como o Claude processa problemas complexos.

**O que é Extended Thinking**

Por padrão, o Claude pensa e escreve ao mesmo tempo — você vê o output crescendo progressivamente. Com Extended Thinking ativado, o Claude primeiro dedica um orçamento de tokens exclusivo para raciocinar sobre o problema, e só depois produz o output final.

A janela de “thinking” não é adicionada ao histórico de conversa da mesma forma que mensagens normais. Isso tem implicações importantes para eficiência de tokens: você pode dar ao Claude um orçamento enorme de raciocínio (8.000, 16.000, até 32.000 tokens) sem que todo esse processamento consuma sua janela de contexto de conversa.

**Como ativar**

No terminal, use `/model` para acessar as configurações de modelo. Além de trocar o modelo (Opus, Sonnet, Haiku), você encontra uma aba “Thinking” que permite:

- Desativar o thinking completamente (máxima eficiência de tokens, menor qualidade em tarefas complexas)

- Ativar thinking com orçamento específico de tokens (mínimo ~1.000, máximo ~32.000+)

- O nível de esforço afeta quanto o Claude vai raciocinar antes de responder

Na interface gráfica (GUI), há um indicador visual do processo de thinking que aparece antes do output final.

**Quando usar Extended Thinking**

O Extended Thinking tem maior impacto em:

- Problemas de lógica complexa (algoritmos, matematica, raciocínio multi-step)

- Decisões arquiteturais importantes (“qual é a melhor forma de estruturar este sistema?”)

- Análise de situações com muitas variáveis

- Qualquer tarefa onde você percebe que o Claude está tomando atalhos cognitivos

Para tarefas simples e rotineiras (editar um texto, fazer uma mudança pequena de código, formatar dados), thinking adicionado é desperdício.

**A estratégia do output conciso com thinking intenso**

Uma técnica mencionada pelo instrutor é usar ambos simultaneamente: ativar o thinking com orçamento alto, mas instruir o Claude no claude.md para “escrever outputs o mais concisos possível — raciocine o quanto precisar, mas quando responder, dê apenas o essencial. Se precisar de mais, vou perguntar.”

O resultado: o Claude pensa profundamente (tokens de thinking), mas o output que entra no contexto permanente da conversa é mínimo. Isso maximiza a qualidade do raciocínio sem explodir a janela de contexto com respostas verbosas.

## GESTÃO AVANÇADA DE CONTEXTO — TODAS AS ESTRATÉGIAS 3:28:32

O contexto é o recurso mais precioso e mais limitado quando se trabalha com Claude Code em sessões longas. O instrutor dedicou uma seção específica do curso à gestão de contexto, compilando as recomendações da própria documentação da Anthropic com suas próprias descobertas.

**Verificando o estado do contexto**

- `/cost`: mostra o custo atual da sessão em dólares e tokens

- `/context`: mostra a breakdown completa de como o contexto está sendo usado — system prompt, ferramentas MCP, memória, histórico de conversa

- Status line: configurável via `/status-line` para mostrar uma barra de progresso do uso de tokens constantemente visível no terminal (só funciona no terminal, não na GUI)

Para configurar o status line com uma barra de loading que mostra o percentual de tokens usados:

1. No terminal, rode `/status-line`

2. Descreva o que quer: “inclua uma barra de loading mostrando quantos tokens usei do total disponível”

3. O Claude cria o script de status e exibe no rodapé do terminal

**Compactação manual e automática**

`/compact`: compacta toda a conversa atual em um resumo de alta densidade informacional. O Claude analiza todo o histórico e cria um sumário que preserva as informações mais importantes em muito menos tokens.

Após a compactação, se você pedir “me diga o que está no seu contexto agora”, o Claude vai descrever o que foi preservado no resumo compactado. Você pode avaliar se informações importantes foram perdidas.

**Auto-compactação**: a Anthropic implementou um sistema de compactação contínua em background. As mensagens mais antigas são gradualmente compactadas enquanto a conversa avança, criando uma “cauda” de contexto de alta densidade atrás da conversa atual. Isso acontece automaticamente sem que você precise fazer nada.

**Compactação customizada**

Você pode fazer compactação direcionada: `/compact [instrução]`. Por exemplo:

- `/compact preserve all code snippets verbatim` — garante que código não seja simplificado durante a compactação

- `/compact focus on the architecture decisions made` — prioriza preservar as decisões arquiteturais

Isso é útil quando você sabe que certos tipos de informação são críticos para continuar o trabalho.

**Estratégias de economia de tokens**

1. **RAG (Retrieval Augmented Generation)**: em vez de carregar toda a documentação no contexto, use busca para trazer apenas os trechos relevantes quando necessário. Isso pode reduzir o uso de contexto em 70-80% em projetos que referenciam muita documentação.

2. **Claude.md enxuto**: mantenha o claude.md entre 200 e 500 tokens. Move regras complexas ou procedimentos detalhados para skills, que só são carregadas quando invocadas.

3. **Output conciso**: instrua o Claude no claude.md para “responder de forma sucinta. Raciocine o quanto precisar internamente, mas respostas devem ser diretas ao ponto. Se precisar de mais detalhes, peço.”

4. **Modelos menores para sub-agentes**: use Haiku ou Sonnet para sub-agentes que fazem trabalho repetitivo. Economiza tokens e é mais rápido.

5. **MCP server overhead**: audite regularmente seus servidores MCP com `/context` e remova os que você não usa. Um único servidor MCP mal otimizado pode consumir 15-20% da sua janela de contexto só com as definições de ferramentas.

6. **Mover instruções do claude.md para skills**: qualquer instrução que é mais “como fazer X” do que “sempre faça Y” deve ser uma skill, não uma regra no claude.md.

7. **/clear entre tarefas não relacionadas**: quando você muda completamente de assunto, use `/clear` para começar uma sessão limpa. O contexto de uma tarefa anterior raramente ajuda e frequentemente atrapalha.

8. **Prompts específicos**: “melhore este código” vs “corrija a função `processar_pagamento` em `src/pagamentos.py` para tratar o caso onde o usuário não tem saldo suficiente” — o segundo prompt produz um resultado melhor com muito menos tokens desperdiçados em exploração.

9. **Front-load o planejamento**: para tarefas complexas, investir em um bom plano antes de começar a implementar economiza tokens de backtracking. Errar a direção cedo e corrigir depois é muito mais caro do que planejar bem no início.

**A visão do instrutor sobre custo**

O instrutor é transparente sobre os custos ao longo do curso. Ele menciona ter gasto mais de 173 dólares em tokens durante a gravação do curso — isso inclui todos os experimentos, as demonstrações com agent teams, o código dos sistemas complexos que construiu.

Para um uso normal do dia a dia — desenvolvimento de projetos pessoais, skills de automação, análises — os custos são muito menores. Ele estima gastar entre 50 e 200 dólares por mês no Claude Code como parte central de suas operações de negócio, comparando isso ao salário de um desenvolvedor freelancer que faria a mesma quantidade de trabalho por 3.000 a 10.000 dólares por mês.

## FAST MODE E MODELOS DISPONÍVEIS 3:32:15

Durante todo o curso, o instrutor menciona repetidamente o “fast mode”. Esta seção consolida o que foi dito sobre modelos e velocidade.

**Os modelos principais**

À época da gravação, a linha de modelos da Anthropic inclui:

- **Claude Opus 4.6**: o modelo mais capaz, mais inteligente para tarefas complexas, mas o mais lento e caro

- **Claude Sonnet 4.5**: equilíbrio entre capacidade e custo, recomendado para a maioria das tarefas

- **Claude Haiku**: o mais rápido e mais barato, ideal para tarefas repetitivas e sub-agentes simples

**Fast mode com Opus 4.6**

O instrutor menciona que durante a gravação do curso, a Anthropic lançou um modo de execução mais rápida para o Opus 4.6 — especificamente, “2,5 vezes mais rápido por aproximadamente 3 vezes o preço”. Ele decide usar esse modo porque valoriza o tempo economizado mais do que o custo adicional.

Para habilitar fast mode no terminal: há uma opção nas configurações do modelo que permite ativar a execução em modo de alta velocidade. A opção específica depende da versão do Claude Code que você está usando.

**Escolhendo o modelo certo para cada tarefa**

Dentro do sistema de agent teams e sub-agentes, o instrutor sempre usa:

- **Opus** para o agente líder / pai: mais inteligente, melhor em síntese e tomada de decisão de alto nível

- **Sonnet** para a maioria dos sub-agentes e teammates: bom equilíbrio, janela de contexto maior, mais barato

- **Haiku** para tarefas muito simples e repetitivas onde a inteligência não é o fator limitante

Essa estratégia de “usar o modelo certo para o trabalho certo” pode reduzir os custos totais em 50-70% comparado a usar o Opus para tudo, sem perda significativa de qualidade no resultado final.

**Trocando modelos no terminal**

```

/model

```

Esse comando abre uma interface onde você pode:

- Ver qual modelo está ativo atualmente

- Trocar para qualquer modelo disponível

- Configurar o orçamento de Extended Thinking

- Ver informações sobre custos por modelo

Na GUI, há um seletor de modelo visível na interface principal.

## APLICAÇÃO PRÁTICA — RESUMO DE CASOS DE USO REAIS 3:33:41

O instrutor é dono de múltiplos negócios que coletivamente geram mais de 300.000 dólares por mês em lucro, e usa o Claude Code como infraestrutura central de operações. Esta seção consolida os casos de uso reais que ele demonstra ou menciona ao longo do curso.

**Negócio de dental marketing**

- Scraping de leads de dentistas nos EUA (skill scrape-leads)

- Geração de sites personalizados para cada prospect (skill de design de websites)

- Cold email automatizado via Instantly

- O ciclo completo de “encontrar prospect → criar material personalizado → enviar” acontece em minutos, não horas

**Agência LeftClick**

- Scraping e qualificação de leads para clientes

- Gestão de projetos via ClickUp MCP

- Geração de propostas customizadas (o app de propostas construído no curso)

- Pesquisa de mercado e análise de competidores via sub-agentes de pesquisa

**Conteúdo e YouTube**

- Uma das skills do instrutor faz gestão de conteúdo do YouTube automaticamente

- Monitoramento de posts em plataformas como Skool e classificação de comentários

- Auto-resposta a e-mails com o workflow gmail-label e extensões

**Pesquisa pessoal**

- Skill de literature review para pesquisas científicas (nutrição, saúde, negócios)

- Consulta ao PubMed e outras bases de dados em segundos

- Relatórios estruturados sobre qualquer tópico em minutos

**Maker School**

- Programa de 90 dias para empreendedores construírem agências de automação

- O instrutor usa o Claude Code para criar materiais de curso, exemplos práticos, conteúdo educacional

- O próprio sistema de proposals do curso foi construído ao vivo como demonstração

**A filosofia por trás**

O instrutor articula uma perspectiva econômica clara: antes do Claude Code, ele contratava freelancers para tarefas específicas — scraping de leads, pesquisa, desenvolvimento de ferramentas. Cada freelancer levava horas ou dias e custava centenas a milhares de dólares. Agora as mesmas tarefas são feitas por skills em minutos ou horas, por frações do custo.

Ele não está romantizando isso nem sugerindo que IA é superior a humanos em tudo. Para trabalho criativo complexo, estratégia de alto nível e relacionamento com clientes, humanos ainda ganham. Mas para o trabalho operacional repetitivo que consome a maior parte do tempo de uma empresa em crescimento, a IA é uma alavancagem enorme.

## CONFIGURAÇÕES AVANÇADAS DO CLAUDE CODE 3:35:07

Esta seção compila as configurações menos óbvias mas muito úteis do Claude Code que foram mencionadas ao longo do curso.

**O arquivo settings.json**

Localizado em `.claude/settings.json` no seu workspace (ou globalmente), este arquivo controla comportamentos específicos do Claude Code. Algumas configurações úteis:

```json

{

“env”: {

“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”

}

}

```

Esse formato básico pode incluir outras variáveis de ambiente que controlam funcionalidades experimentais.

**Bypass de permissões**

Em modo interativo, o Claude pede confirmação antes de executar comandos bash, criar arquivos ou fazer outras ações. Para sessões de desenvolvimento intensivo onde você confia no que o Claude vai fazer, é possível pressionar Shift+Tab para ativar o modo de bypass, onde o Claude executa sem pedir confirmação.

Use com cuidado: em modo bypass, o Claude pode fazer mudanças irreversíveis sem confirmação. Sempre trabalhe em branches separadas ou com backup quando usar bypass em código importante.

**Status line no terminal**

Configurável via `/status-line`. Permite exibir informações customizadas no rodapé do terminal, como:

- Percentual de tokens usados (barra de loading)

- Modelo atual

- Branch git atual

- Qualquer outra informação que você queira monitorar

Exemplo de prompt para configurar: “Adicione uma barra de loading no status line mostrando quantos tokens usei do total disponível no contexto.”

**Comandos especiais úteis**

- `/clear`: limpa toda a conversa, começando com contexto mínimo

- `/compact`: compacta a conversa mantendo informação essencial

- `/compact [instrução]`: compacta com prioridades específicas

- `/cost`: mostra custo atual em tokens e dólares

- `/context`: breakdown detalhado de uso de contexto

- `/model`: troca de modelo e configurações de thinking

- `/status-line`: configura a linha de status

- `/mcp`: gerencia servidores MCP instalados

**Memória por projeto vs global**

As memórias do Claude persistem entre sessões de duas formas:

- **Global**: disponíveis em qualquer projeto, configuradas via `claude --memory`

- **Por projeto**: específicas do projeto atual, salvas no `.claude/` do projeto

Para evitar poluir memórias de projetos diferentes, seja específico sobre onde salvar cada tipo de informação.

## BOAS PRÁTICAS — DICAS FINAIS DO INSTRUTOR 3:37:18

Consolidando os conselhos práticos que o instrutor distribui ao longo do curso, esta seção funciona como um checklist de boas práticas para qualquer pessoa que queira usar o Claude Code de forma profissional e eficiente.

**Sobre configuração inicial**

1. Invista tempo no seu claude.md — ele define a “personalidade” e as capacidades do seu agente. Um bom claude.md economiza horas de retrabalho em cada projeto.

2. Use a estrutura .claude/ para separar memórias, skills e sub-agentes de forma organizada. Quanto mais organizado, mais o Claude vai conseguir encontrar e usar o que você criou.

3. Configure os MCPs que você usa com frequência uma vez, e depois decida quais valem a pena manter (considerando o custo de tokens) versus converter para skills.

4. Defina limites de gasto mensal nas configurações do Claude Code. Isso protege você de acidentes com agent teams ou loops infinitos.

**Sobre workflow de desenvolvimento**

5. Para qualquer tarefa não trivial, comece com planejamento: “antes de implementar, me dê um plano passo a passo do que você vai fazer”. Revisar o plano é muito mais rápido do que revisar código que foi na direção errada.

6. Use o loop de screenshot quando estiver construindo interfaces: build → screenshot → avaliar → ajustar. Isso é especialmente poderoso para matching de designs.

7. Crie skills para qualquer coisa que você faz mais de uma vez. O retorno sobre o investimento de criar uma skill aparece já na segunda execução.

8. Quando usar sub-agentes, mantenha as tarefas de cada um simples e bem definidas. Complexidade excessiva nas instruções dos sub-agentes aumenta a probabilidade de falha.

9. Use git e git worktrees — mesmo que você não seja programador. Ter um histórico de commits significa que você pode sempre reverter para uma versão que funcionava.

**Sobre custos e eficiência**

10. Monitore regularmente o uso de contexto com `/context`. Se as ferramentas MCP estão consumindo mais de 20-25% do contexto, é hora de auditar quais você realmente usa.

11. Faça `/compact` quando o custo da sessão passar de um certo limiar. Um bom sinal é quando você nota que o Claude está “esquecendo” coisas que mencionou cedo na conversa — isso indica que o contexto está fragmentado.

12. Use `/clear` quando mudar completamente de tarefa. O contexto de um projeto de e-commerce raramente ajuda quando você está trabalhando em um script de análise de dados.

13. Para pesquisa pesada, use sub-agentes com modelos menores (Sonnet, Haiku). Reserve o Opus para síntese, decisão e geração de outputs finais.

**Sobre segurança**

14. Nunca ative bypass de permissões em repos com código que afeta usuários reais em produção, sem ter um backup.

15. Revise os MCPs que você instala — são código de terceiros com acesso aos seus dados e sistema. Verifique a reputação, o número de stars no GitHub e os issues abertos antes de instalar.

16. Não coloque credenciais de API diretamente no claude.md ou em skills commitadas no git. Use variáveis de ambiente ou arquivos de configuração que estão no .gitignore.

17. Ao criar ferramentas que acessam e-mails, dados financeiros ou qualquer informação sensível, pense antes sobre quem vai ter acesso à URL final se você publicar via Modal ou similar.

**Sobre expectativas**

18. O Claude Code não vai acertar tudo de primeira. A iteração é parte do processo — e o loop de “rodar, ver o que aconteceu, ajustar” é muito mais rápido com IA do que sem.

19. Quanto mais específico e contextualizado for seu prompt, melhor o resultado. “Melhore isso” produz resultados genéricos. “Corrija a função X para tratar o caso Y” produz o que você precisa.

20. Documente o que funciona. Quando você encontrar um prompt que produziu um resultado excelente, salve como skill ou como nota no claude.md. Você vai querer reusar.

## O FLUXO COMPLETO — DA IDEIA AO PRODUTO EM PRODUÇÃO 3:40:00

Para consolidar tudo que foi aprendido no curso, vale a pena percorrer o fluxo completo de um projeto real do início ao fim. O instrutor demonstrou isso várias vezes, mas esta seção vai explicitar cada etapa com clareza.

**Etapa 1: Definir o problema com precisão**

Antes de abrir o Claude Code, responda: O que precisa existir que não existe? Quem vai usar? Como vão usar? Quais são os critérios de sucesso?

Exemplo bom: “Preciso de uma página web onde minha equipe de vendas preenche um formulário com informações de um prospect e recebe um PDF de proposta customizado em menos de 30 segundos.”

Exemplo ruim: “Quero algo para propostas.”

**Etapa 2: Preparar o contexto**

Antes de começar a sessão do Claude Code:

- Selecione a pasta/workspace adequado

- Certifique-se que o claude.md tem o contexto relevante para este projeto

- Tenha à mão: referências visuais (screenshots, links), dados de exemplo, qualquer documentação relevante

**Etapa 3: Planejamento com o Claude**

“Antes de implementar, me dê um plano passo a passo do que você vai construir.”

Revise o plano. Corrija qualquer mal-entendido. Adicione restrições que você esqueceu de mencionar. O planejamento é barato — a implementação na direção errada é cara.

**Etapa 4: Implementação iterativa**

Ative bypass de permissões se confiar no escopo. Deixe o Claude trabalhar. Monitore o progresso nas tasks. Quando parar para sua avaliação, teste imediatamente o que foi construído.

Para interfaces, use o loop de screenshot constantemente. Para funcionalidades, teste com dados reais o mais cedo possível.

**Etapa 5: Refinamento**

Identifique o que está faltando ou errado. Seja específico nos pedidos de ajuste. Separe sessões de desenvolvimento de sessões de refinamento para evitar acúmulo de contexto desnecessário.

**Etapa 6: Qualidade (quando relevante)**

Para projetos que vão para produção com usuários reais:

- Use o sub-agente de Code Review nos arquivos modificados

- Use o sub-agente de QA para gerar e rodar testes

- Corrija todos os issues bloqueantes antes de prosseguir

**Etapa 7: Deploy**

Para sites estáticos: Netlify

- Arraste a pasta para o Netlify Drop ou conecte o GitHub repo

- URL pública em segundos

Para APIs e scripts Python: Modal

- O Claude configura tudo com as credenciais certas

- URL pública após `modal deploy`

Para aplicações mais complexas: qualquer plataforma de cloud que o Claude Code consiga configurar — Vercel, Railway, Fly.io, etc.

**Etapa 8: Transformar em skill (se vai usar de novo)**

Se o que você construiu é um processo que vai repetir, transforme em skill. Você vai economizar tempo todas as vezes que for executar no futuro.

**Etapa 9: Monitorar e iterar**

Sistemas de IA não são “build once, forget forever”. O que funciona hoje pode precisar de ajustes amanhã quando os dados ou requisitos mudam. Mantenha um registro de como suas skills e sistemas estão performando.

## CONSTRUINDO UM NEGÓCIO COM CLAUDE CODE — A VISÃO DO INSTRUTOR 3:41:38

Nos momentos mais pessoais do curso, o instrutor compartilha reflexões mais amplas sobre o impacto do Claude Code em sua vida profissional e nos negócios que opera.

**“Por que eu não contrato mais funcionários”**

Essa frase resume muito da filosofia do instrutor. Ele construiu um portfólio de negócios que gera mais de 300.000 dólares por mês em lucro sem uma equipe grande. As funções que antes exigiam contratações específicas — pesquisador, desenvolvedor de ferramentas, operador de leads, gestor de e-mails — são agora executadas por sistemas de IA que ele mesmo construiu.

Isso não é apresentado como “IA vai tirar empregos” de forma alarmista. A perspectiva é mais prática: para empreendedores individuais e pequenas equipes, a IA remove a barreira entre ter uma ideia e conseguir implementá-la. Você não precisa mais esperar dias para contratar um freelancer, gastar horas de briefing, e depois ainda ter que revisar o trabalho.

**Sobre o retorno do investimento**

O instrutor calcula o ROI de forma direta: ele paga entre 50 e 200 dólares por mês em tokens (dependendo do volume de trabalho). Esse valor substitui o que seriam milhares de dólares em trabalho humano por mês — mesmo em países com mão de obra mais barata.

Para um empreendedor, o ROI não é só financeiro. É o tempo recuperado. É a velocidade de execução. É a capacidade de testar ideias sem o ciclo longo de contratação → briefing → desenvolvimento → revisão → entrega.

**Sobre a curva de aprendizado**

O instrutor é honesto: as primeiras semanas com o Claude Code têm frustração. A ferramenta é poderosa, mas requer entender sua “linguagem” — como estruturar prompts, quando usar qual funcionalidade, como interpretar os erros que acontecem.

O investimento de aprendizado vale a pena. Mas não espere resultados mágicos no primeiro dia. Espere um mês de uso regular antes de avaliar se está te dando retorno.

**Sobre Maker School**

O único pitch comercial do curso: Maker School é um programa de 90 dias com acompanhamento diário para ajudar empreendedores a conseguir seu primeiro cliente em consultoria de automação e IA. O instrutor garante o resultado (primeiro cliente em 90 dias ou dinheiro de volta).

O programa usa o mesmo stack de ferramentas ensinadas no curso. O objetivo é ajudar as pessoas a transformar o conhecimento técnico em negócio real, com clientes reais e receita real.

**Palavras finais**

“Você agora tem tudo que precisa para construir a base de conhecimento — seja programador experiente, desenvolvedor iniciante ou completamente não-técnico. O Claude Code democratizou o acesso a capacidades que antes eram restritas a quem tinha equipes grandes ou orçamentos de desenvolvimento expressivos.”

“Se tiver dúvidas sobre qualquer coisa que mostrei no vídeo, deixe nos comentários. Terei um bom dia, e até o próximo curso.”

## REFERÊNCIA RÁPIDA — COMANDOS E ATALHOS DO CLAUDE CODE 3:43:51

Um guia de referência rápida para todos os comandos e atalhos mencionados ao longo do curso.

**Comandos de barra (/)**

| Comando | O que faz |

|---------|-----------|

| `/clear` | Limpa toda a conversa, contexto zerado |

| `/compact` | Compacta a conversa em resumo denso |

| `/compact [instrução]` | Compacta com prioridades específicas |

| `/cost` | Mostra custo atual em tokens e dólares |

| `/context` | Breakdown detalhado do uso de contexto |

| `/model` | Troca o modelo, configura thinking |

| `/status-line` | Configura linha de status no terminal |

| `/mcp` | Gerencia servidores MCP instalados |

| `/help` | Lista todos os comandos disponíveis |

**Modos de permissão (terminal)**

| Ação | Efeito |

|------|--------|

| Tab | Aceita uma ação específica |

| Shift+Tab | Ativa bypass (aceita tudo automaticamente) |

| Ctrl+C | Cancela a ação atual |

| Escape | Cancela sem executar |

**Navegação em agent teams (terminal)**

| Atalho | Efeito |

|--------|--------|

| Shift+Up | Vai para o agente acima |

| Shift+Down | Vai para o agente abaixo |

| Enter | Entra no contexto do agente selecionado |

**Estrutura de pastas recomendada**

```

projeto/

├── .claude/

│ ├── settings.json ← configurações do workspace

│ ├── memories/ ← arquivos de memória persistente

│ ├── skills/ ← suas skills customizadas

│ │ └── nome-skill/

│ │ ├── skill.md

│ │ └── scripts/

│ └── agents/ ← especificações de sub-agentes

│ └── nome-agente.md

├── claude.md ← instruções do projeto (raiz)

└── [código do projeto]

```

**Variáveis de ambiente úteis (settings.json)**

```json

{

“env”: {

“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”,

“CLAUDE_CODE_MAX_TOKENS”: “200000”,

“ANTHROPIC_MODEL”: “claude-opus-4-6”

}

}

```

## PERGUNTAS FREQUENTES — DÚVIDAS COMUNS DE INICIANTES 3:45:36

Ao longo do curso, o instrutor antecipa e responde diversas dúvidas que iniciantes costumam ter. Esta seção compila as mais importantes.

**“Preciso saber programar para usar o Claude Code?”**

Não. O instrutor é explícito sobre isso desde o início. Você vai escrever código ao trabalhar com o Claude Code, mas você não precisa escrever esse código — o Claude escreve por você. O que você precisa é descrever claramente o que quer que o sistema faça.

A analogia usada: você não precisa saber dirigir um táxi para chegar ao destino, mas precisa saber o endereço. Da mesma forma, você não precisa saber Python para criar uma skill de scraping, mas precisa saber o que você quer que a skill faça.

**“Qual é a diferença entre usar o Claude no browser e o Claude Code?”**

O Claude no browser (claude.ai) é uma interface de chat simples. O Claude Code é um ambiente de desenvolvimento completo que:

- Tem acesso ao seu sistema de arquivos

- Pode executar código e comandos bash

- Persiste memórias entre sessões

- Tem skills, sub-agentes e agent teams

- Pode instalar e usar MCPs

- Tem acesso à internet para pesquisa

Para desenvolvimento, automação e criação de sistemas, o Claude Code é muito mais poderoso. Para conversas casuais, análise de documentos e brainstorming, o chat do browser é suficiente.

**“Qual IDE usar com o Claude Code?”**

O Claude Code funciona em qualquer IDE. O instrutor usa principalmente o VS Code (que ele chama de “anti-gravity” na demonstração — provavelmente um fork ou tema customizado) e o terminal nativo.

A diferença principal: o terminal dá acesso a funcionalidades como status line e a navegação de agent teams que a GUI não suporta. Para uso avançado, recomenda-se passar mais tempo no terminal.

Para iniciantes: comece com a interface gráfica (GUI) onde você tem o painel de chat familiar. Gradualmente explore o terminal para funcionalidades avançadas.

**“Como sei quando meu contexto está ficando grande demais?”**

Sinais de alerta:

- O Claude começa a “esquecer” coisas mencionadas cedo na conversa

- Respostas ficam mais genéricas, menos específicas ao seu projeto

- O `/cost` mostra uso de tokens alto (mais de 50% do limite)

- O Claude começa a refazer coisas que já foram feitas antes

Solução: `/compact` para compactar a conversa, ou `/clear` se o contexto atual não for mais relevante.

**“Devo usar o GUI ou o terminal?”**

O instrutor demonstra ambos e tem uma posição clara: o terminal oferece mais controle e funcionalidades exclusivas (status line, navegação de agent teams). Mas a GUI tem seu lugar para iniciantes e para tarefas rápidas onde a interface visual ajuda.

Recomendação prática: aprenda a usar ambos. Use a GUI para começar e quando precisar ver o output de forma visual. Use o terminal para desenvolvimento intensivo, agent teams e quando quiser máximo controle.

**“Quanto custa usar o Claude Code?”**

O Claude Code tem um plano com uso incluído (a partir de ~20 dólares por mês) e depois cobra por tokens além desse limite. O custo real depende muito do que você faz:

- Uso casual/pessoal: 10-30 dólares por mês

- Desenvolvimento intensivo diário: 50-150 dólares por mês

- Agent teams com projetos grandes: pode chegar a centenas por sessão

O instrutor menciona ter gasto 173+ dólares em tokens durante a gravação de um único curso de 4 horas com muitas demonstrações intensivas. Para uso normal, o custo é muito menor.

**“Como o Claude Code lida com segredos e credenciais?”**

Nunca coloque credenciais diretamente em prompts ou em arquivos que você vai commitar no git. O Claude Code usa variáveis de ambiente para isso. Você pode:

1. Definir variáveis de ambiente no seu sistema operacional

2. Usar um arquivo `.env` que está no `.gitignore`

3. Usar um gerenciador de segredos como 1Password ou AWS Secrets Manager

Quando precisar passar uma API key ao Claude, faça isso via variável de ambiente, nunca no texto da conversa.

**“As skills funcionam com qualquer linguagem de programação?”**

Sim. As skills são escritas em Markdown e os scripts dentro delas podem ser em qualquer linguagem que esteja instalada no seu sistema: Python, JavaScript/Node.js, Bash, Ruby, etc. O instrutor usa principalmente Python, mas a abordagem funciona com qualquer linguagem.

Para automatizações no Mac, scripts AppleScript e Shell também funcionam. Para integração com Microsoft Office, VBA scripts são possíveis. A skill.md é a cola que conecta tudo — os scripts em si podem ser escritos no idioma que faz mais sentido para cada tarefa.

## TOMADA DE SCREENSHOTS — LOOP VISUAL DE DESENVOLVIMENTO 3:48:52

Uma técnica central no workflow de desenvolvimento com Claude Code é o uso sistemático de screenshots para feedback visual. O instrutor demonstra isso repetidamente e vale a pena entender em profundidade como funciona.

**Por que screenshots são tão poderosos**

Quando você está construindo uma interface visual — site, app, dashboard — texto descrevendo “o botão está um pouco para a esquerda” é impreciso e sujeito a interpretação. Uma screenshot elimina toda ambiguidade: o Claude vê exatamente o que você está vendo.

Mais importante: o Claude pode comparar a screenshot do resultado atual com uma screenshot do design desejado e identificar as diferenças pixel a pixel. Isso transforma o processo de ajuste de interface de “descrever o problema em palavras” para “mostrar o problema visualmente”.

**O loop padrão de desenvolvimento visual**

1. **Build**: o Claude constrói ou modifica a interface

2. **Preview**: você abre o arquivo HTML no browser ou usa o Chrome DevTools MCP

3. **Screenshot**: você tira uma screenshot do resultado atual

4. **Compare**: você cola a screenshot no chat com o design desejado lado a lado (se houver)

5. **Feedback**: você descreve o que está errado ou o Claude identifica as diferenças automaticamente

6. **Ajuste**: o Claude faz as correções

7. **Repetir**: volta ao passo 2 até estar satisfeito

**Como tirar e colar screenshots no Claude Code**

No Mac:

- `Cmd+Shift+4`: seleciona área para screenshot

- `Cmd+Shift+3`: screenshot da tela inteira

- As screenshots vão para a área de transferência ou para o Desktop

Para colar no Claude Code:

- Na GUI: `Cmd+V` cola a imagem diretamente no campo de texto

- No terminal: algumas integrações permitem drag-and-drop de arquivos

**Usando o Chrome DevTools MCP para screenshots automáticas**

Com o Chrome DevTools MCP instalado, você pode pedir ao Claude para tirar screenshots automaticamente como parte do workflow:

“Abra o arquivo index.html no Chrome, tire um screenshot, compare com o design de referência e liste as diferenças.”

O Claude vai:

1. Abrir o arquivo no Chrome via MCP

2. Tirar um screenshot

3. Analisar visualmente

4. Listar diferenças específicas (cor errada no header, texto muito grande, espaçamento incorreto)

5. Fazer as correções no código

6. Tirar outro screenshot para confirmar que as correções funcionaram

Esse loop pode acontecer 5-10 vezes rapidamente, convergindo para um resultado que corresponde ao design desejado sem você precisar fazer nada além do feedback inicial.

**Referências visuais externas**

O workflow de copiar designs de sites existentes usa screenshots da mesma forma:

1. Você navega até um site que você gosta (godly.website tem ótimos exemplos)

2. Tira um screenshot do design que quer replicar

3. Cola no Claude: “reproduza esse design para o meu produto”

4. O Claude analisa o screenshot e extrai: paleta de cores, tipografia, layout, espaçamentos

5. Implementa o mesmo estilo para o seu conteúdo

Essa abordagem produz resultados muito mais próximos do que você imagina do que tentar descrever o design em palavras.

**Limitações**

Screenshots são grandes em termos de tokens. Uma screenshot de alta resolução pode consumir 1.000-3.000 tokens. Para sessões longas com muitos ajustes visuais, isso pode impactar o custo.

Soluções:

- Use screenshots de resolução moderada (não precisa ser 4K para o Claude entender o design)

- Faça `/compact` periodicamente em sessões visuais intensivas

- Quando a interface estiver quase certa, use descrições textuais para os últimos ajustes finos em vez de mais screenshots

## INTEGRAÇÃO COM FERRAMENTAS NO-CODE — N8N, MAKE E ZAPIER 3:51:03

Um tema que aparece no final do curso mas merece atenção especial é como o Claude Code se integra com plataformas de automação no-code. Isso abre um novo nível de possibilidades para empreendedores que já usam essas ferramentas.

**A ponte: webhooks e URLs públicas**

Plataformas como n8n, Make.com, Zapier e Lindy se comunicam com o mundo externo principalmente via webhooks — URLs que recebem dados quando um evento acontece, ou que você chama para disparar uma ação.

Quando você publica um script Python via Modal, você cria exatamente isso: uma URL que faz algo quando é chamada. Essa URL pode receber dados (via POST) ou simplesmente ser acessada (via GET) para disparar um processo.

**Casos de uso de integração**

**Cenário 1: Trigger automático de scraping**

No Make.com, você configura um cenário que roda toda segunda-feira às 9h. O trigger chama sua URL do Modal com os parâmetros “dentistas, São Paulo, 500 resultados”. O endpoint dispara a skill de scraping, e 2 minutos depois você tem 500 novos leads na sua planilha do Google.

**Cenário 2: Processamento de e-mails incomuns**

Você tem um fluxo no n8n que monitora sua caixa de entrada. Quando chega um e-mail com “proposta” no assunto, o n8n chama sua URL do Modal passando o conteúdo do e-mail. Sua API lê o e-mail, extrai as informações relevantes do cliente, gera uma proposta customizada e retorna um link para o PDF. O n8n então responde automaticamente ao e-mail com o link da proposta.

**Cenário 3: Webhooks de CRM**

Quando um novo lead entra no seu CRM, um webhook chama sua API. Sua skill pesquisa o prospect na internet, verifica o LinkedIn, analisa o site da empresa, e retorna um briefing completo. O CRM então atualiza o registro com esse contexto, e quando o vendedor abre o lead, já tem toda a informação necessária.

**Cenário 4: Integração com formulários**

Um formulário de contato no seu site envia os dados para uma URL do Modal. A API processa as informações, determina qual serviço é mais relevante para o prospect, e dispara automaticamente: (1) um e-mail de boas-vindas personalizado, (2) uma tarefa no ClickUp para follow-up, (3) adiciona o lead à sequência correta no Instantly.

**A vantagem sobre automações tradicionais**

A diferença fundamental entre uma automação no-code tradicional e uma com Claude Code no meio:

Automação tradicional: se o e-mail está no formato esperado, a automação funciona. Se não está, falha ou produz resultados errados.

Automação com Claude Code: o LLM interpreta o conteúdo semântico. Um e-mail de um cliente em potencial, mesmo que escrito de forma informal ou inusitada, vai ser corretamente classificado como “oportunidade de venda” e tratado adequadamente.

Essa flexibilidade semântica é o que torna as integrações com LLMs fundamentalmente diferentes das automações baseadas em regras.

**Construindo o endpoint correto**

Para uma integração robusta com plataformas no-code, seus endpoints Modal devem:

1. Aceitar dados via POST com JSON no body

2. Retornar respostas no formato JSON para facilitar o parsing pela plataforma

3. Incluir tratamento de erros com status codes HTTP adequados (200 sucesso, 400 input inválido, 500 erro interno)

4. Ter autenticação via API key para evitar uso indevido

5. Retornar em tempo razoável — plataformas no-code geralmente têm timeout de 30-60 segundos

O Claude Code pode construir um endpoint com todas essas características em poucos minutos, dado um prompt bem descrito.

## NETLIFY — PUBLICANDO SITES ESTÁTICOS INSTANTANEAMENTE 3:54:07

Para sites e aplicações que não precisam de backend dinâmico (HTML, CSS, JavaScript puro), o Netlify é a solução mais rápida e simples que o instrutor recomenda.

**O que é o Netlify**

Netlify é uma plataforma de hospedagem que permite publicar sites estáticos gratuitamente com uma URL pública. O plano gratuito é generoso o suficiente para a maioria dos projetos pessoais e até alguns profissionais.

**Deploying via Netlify Drop**

A forma mais simples de usar o Netlify é o “Netlify Drop”:

1. Acesse app.netlify.com/drop

2. Arraste a pasta do seu projeto para a área indicada

3. Em menos de 30 segundos, você tem uma URL no formato `random-name.netlify.app`

Isso é o que o instrutor faz com o primeiro site que constrói no curso (o site-vitrine simples) e com o app de propostas.

**Conectando ao GitHub para deploy automático**

Para projetos que você vai continuar desenvolvendo:

1. Conecte seu repositório GitHub ao Netlify

2. Configure qual branch é a de produção (geralmente `main`)

3. A cada push para essa branch, o Netlify automaticamente constrói e publica a nova versão

Com esse setup, o fluxo de deploy fica: `git push` → Netlify publica automaticamente. O Claude Code pode fazer o commit e push, e você tem o site atualizado em menos de um minuto.

**Domínio customizado**

O Netlify permite adicionar domínios customizados, incluindo SSL/HTTPS gratuito via Let's Encrypt. Em vez de `random-name.netlify.app`, você pode ter `suaempresa.com`. O processo leva menos de 10 minutos e o Claude Code pode guiar através das configurações de DNS necessárias.

**Quando usar Netlify vs Modal**

- **Netlify**: sites e apps com apenas frontend (HTML/CSS/JS). Exemplos: landing pages, portfolios, documentação, apps React/Vue sem backend.

- **Modal**: quando você precisa executar código Python no servidor, processar dados, acessar APIs externas de forma segura, ou ter endpoints que fazem computação. Exemplos: skills como serviço, processamento de dados, integrações com APIs.

Para projetos complexos, você pode usar ambos: Netlify para o frontend, Modal para as APIs que o frontend consome.

## MODOS DE OPERAÇÃO — INTERATIVO VS HEADLESS 3:55:56

Uma distinção importante que o instrutor menciona brevemente mas é valiosa entender é a diferença entre os modos de operação do Claude Code.

**Modo interativo (padrão)**

O modo padrão que usamos ao longo de todo o curso. Você abre o Claude Code, digita mensagens, e o Claude responde e executa ações. Há um loop de conversa onde você fornece direcionamento e feedback.

Características:

- Você está presente e pode intervir a qualquer momento

- O Claude pede confirmação antes de ações irreversíveis (a menos que bypass esteja ativo)

- Ideal para desenvolvimento ativo onde você quer supervisionar o processo

**Modo headless**

O Claude Code pode ser executado sem interface, em modo “non-interactive”, onde você passa um prompt pela linha de comando e ele executa e retorna o resultado. Isso é essencial para automações.

Sintaxe básica:

```bash

claude --headless --prompt “sua instrução aqui”

```

Ou redirecionando um arquivo de instrução:

```bash

claude --headless < instrucoes.txt

```

**Casos de uso para headless**

- **Scripts de automação**: um script Python pode chamar o Claude Code headless para processar dados, gerar conteúdo ou fazer análises

- **Cron jobs**: executar o Claude Code periodicamente sem interação humana (ex: “toda noite, analise os leads do dia e classifique”)

- **Pipelines de CI/CD**: usar o Claude como parte de um pipeline de integração contínua para revisão de código automática

- **Integração com outras ferramentas**: quando você quer que o Claude seja uma etapa em um fluxo maior gerenciado por outro sistema

**A conexão com skills e Modal**

Quando você publica uma skill via Modal, nos bastidores o que está acontecendo é essencialmente um modo headless: o Modal recebe uma requisição HTTP, passa as informações para o Claude Code via linha de comando, e retorna o output.

Isso fecha o ciclo: você constrói com o Claude Code interativamente, extrai o workflow como skill, e depois disponibiliza essa skill como serviço via Modal. O resultado é um sistema que executa a inteligência do Claude de forma autônoma, sem nenhuma interação humana no loop.

## CONSTRUINDO O APP DE PROPOSTAS — PASSO A PASSO DETALHADO 3:56:44

Esta seção reconstrói o fluxo completo da demonstração mais longa do curso: o app de geração de propostas comerciais. Este é o projeto que melhor ilustra o processo completo de desenvolvimento com Claude Code.

**O problema a resolver**

O instrutor precisa de um sistema onde, dado o nome ou URL de um prospect, o sistema pesquisa informações sobre a empresa e gera automaticamente uma proposta comercial personalizada em formato HTML profissional.

O processo atualmente manual demora entre 30 minutos a 2 horas, dependendo da complexidade da proposta. O objetivo é reduzi-lo para menos de 2 minutos.

**Fase 1: Construindo a base sem banco de dados**

Antes de qualquer plano formal, o instrutor parte para uma abordagem direta: “construa um app de geração de propostas, funcionalidades básicas, sem banco de dados, que produza um HTML pronto para usar.”

O Claude produz uma primeira versão em minutos. Ela funciona, mas é básica — HTML simples, design sem graça, sem personalização real.

**Fase 2: Melhorando o design com referência visual**

O instrutor vai ao godly.website (curador de melhores designs web), encontra um template que gosta, tira um screenshot e volta para o Claude: “redesenhe o app para que as propostas geradas se pareçam com este design.”

O Claude analisa o screenshot, extrai a paleta de cores, a tipografia, o layout, e reimplementa o gerador de propostas com esse estilo. O resultado é visualmente muito superior.

**Fase 3: Pesquisa automática sobre o prospect**

A funcionalidade mais impressionante: quando o usuário entra com o nome ou URL de uma empresa, o sistema vai pesquisar automaticamente informações sobre ela — site, LinkedIn, setor de atuação, tamanho estimado, principais produtos/serviços.

Para isso, o Claude integra chamadas à API de pesquisa web e usa essa informação para personalizar o conteúdo da proposta. Em vez de “Prezada empresa”, a proposta tem “Prezada [Nome real da empresa], que atua no setor de [setor identificado]...”

**Fase 4: Adicionando banco de dados com Supabase**

À medida que o projeto evolui, surge a necessidade de persistência — salvar as propostas geradas para referência futura, poder ver propostas enviadas anteriormente, editar uma proposta existente.

O instrutor integra o Supabase (banco de dados PostgreSQL na nuvem com interface amigável): “adicione banco de dados usando Supabase para salvar todas as propostas geradas, com campos de timestamp, nome do cliente, valor da proposta e status.”

O Claude:

1. Pergunta as credenciais do Supabase (URL e chave de API)

2. Cria o schema do banco com a tabela `proposals`

3. Adiciona as operações CRUD (criar, ler, atualizar, deletar)

4. Adiciona uma tela de histórico de propostas ao app

**Fase 5: Exportação para PDF**

Uma proposta em HTML não é o formato final — você precisa de um PDF para enviar por e-mail. O instrutor pede: “adicione um botão que exporta a proposta atual como PDF de alta qualidade.”

O Claude integra a biblioteca Puppeteer (que controla um Chrome headless para tirar um “screenshot” da página em PDF), gerando PDFs com o design idêntico ao HTML.

**Fase 6: Refinamentos finais**

Com as funcionalidades principais prontas:

- Adicionar campos de formulário para ajustar partes específicas da proposta antes de gerar

- Adicionar preview ao vivo enquanto preenche o formulário

- Adicionar suporte a múltiplos templates (proposta curta, proposta detalhada, proposta de emergência)

- Adicionar email de envio automático quando a proposta é aprovada internamente

Cada uma dessas funcionalidades é adicionada em uma mensagem separada, mantendo o contexto limpo.

**Resultado final**

O app completo em um único dia de desenvolvimento:

- Interface web responsiva com design profissional

- Pesquisa automática de informações sobre o prospect

- Geração de proposta personalizada em menos de 30 segundos

- Exportação para PDF com um clique

- Banco de dados com histórico de todas as propostas

- Sistema de templates para diferentes tipos de proposta

O investimento total em tokens foi de algumas dezenas de dólares. Comparado ao custo de contratar um desenvolvedor para construir o mesmo sistema (meses de trabalho, 10.000-50.000 dólares), o ROI é extraordinário.

**Lição principal**

O processo demonstra que o valor não está apenas no produto final, mas na velocidade com que você pode iterá-lo. Quando você pode testar uma ideia em 2 horas ao invés de 2 semanas, você se permite explorar muito mais possibilidades. A maioria das ideias de produto morre não porque são ruins, mas porque o custo de testar é alto demais. O Claude Code remove esse obstáculo.

## PARALELIZAÇÃO — O PRINCÍPIO FUNDAMENTAL 4:00:52

Um conceito que permeia todo o curso — de sub-agentes a agent teams a git worktrees — é a paralelização. O instrutor volta a ele várias vezes de diferentes ângulos porque entender quando e como paralelizar determina muito do valor que você extrai do Claude Code.

**O problema do trabalho serial**

Imagine que você tem três tarefas que precisam ser feitas: pesquisar o mercado, construir um protótipo e escrever o pitch. Feitas em série:

- Pesquisa: 10 minutos

- Protótipo: 15 minutos

- Pitch: 5 minutos

- Total: 30 minutos

Com paralelização, todas as três podem ser iniciadas simultaneamente:

- Tempo total: 15 minutos (o tempo da tarefa mais longa)

- Ganho: 50% menos tempo

Em tarefas maiores, o ganho é ainda maior. Para 10 tarefas independentes de 30 minutos cada (5 horas no total), a paralelização em 10 agentes reduz para 30 minutos.

**Quando paralelizar faz sentido**

A paralelização tem valor quando:

1. As tarefas são independentes (não dependem do resultado uma da outra)

2. Cada tarefa demora tempo suficiente para que o overhead de coordenação valha a pena

3. O custo adicional (mais tokens, mais agentes) é justificado pelo tempo economizado

Quando NÃO paralelizar:

1. Tarefas que dependem do resultado das anteriores (criar banco → popular banco → analisar dados: essas devem ser sequenciais)

2. Tarefas muito rápidas (spawnar um sub-agente para uma operação de 5 segundos pode ter mais overhead do que simplesmente fazê-la no agente principal)

3. Quando o orçamento de tokens é limitado e o speedup não é crítico

**Os três mecanismos de paralelização no Claude Code**

1. **Sub-agentes**: um agente pai cria filhos para tarefas específicas. Filhos têm contexto isolado, retornam resultado ao pai. Overhead baixo, bom para paralelização simples.

2. **Agent teams**: instâncias completamente independentes do Claude Code que compartilham uma área de comunicação. Mais overhead, mas mais flexibilidade — agentes podem se comunicar entre si e ter suporte completo de ferramentas. Melhor para trabalho complexo que requer colaboração.

3. **Git worktrees**: separação no nível do sistema de arquivos. Cada agente trabalha em sua própria branch/pasta. Elimina conflitos de arquivo mas requer merge ao final.

**A combinação mais poderosa**

O workflow que o instrutor considera mais eficaz combina os três:

- Git worktrees para isolar o trabalho no nível de branch

- Agent teams para coordenar múltiplos agentes em paralelo

- Sub-agentes dentro de cada team member para tarefas específicas

Esse setup permite que 3 agent team members trabalhem em 3 branches diferentes, cada um com 3 sub-agentes para pesquisa, implementação e QA, totalizando 9 processos em paralelo para construir 3 features simultaneamente.

**O custo da paralelização**

Toda essa paralelização tem um custo proporcional em tokens. 10 sub-agentes = ~10x mais tokens do que um único agente fazendo o mesmo trabalho sequencialmente. O tempo economizado vem a um custo monetário mais alto.

A equação que o instrutor usa: “se o tempo economizado tem valor financeiro maior do que o custo adicional em tokens, paralelize.”

Para um empreendedor cujo tempo vale 100 dólares por hora, economizar 5 horas de trabalho por 50 dólares em tokens extras é um excelente ROI. Para um estudante usando o Claude Code para aprender, talvez não faça sentido gastar mais em tokens quando tempo não é tão escasso.

## GESTÃO DE ERROS E DEBUGGING COM CLAUDE CODE 4:02:47

Uma das situações que todo usuário do Claude Code vai enfrentar é o agente encontrando erros durante a execução. Entender como o Claude lida com erros — e como você pode ajudar quando ele trava — é fundamental para projetos complexos.

**O comportamento padrão do Claude diante de erros**

Quando um script falha ou um comando retorna um erro, o comportamento padrão do Claude é tentar resolver automaticamente:

1. Lê o error message completo

2. Identifica a causa provável

3. Faz uma ou mais tentativas de correção

4. Se resolver, continua o processo normalmente

5. Se não resolver após algumas tentativas, para e reporta o problema

Esse loop de “tentar, falhar, corrigir” é muito mais eficiente do que o equivalente humano. O Claude é incansável: vai tentar 10 abordagens diferentes antes de desistir.

**O instrutor descrevendo o processo**

Em várias demonstrações, o instrutor mostra erros acontecendo em tempo real. Em nenhum momento ele intervém para ajudar a debugar. Ele simplesmente observa o Claude resolver. “É exatamente como seria com um funcionário júnior muito competente: você dá a tarefa, erros vão acontecer, e ele resolve sozinho.”

O exemplo do Google Sheets illustra isso perfeitamente: a API rejeitou o upload por caracteres inválidos nos nomes dos campos. O Claude leu o erro, consultou a documentação da API do Google Sheets, identificou a restrição de nomenclatura, reformatou os campos e fez o upload com sucesso.

**Quando o Claude fica preso**

Às vezes o Claude entra em um loop: tenta algo, falha, tenta uma variação, falha de forma diferente, volta para a primeira abordagem, falha novamente. Isso é perceptível porque você vê as mesmas tentativas se repetindo.

Sinais de que o Claude está preso:

- Mesmo erro aparecendo repetidamente nas tasks

- O agente tentando a mesma abordagem com pequenas variações

- Tasks que deveriam ter terminado há minutos ainda rodando

**Intervindo quando necessário**

Quando você percebe que o Claude está preso, intervenção humana é mais eficiente do que deixar rodar:

1. Pressione Ctrl+C para interromper a execução atual

2. Avalie o que está acontecendo: qual é o erro, qual abordagem o Claude está tentando

3. Se você souber a solução, descreva-a diretamente

4. Se não souber, dê ao Claude uma dica ou uma direção diferente: “Tente usar a biblioteca X em vez de Y” ou “O problema está na autenticação, não no formato dos dados”

Às vezes simplesmente dizer “você parece preso neste loop, tente uma abordagem completamente diferente” é suficiente para destravar.

**Logs e debugging**

Para problemas mais difíceis, peça ao Claude para adicionar logging detalhado antes de tentar novamente:

“Antes de tentar de novo, adicione logs detalhados em cada etapa para que possamos ver exatamente onde está falhando.”

Isso é muito mais eficiente do que tentar debugar no escuro. Com logs adequados, tanto você quanto o Claude conseguem identificar a causa raiz muito mais rapidamente.

**Debugging de skills**

Para skills que falharam em produção (quando você chama a skill por voz de comando ou pelo URL do Modal), o processo é:

1. Execute a skill manualmente no Claude Code com dados de teste

2. Observe onde falha

3. Peça ao Claude para “ler o skill.md e os scripts, identificar o problema e corrigir”

4. Reescreva no skill.md o que aprendeu para evitar a mesma falha no futuro

O Claude atualiza o skill.md automaticamente quando encontra um erro recorrente — mas só se você pedir explicitamente ou se houver uma instrução no claude.md para fazer isso.

## A FILOSOFIA POR TRÁS DO CLAUDE CODE — REFLEXÕES DO INSTRUTOR 4:05:38

Além dos aspectos técnicos, o instrutor distribui ao longo do curso reflexões mais filosóficas sobre o papel do Claude Code, o futuro do trabalho e a relação humano-IA.

**“O que é inteligência mesmo?”**

Uma passagem reveladora do curso acontece durante a demonstração dos agent teams, quando os agentes geram sites criativos inspirados em diferentes estilos. Alguém poderia argumentar que “IA não é criativa — só combina coisas existentes.”

O instrutor desafia essa visão: “O que é criatividade, se não combinar coisas existentes de maneiras novas? Todas as sentenças que você consideraria criativas são combinações de palavras que existiam antes. Algumas combinações específicas nunca foram feitas antes. O AI pode criar essas combinações — algumas delas são genuinamente novas e genuinamente interessantes.”

Essa observação não é apenas filosófica — tem implicações práticas para como você usa o Claude Code. Se você tratar a IA como um compilador que só pode combinar o que você explicitamente diz, vai subutilizá-la. Se você permitir que o agente faça conexões inesperadas, pode ser surpreendido positivamente.

**Sobre confiança no processo**

O instrutor frequentemente diz “vou confiar que está fazendo bem” quando o Claude está executando algo técnico que ele não entende completamente. Isso não é ingenuidade — é uma prática consciente de delegar.

A analogia é direta: quando você contrata um desenvolvedor experiente para construir algo, você não verifica cada linha de código que ele escreve. Você define critérios de sucesso claros, verifica os resultados, e confia no processo. A mesma postura é recomendada com o Claude Code.

Isso não significa que você não deve revisar o código em situações críticas. Significa que para a maioria das situações cotidianas, a verificação de resultado é suficiente — se funcionou, funcionou.

**Sobre o papel humano**

O instrutor não apresenta o Claude Code como um substituto para a inteligência humana, mas como um multiplicador. A metáfora que usa é de uma fórmula 1: o carro é extraordinariamente capaz, mas sem um piloto habilidoso ele não vai a lugar nenhum. O Claude Code é o carro de Fórmula 1. Você é o piloto.

O que determina o valor que você extrai do Claude Code é a qualidade das suas instruções, a clareza das suas visões de produto, a habilidade de avaliar resultados e dar feedback eficaz. Essas são capacidades humanas que o Claude Code não substitui — ao contrário, valoriza ainda mais.

**Sobre o futuro próximo**

O instrutor é cuidadoso em não fazer previsões audaciosas, mas observa que a velocidade de melhora da IA é extraordinária. Funcionalidades que considera “experimentais” quando grava o curso (agent teams, extended thinking, fast mode) provavelmente serão mainstream e muito mais refinadas em poucos meses.

Sua recomendação: aprenda os fundamentos (bom prompting, estrutura de skills, gerenciamento de contexto) porque esses princípios vão continuar sendo válidos independentemente das mudanças específicas da ferramenta. A mecânica vai evoluir; os princípios subjacentes são mais estáveis.

**“Por que a Anthropic está reduzindo custos?”**

Um momento interessante do curso é quando o instrutor observa que a Anthropic implementou auto-compaction — um sistema que reduz o uso de tokens de forma automática, efetivamente reduzindo a receita deles. Ele interpreta isso como um sinal de que a empresa está genuinamente comprometida com a qualidade do produto em vez de apenas maximizar receita.

“Isso vai contra os interesses financeiros deles de curto prazo. Para mim é um sinal de que esse é um time que valoriza a qualidade da experiência do usuário acima de tudo. E isso me faz confiar mais no produto.”

Esta reflexão ressoa com a audiência do curso, que está decidindo se vai investir tempo aprendendo essa ferramenta. Uma empresa que constrói com esse mindset provavelmente vai continuar inovando no interesse dos usuários.

## RECURSOS ADICIONAIS E PRÓXIMOS PASSOS 4:08:20

Para continuar aprendendo além do que foi coberto neste curso, o instrutor aponta alguns recursos e direções para aprofundamento.

**Documentação oficial**

O site de documentação da Anthropic para o Claude Code é atualizado constantemente e contém as informações mais atualizadas sobre:

- Novas funcionalidades conforme são lançadas

- Estratégias de otimização de tokens (a seção de “reducing token usage” é especialmente útil)

- Guia de MCPs disponíveis

- Exemplos de configurações avançadas

O instrutor menciona que o conteúdo desta documentação evolui tão rapidamente que o que você vê nele pode ser diferente do que estava disponível na data de gravação do curso.

**Twitter/X para novidades em tempo real**

Para acompanhar as últimas estratégias, prompts e dicas que a comunidade está descobrindo, o X (Twitter) é a fonte mais atual. Uma dica específica do instrutor: quando quiser saber as melhores práticas mais recentes, pergunte ao Grok:

“Resuma as melhores estratégias para reduzir uso de tokens no Claude Code que usuários estão discutindo no último mês.”

Essa abordagem de usar IA para sumarizar o que a comunidade está descobrindo é muito mais eficiente do que ler todos os tweets um a um.

**O canal do instrutor no YouTube**

Nick Sarayev (o instrutor) tem um canal no YouTube com conteúdo complementar sobre:

- Agentic workflows (workflows agênticos) em detalhes

- Como monetizar habilidades de automação

- Casos de uso específicos de negócio

- Demos de projetos avançados

O curso menciona que existe um conteúdo separado sobre workflows agênticos que vai mais fundo do que foi possível cobrir neste curso de 4 horas.

**Maker School**

Para quem quer não apenas aprender a usar o Claude Code mas também construir um negócio com base nessas habilidades, o Maker School é o programa de 90 dias do instrutor. Foco em conseguir o primeiro cliente em consultoria de automação e IA.

**Prática deliberada**

A recomendação mais importante do instrutor para quem acabou de assistir o curso: não espere ter o projeto perfeito para começar. Pegue qualquer tarefa repetitiva que você faz hoje — uma pesquisa que faz regularmente, um relatório que formata, um processo de comunicação que repete — e transforme em uma skill.

Essa prática imediata de aplicação é o que converte conhecimento teórico em competência real. O curso deu os fundamentos. O que vai determinar o seu resultado é quantas vezes você vai sentar na frente do terminal e construir coisas reais com as ferramentas que aprendeu.