Sincron Auto V2: como fazer o Claude Code desenvolver sozinho

Quando o “oi” custa 60 mil tokens no Claude Code, o problema não é o modelo. É o fluxo. No Sincron Auto V2, esse mesmo “oi” passou a custar 6 mil tokens porque o sistema parou de desperdiçar chamadas e começou a controlar o que realmente precisa ser executado.

O custo escondido da V1 e a lógica do “one shot, one kill”

Na V1 do Sincron Auto, o objetivo era simples: colocar o agente para desenvolver projeto de ponta a ponta. Mas, na prática, surgia um custo escondido que não aparecia como “erro”, só como consumo: verificadores baratos que, em certos cenários, viravam novas chamadas de modelo. Ou seja, uma etapa que deveria ser determinística (ou quase) acabava acionando o LLM como se fosse parte do core do desenvolvimento.

Na V2, a meta ficou explícita: one shot, one kill. A ideia é captar tudo no início (requisitos, arquitetura, skills disponíveis, padrões e critérios de aceite) e reduzir retrabalho durante a execução. A consequência é direta: menos idas e vindas, menos “tentativas” desperdiçadas e mais entregas com relatório.

O ganho de eficiência não é teórico. O devlog citado no vídeo mostra uma redução drástica no custo de uma etapa inicial: o mesmo “oi” que consumia 60 mil tokens passou a consumir 6 mil tokens na V2. Em sistemas que executam milhares de passos (o time comenta que já rodaram 63 projetos, com 24 skills e 30 agentes e milhares de user stories), pequenas diferenças por etapa viram economia real.

Escalonamento de modelo: tenta baixo, sobe quando precisa

Um dos pontos mais práticos do Sincron Auto V2 é o escalonamento de modelo. Em vez de começar sempre no nível mais caro (por padrão, o melhor modelo disponível), o sistema tenta primeiro com um patamar mais baixo e só “escala” quando há sinais de falha.

O vídeo descreve esse comportamento como: mesma tentativa com feedback e, se necessário, sobe o nível. Isso resolve dois problemas comuns em automação com LLM:

• Overkill: chamar o modelo mais forte para tarefas que já podem ser resolvidas com boa qualidade em um nível inferior.
• Repetição cega: insistir no mesmo raciocínio sem incorporar feedback do que falhou (ou por que falhou).

Outro detalhe importante: não usar Fable e não fixar versão do modelo. O vídeo coloca que Opus é o teto. Na prática, isso significa que o sistema tem margem para operar com mudanças de oferta e qualidade do provedor, mantendo um limite superior claro de custo/qualidade. Em B2B, essa flexibilidade tende a ser mais sustentável do que amarrar o fluxo a uma versão específica que pode mudar ou encarecer.

Fase A: perguntas iniciais, catálogo de skills e aprovação humana

A V2 não começa escrevendo código. Ela começa organizando o terreno. A primeira etapa (Fase A) é um conjunto de perguntas iniciais para extrair o necessário para executar com precisão e reduzir improviso durante o desenvolvimento.

O fluxo inclui:

• Catalogar as skills da sua máquina (o que o ambiente realmente consegue fazer: ferramentas, integrações, capacidade de build, testes, rotas de execução).
• Aprovação humana antes de avançar para a construção detalhada.

Esse ponto é particularmente relevante para empresas que tentam “vibe coding” sem governança. Sem validação humana no começo, você acaba gastando tokens e tempo tentando corrigir suposições erradas no meio do caminho. Com aprovação humana na Fase A, a esteira segue com menos ambiguidades e mais previsibilidade.

O vídeo também menciona o uso do Excalidraw para abrir e mostrar o fluxo completo. Isso não é estética: é uma forma de tornar o pipeline auditável. Em automação para desenvolvimento, auditabilidade é tão importante quanto performance.

História por história com verificações reais (sem depender só do “achismo”)

Depois da Fase A, a V2 entra na construção incremental. A lógica é história por história, com uma abordagem que tenta detectar quando uma história está “suspeita”. Em vez de aceitar qualquer implementação gerada pelo modelo, o sistema impõe verificações que funcionam como guardrails técnicos.

O vídeo dá exemplos concretos do que conta como validação:

• Type check
• Linter
• Testes
• Build

Essa parte muda o jogo porque reduz o tipo de erro que LLMs fazem bem: escrever algo plausível que não compila, não passa testes ou viola padrões. Ao exigir validações reais sem IA para as etapas determinísticas, o sistema transforma o desenvolvimento em um ciclo de engenharia, não apenas em geração de texto.

Além disso, o vídeo descreve o comportamento de tentativa com 3 tentativas no avaliador. Se a história não passa nos critérios, o fluxo não “engole” o resultado. Ele reavalia, ajusta e só então segue.

A esteira final: avaliador, gestor, design, segurança e pentest

Uma automação que entrega código sem um pós-processo de qualidade vira dívida técnica. No Sincron Auto V2, existe uma esteira final que contempla múltiplas camadas antes da entrega: design, segurança e pentest.

O vídeo cita a presença de:

• Avaliador com 3 tentativas
• Gestor para coordenar o fluxo e garantir que o objetivo (entrega com relatório) seja atingido
• Design como etapa explícita, não como consequência acidental do código
• Segurança e pentest antes de considerar o trabalho pronto

Para times B2B, isso é um diferencial porque muda a conversa de “o agente funciona” para “o agente atende critérios de entrega”. Quando você tem projetos reais (como os 63 citados no devlog), a capacidade de incorporar segurança e validações reduz o risco operacional de usar IA como parte do processo de desenvolvimento.

Se você quer ver o fluxo completo no Excalidraw e entender como cada etapa conversa com a anterior (incluindo onde a V1 gerava custo escondido), assista ao vídeo para mais detalhes.

---

Sua empresa pode ir mais longe com inteligência artificial.
Na Sincron IA, criamos soluções sob medida em automação e IA para empresas que querem liderar seus mercados.
Vamos conversar → sincronia.digital