Como o Claude Code construiu este blog pra mim
TL;DR: O Claude Code tem um sistema de subagentes que rodam em paralelo com contextos isolados. Para construir este blog em Next.js 15, três agentes trabalharam ao mesmo tempo: um cuidou da camada de dados, outro dos componentes React e um terceiro das rotas dinâmicas do App Router. O resultado foi um projeto inteiro entregue em uma única sessão. Este post explica como funcionou na prática e o que isso muda para quem constrói sozinho.
Antes de falar de sentimentos, vamos falar de arquitetura.
Este blog existe por causa de um único comando. Eu descrevi o que queria, o Claude Code montou um plano, disparou três agentes em paralelo e entregou um projeto Next.js 15 funcional, com TypeScript, Tailwind, App Router e posts em Markdown, sem que eu precisasse alternar entre camadas ou esperar uma terminar para começar a outra.
Isso não é magia. É uma mudança de modelo de execução.
O que é o sistema de subagentes do Claude Code?
O Claude Code pode instanciar subagentes especializados que rodam em paralelo, cada um com seu próprio contexto isolado, suas próprias ferramentas e seu próprio escopo de atuação. O agente orquestrador coordena tudo: decide o que delegar, para quem e quando.
A documentação oficial de subagentes descreve assim: cada subagente roda com uma janela de contexto própria, e apenas o resultado final retorna ao orquestrador. Os passos intermediários, arquivos lidos, raciocínio interno, ficam dentro do contexto do subagente e não poluem a conversa principal.
Três características tornam isso útil de verdade:
- Paralelismo real: tarefas independentes rodam ao mesmo tempo, não em fila.
- Especialização: cada subagente recebe um prompt focado no seu domínio, sem ruído do restante do projeto.
- Coordenação por resultado: o orquestrador só avança quando os subagentes reportam conclusão, e pode usar o output de um como input de outro.
Como o multi-agent funcionou na construção deste blog?
O blog usa Next.js 15 com App Router, TypeScript e Tailwind. Posts em Markdown puro, sem CMS. Estrutura simples, mas com decisões técnicas que precisavam ser tomadas em camadas: modelo de dados, rotas dinâmicas, componentes de layout, leitura de arquivos, geração de URLs.
Em vez de iterar sequencialmente, o Claude Code dividiu o trabalho em domínios e os executou em paralelo:
Agente 1 — camada de dados: a interface Post, as funções getPostBySlug e getAllPosts, e a lógica de leitura recursiva de arquivos em _posts/. Tudo em TypeScript, com tipos bem definidos.
Agente 2 — componentes React: PostHeader, PostBody, CoverImage, DateFormatter e a estrutura de layout responsiva com Tailwind. Construídos em cima do contrato de dados que o orquestrador passou antes de disparar os agentes.
Agente 3 — rotas dinâmicas: [slug]/page.tsx com generateStaticParams e generateMetadata para SEO. Toda a lógica do App Router, configurada para geração estática no build.
Os três rodaram simultaneamente. Enquanto o Agente 1 construía a API de posts, o Agente 2 já estruturava os componentes com os tipos corretos, porque o orquestrador tinha passado o contrato de dados para ambos antes de iniciar a execução. Nenhum esperou o outro.
O resultado: o que seria uma sequência de sessões se tornou uma única sessão com múltiplas frentes abertas ao mesmo tempo.
Por que contexto isolado importa para um projeto real?
Um problema comum em sessões longas com IA é o esgotamento do contexto. Conforme a conversa cresce, o modelo começa a perder fio de raciocínio, mistura responsabilidades e produz código inconsistente.
Com subagentes, esse problema muda de forma. Segundo a documentação de subagentes do Claude Code, operações de alto volume ficam contidas no contexto do subagente. O orquestrador recebe apenas um resumo conciso, não cada arquivo lido, cada decisão tomada. Isso libera a janela de contexto principal para o que importa: coordenação e resultado.
Na prática, para este blog, significou que o agente de componentes não precisou carregar no contexto dele toda a lógica de leitura de arquivos. E o agente de rotas não precisou rastrear cada tipo TypeScript definido na camada de dados. Cada um tinha o que precisava, nada mais.
O que isso muda para um builder solo?
A implicação prática não é "a IA faz tudo por você". É outra: o gargalo muda de lugar.
Em desenvolvimento tradicional, um dev solo serializa tudo. Você termina o modelo de dados, então começa os componentes, então ajusta as rotas. O tempo de projeto é a soma das partes.
Com multi-agent, você passa a pensar em termos de domínios independentes e dependências reais. O que pode rodar em paralelo? O que precisa esperar o quê? Essas perguntas sempre existiram em times de engenharia. Agora elas têm retorno direto para uma pessoa só.
A pesquisa de autonomia da Anthropic mostra que o 99,9° percentil de duração de execução de sessões do Claude Code quase dobrou entre outubro de 2025 e janeiro de 2026, passando de menos de 25 minutos para mais de 45 minutos. O agente ficou mais capaz de sustentar trabalho longo sem intervenção humana. Para um builder solo, isso significa projetos mais complexos resolvidos sem supervisão constante.
O trabalho de quem constrói muda: você define o contrato entre as partes e deixa a execução paralela acontecer. Isso exige clareza sobre arquitetura antes de apertar Enter, não depois.
O que o orquestrador precisa receber para funcionar bem?
Aqui está a parte contraintuitiva: o trabalho mais importante não é o que o agente faz. É o que você define antes.
O orquestrador só consegue coordenar bem quando recebe um contrato claro. Para este blog, esse contrato era simples: estrutura de diretórios esperada, o shape do objeto Post, quais rotas existiriam, como os slugs seriam gerados. Não precisei escrever código. Precisei descrever o acordo entre as partes.
Sem isso, os três agentes poderiam ter produzido três sistemas coerentes internamente mas incompatíveis entre si. O componente PostBody esperando uma prop que a função getPostBySlug não retorna. A rota dinâmica tentando gerar um parâmetro que a lógica de listagem de posts não expõe.
O contrato de dados veio primeiro. A execução paralela veio depois.
Como o blog continua sendo mantido
Este blog não foi construído uma vez e largado. Ele continua sendo mantido com agentes especializados: um para escrever posts, outro para ajustar componentes, outro para gerenciar o repositório.
Isso vale também para o conteúdo que você está lendo agora. Os posts deste blog não são escritos manualmente por mim. Existe um agente escritor que pesquisa o tema, estrutura o post com foco em SEO e escreve o texto completo. Antes de publicar, um agente revisor passa pelo texto nas três dimensões: editorial, SEO e técnico. Eu orquestro esse processo, defino o tema e o ângulo, aprovo o esboço e reviso o resultado final. Mas a escrita em si é delegada.
A aposta em agentes, portanto, não para no código. Ela cobre a operação inteira do blog.
Em março de 2026, a Anthropic lançou o auto mode para o Claude Code: um classificador que avalia cada ação antes de executar e aprova automaticamente as operações seguras, sem pedir confirmação do desenvolvedor. Para manutenção contínua, isso significa sessões que correm sem interrupção para aprovações triviais.
A pesquisa da Anthropic aponta que usuários com mais de 750 sessões já usam aprovação automática em mais de 40% dos casos. A confiança no agente cresce com o uso, e as ferramentas estão acompanhando isso.
Se você quiser ver como isso evoluiu além de construir um blog e chegou a entregar features de produto completas enquanto eu dormia, o próximo post cobre exatamente isso.
Para quem constrói produtos com IA e quer acompanhar como esses padrões evoluem na prática, incluindo os erros e as limitações que aparecem ao longo do caminho, a comunidade AI Builders BR é o melhor lugar para isso.
Perguntas Frequentes
O que é o sistema de subagentes do Claude Code e como ele funciona tecnicamente?
Subagentes são instâncias do Claude que rodam em paralelo, cada uma com sua própria janela de contexto, ferramentas e permissões. O agente orquestrador os dispara com a ferramenta Agent, passando o contexto necessário para cada um. Apenas o resultado final retorna ao orquestrador, não os passos intermediários. Isso preserva o contexto principal e permite paralelismo real em tarefas independentes.
Por que usar Next.js 15 com App Router para um blog em Markdown sem CMS?
O App Router do Next.js 15 permite geração estática com generateStaticParams, o que significa que cada post vira uma página HTML no build. Sem servidor, sem banco de dados, sem CMS para manter. O guia de build de blog com Next.js 15 explica bem os benefícios de performance e SEO dessa abordagem. Para um blog pessoal técnico, a simplicidade operacional vale mais do que a flexibilidade de um CMS.
Quanto controle você tem sobre o que o agente faz durante a execução? Controle total antes de começar, menos durante. Você define o contrato de dados, a estrutura de diretórios, as convenções de código. O agente executa dentro desse contrato. Com o auto mode da Anthropic, operações seguras são aprovadas automaticamente por um classificador. Operações arriscadas param e pedem confirmação. A revisão de comportamento ao final continua sendo necessária.
Isso funciona para projetos além de um blog simples? Sim. A pesquisa da Anthropic sobre construção de um compilador C em paralelo mostra múltiplas instâncias do Claude trabalhando em um projeto de 100 mil linhas. A escala muda, o princípio não: tarefas independentes rodam em paralelo, o orquestrador coordena por resultado. O gargalo passa a ser a clareza do problema descrito, não a capacidade de execução do agente.
O que um desenvolvedor solo ganha com esse modelo que não tinha antes? Capacidade de paralelização que antes era exclusiva de times. Em desenvolvimento tradicional, uma pessoa serializa tudo por necessidade. Com multi-agent, você pode abrir múltiplas frentes ao mesmo tempo, desde que o problema esteja bem dividido. O Bloomberg reportou que Claude Code se tornou a ferramenta de coding com IA mais usada em 2026 exatamente por esse motivo: ela muda o que é possível fazer sozinho.