Regras de Vibe Coding: Crie Projetos Paralelos pelo Celular Usando Claude Code Sem Ler Código

Um engenheiro de software experiente, com uma década de experiência, publicou um fluxo de trabalho detalhado para o que chama de "vibe coding" — construir projetos paralelos usando Claude Code inteiramente pelo celular, sem nunca ler o código gerado. O post descreve um processo estruturado que prioriza planejamento e verificações de segurança para tornar essa abordagem prática.

Fluxo de Trabalho Principal

• Comece no modo plano. Leia o plano, entenda o máximo possível. Se não estiver claro, pergunte. O autor usa o comando 4. Tell Claude what to change repetidamente para fazer perguntas como "O que é
  sobre? O que isso significa?"
• Vá e volte com o agente. O modo plano é a fase mais importante — decisões boas e ruins se multiplicam.
• Divida os planos em pequenos pedaços. Se o plano for grande demais para compreender, peça ao agente para dividi-lo em partes menores e processá-las uma de cada vez.
• Faça commit de tudo no git após cada plano completo. O autor sugere criar uma skill ou memória que faça auto-commit. Isso permite reverter se algo quebrar. Nota: backups de banco de dados são separados.
• Gere casos de teste visíveis no plano. Você não precisa ler o código de teste, mas uma lista como it checks two positive integers, it checks passing a negative value, it checks not passing any value dá confiança e previne regressões.

Segurança Avançada: Três Subagentes

Para mudanças complexas, crie três subagentes para:

• revisar criticamente o plano
• fazer uma revisão de segurança
• realizar uma auditoria de testes

Cuidado com o Banco de Dados

O autor aconselha sempre fazer um backup do banco de dados (ou ter backups agendados) antes de deixar o agente tocar em dados de produção. Rollbacks previnem desastres como exclusão acidental.

Modo Automático

Assim que o trabalho inicial (planejamento, git, testes, revisões) estiver pronto, o autor ativa o modo automático e deixa o agente rodar. Ele também dá ao agente acesso ao Chrome DevTools MCP (ou similar) para testes ponta a ponta após a implantação.

O resultado: "Você pode construir algo que ninguém usa."