Essa semana tive a oportunidade de construir um protótipo navegável completo de um sistema SaaS usando Claude Code com uma abordagem que quero compartilhar: subagentes especializados. O sistema em questão era uma plataforma com múltiplos perfis de usuário, dashboards personalizados, marketplace de serviços e pagamentos integrados. Não posso entrar nos detalhes da regra de negócio por questões de confidencialidade do cliente, mas posso compartilhar como foi o processo e principalmente os aprendizados que tive.
Para contextualizar: não estamos falando de um sistema funcional com backend real, mas sim de um protótipo navegável de alta fidelidade com dados mockados estruturados em JSONs. Mesmo sendo mock, a qualidade e estruturação do código permitiram validar toda a UX e fluxos do sistema de forma realista. E o melhor: tudo isso saiu em exatas 3 horas de vibe coding.
O Setup Vencedor: 4 Subagentes + PRD
A sacada principal que fez toda a diferença foi estruturar o desenvolvimento simulando uma equipe de produto real. Antes de escrever qualquer linha de código, pedi ao Claude que criasse quatro agentes especializados:
- Gerente de Projetos: Responsável por quebrar requisitos em tasks acionáveis e manter a visão de negócio
- Tech Lead: Define padrões técnicos, arquitetura e valida viabilidade das soluções
- Developer: Implementa as features seguindo os padrões estabelecidos
- QA: Valida se as implementações atendem os critérios de aceite
Junto com os agentes, pedi a criação de um PRD completo a partir de um input inicial com o escopo do sistema. O Claude gerou um documento estruturado com todos os módulos, requisitos funcionais e não-funcionais, jornadas de usuário e até métricas de sucesso.
O mais importante: customizei cada agente para seguir o boilerplate que eu já tinha pronto. Isso garantiu que todas as implementações seguissem os padrões do projeto desde o início.
O Workflow que Funcionou
Com os agentes criados, parti para um planejamento incremental:
- Planejamento de Tasks: Pedi ao agente de PM para decompor o PRD em tasks específicas, com critérios de aceite claros
- Desenvolvimento Iterativo: Para cada task, solicitei a implementação seguindo os padrões do Tech Lead
- Validação Contínua: Após cada implementação, validei o resultado e pedi correções quando necessário
- Commits Automatizados: Até os commits foram feitos pelo Claude Code, seguindo convenções de mensagem
Fiz vibe coding do início ao fim. O Claude Code foi responsável por escrever código, criar componentes, estruturar os dados mockados em JSONs, fazer commits e até resolver conflitos. Meu papel foi principalmente de revisor e direcionador, validando se as implementações estavam no caminho certo.
O resultado em 3 horas foi um protótipo navegável de alta fidelidade com:
- Sistema de autenticação multi-perfil mockado
- Dashboards personalizados com dados estruturados em JSON
- Marketplace funcional com listagem e filtros
- Fluxos de agendamento e contratação navegáveis
- Interface responsiva e consistente
- Transições e estados que simulam um sistema real
Os Erros que Custaram Tokens
Agora vem a parte importante: os erros que cometi e que me custaram tempo e tokens desnecessários.
1. Dark Mode com Cores Hardcoded
O primeiro erro foi não especificar desde o início como o dark mode deveria ser implementado. Como não deixei explícito que deveria usar variáveis CSS, o Claude criou todos os estilos com cores fixas nos componentes. Quando percebi e pedi para refatorar usando CSS variables, tive que gastar uma quantidade significativa de tokens para corrigir algo que poderia ter sido feito certo desde o início.
A lição aqui: guardrails técnicos precisam ser especificados antes, não depois. Se você tem uma preferência sobre como algo deve ser implementado, coloque isso nos prompts dos agentes ou no início do desenvolvimento. É muito mais barato prevenir do que corrigir.
2. Componentes Sem Reutilização
O segundo erro foi similar: não pedi explicitamente que o Claude reutilizasse componentes sempre que possível. Resultado? Vários componentes duplicados com pequenas variações que poderiam ser um único componente parametrizado.
Quando pedi a refatoração para consolidar componentes, novamente gastei tokens que poderiam ter sido economizados se eu tivesse estabelecido essa diretriz no Tech Lead desde o começo.
As Regras de Ouro que Aprendi
Depois dessa experiência, cheguei em algumas regras práticas para quem quiser usar subagentes com Claude Code:
-
Defina todos os guardrails técnicos ANTES: Padrões de estilo, convenções de código, preferências de implementação. Tudo isso deve estar nos prompts dos agentes antes de começar a implementação.
-
Seja específico sobre reutilização: Se você quer que componentes sejam reutilizáveis, diga isso explicitamente. Se quer evitar duplicação de código, deixe claro. O Claude é ótimo em seguir diretrizes, mas precisa que elas existam.
-
Customize os agentes para seu contexto: Não use agentes genéricos. Adapte cada um para o boilerplate, stack e padrões do seu projeto.
-
Valide incrementalmente: Não deixe o Claude implementar 10 features para só depois revisar. Valide task por task, isso evita propagação de erros.
-
Documente as decisões técnicas: Quando tomar uma decisão sobre como algo deve ser implementado, documente nos prompts dos agentes. Isso garante consistência ao longo do projeto.
Vale a Pena?
Absolutamente. Mesmo com os erros que cometi, a produtividade foi absurdamente maior do que seria em desenvolvimento tradicional. Um protótipo navegável de alta fidelidade que levaria semanas para ser construído manualmente ficou pronto em 3 horas, e com qualidade superior ao que eu conseguiria sozinho no mesmo tempo.
É importante reforçar: estamos falando de um protótipo mockado, não de um sistema funcional com backend. Mas a estruturação foi tão bem feita que a transição para implementação real seria direta. Os JSONs seguem a estrutura de dados real, os componentes estão prontos para consumir APIs, e os fluxos refletem exatamente como o sistema final deve funcionar.
O segredo não é deixar o Claude Code fazer tudo sozinho, mas sim estruturar o trabalho de forma que ele possa operar com autonomia dentro de guardrails bem definidos. É como ter uma equipe de desenvolvedores que executa perfeitamente o que você especifica, mas que precisa de especificações claras.
Os subagentes foram fundamentais nessa dinâmica. Eles criaram uma estrutura mental que manteve o desenvolvimento organizado e consistente. O PM garantiu que tudo estava alinhado com o negócio, o Tech Lead manteve a qualidade técnica, o Dev executou com eficiência e o QA validou as entregas.
Se você já usa LLMs para desenvolvimento mas ainda não experimentou trabalhar com subagentes especializados, eu recomendo fortemente. A diferença é tangível, especialmente em projetos maiores onde a consistência e organização fazem toda a diferença. E mesmo para protótipos mockados, a velocidade e qualidade que você consegue são impressionantes.
E lembre-se: especifique seus guardrails ANTES de começar. Seu eu do futuro vai agradecer.