O problema
Somos uma equipe pequena. Cinco pessoas construindo uma plataforma de IA. Em qualquer momento, temos 14 repositórios ativos. Isso significa muitos PRs e não humanos suficientes para revisá-los bem.
As revisões estavam demorando demais. Coisas importantes estavam sendo ignoradas. Estávamos entregando código mais rápido do que conseguíamos verificar.
Então construímos nosso próprio bot de revisão de código. Começou como um projeto paralelo para resolver um problema interno. Agora é um produto: Surmado Code Review. US$15 por mês por 100 PRs.
Aqui está como realmente construímos. O que foi vibe-coded, o que não foi, e o framework que recomendamos para quem está prototipando qualquer pipeline de IA.
Fase 1: Início com vibe coding
A primeira versão era um agente de resumo. Só isso. Você abria um PR e recebia um resumo em linguagem natural das mudanças. Fizemos tudo com vibe coding. Rápido, direto, com o Claude fazendo a maior parte do trabalho.
Depois começamos a perguntar: será que ele também consegue detectar bugs?
Foi aí que ficou interessante.
Fase 2: O forward-backward pass
Essa é a parte que achamos que realmente vale compartilhar. É um framework que você pode usar em qualquer pipeline de IA, não só revisão de código.
Pegamos um conceito do treinamento em ML: o forward-backward pass. Mas, em vez de treinar os pesos de um modelo, tratamos todo o pipeline como se fosse um LLM.
Funciona assim.
Forward pass. Você define um conjunto de inputs controlados. No nosso caso, PRs com bugs que inserimos deliberadamente. Rodamos isso no pipeline e registramos o que ele detecta e o que ele deixa passar.
Backward pass. Olhamos para o que passou despercebido. Ajustamos prompts, estrutura e lógica de revisão. Depois rodamos de novo. Agora ele detecta o bug? Gerou mais falsos positivos?
Repetir. Cada ciclo é rápido e barato. Você não está retreinando um modelo. Está iterando sobre código, prompts e arquitetura com sinal imediato de se funcionou.
O insight principal: você transforma o Claude Code em um usuário sintético. Dá um input esperado e um output esperado. Deixa ele gerar novos casos de teste e avaliar os resultados contra o seu pipeline. Isso vira seu test harness.
Test harnesses são fáceis de montar com vibe coding. Se você tem uma API ativa, dá para montar em uma tarde. Algo deployado, em container ou rodando localmente basta. Você define os tipos de bugs que quer que o pipeline detecte, gera casos, executa e itera.
Isso foi nosso v1 e v2. Tínhamos 10 teorias diferentes sobre como estruturar a lógica de revisão. Em vez de debater, passávamos todas pelo harness e deixávamos os resultados decidirem.
Fase 3: Onde o vibe coding encontra o limite
Depois de toda essa experimentação, encontramos o ponto-chave: o grounding em padrões.
O agente de revisão melhorou muito quando passou a ter um documento de padrões bem escrito para consultar. As convenções reais de código da equipe, nossas decisões de arquitetura.
Se você usa vibe coding, provavelmente já tem um CLAUDE.md ou .cursorrules. Isso é um contrato de escrita. Ele diz ao agente o que produzir. Mas a maioria dos times não tem um contrato de revisão. Não existe um arquivo equivalente dizendo, para humano ou máquina, o que é aceitável para dar merge. É aí que nasce o drift.
Escrevemos um STANDARDS.md para cada repositório. A partir daí, o agente tinha algo concreto para comparar. Não boas práticas genéricas. Nossas opiniões específicas sobre como construímos.
Mas tem uma coisa importante. Esse documento de padrões em si não dava para vibe-code. O formato, como ele entra no pipeline, a linguagem e a estrutura específicas. Tudo isso exigiu julgamento humano. Escrevemos, testamos como o agente interpretava, e revisamos. Esse loop foi conduzido por humanos.
A produtização foi totalmente manual. Cada parte dela.
Autenticação e pagamentos. Feitos de forma deliberada. Protegemos o dinheiro do cliente.
Estados de erro e reembolsos. Definidos manualmente. Quando algo dá errado, precisamos saber exatamente o que acontece e por quê.
Privacidade. Inegociável. O código do cliente passa pelo nosso pipeline. Isso exige arquitetura deliberada, não código gerado.
Integração com o Scout. O Scout é nosso analista de pesquisa com IA. A ligação entre Surmado Code Review e Scout foi cuidadosa, testada e intencional.
Também dedicamos muito tempo ao peso dos modelos no pipeline. Ser deliberados sobre qual modelo faz o quê, equilibrando custo e qualidade. Esse tipo de decisão não se delega. Exige entender margens, expectativa do cliente e failure modes de cada nível de modelo.
Nada disso foi deixado para a máquina.
Fase 4: Revisão humana e polimento
Depois que o protótipo com vibe coding e o loop de testes agentic nos deram uma base sólida, veio muito trabalho humano de revisão. Ler outputs. Comparar com o que um engenheiro sênior realmente sinalizaria. Ajustar o documento de padrões. Matar falsos positivos.
Usamos internamente nos 14 repositórios. Quando lançamos a v7, já tinha passado por milhares de PRs reais em código que nos importava.
Resultado: 3× mais rápido para dar merge nesses repos. PRs pararam de acumular. Engenheiros sêniores pararam de caçar as mesmas cinco coisas em cada revisão. Juniors pararam de adivinhar convenções. PRs gerados por agentes pararam de sair do padrão do time.
No fim, o time me obrigou a lançar. Estavam cansados de dizer para amigos fundadores que não, eles não podiam ter, que era interno. Então transformamos em produto.
O framework (pode usar)
Se você está construindo qualquer pipeline de IA, de revisão de código ou não, este é o padrão.
1. Prototipe com vibe coding. Faça o fluxo básico funcionar. Não pense demais na arquitetura. Deixe a IA montar o andaime.
2. Construa um test harness agentic. Defina seus inputs e outputs esperados. Deixe o Claude Code atuar como usuário sintético. Esse é o forward-backward pass. É rápido de montar se você tem uma API para chamar, e te permite testar 10 ideias no tempo que levaria para avaliar uma manualmente.
3. Deixe os dados decidirem os vencedores. Não debata qual abordagem é melhor. Passe todas pelo harness. O sinal é imediato.
4. Encontre o mecanismo de grounding. Para nós foi um documento de padrões. Para você pode ser um style guide, uma rubrica, um conjunto de regras ou um dataset de referência. A coisa que torna seu pipeline consistente e com opinião. Esse é o verdadeiro diferencial, e quase certamente exige trabalho humano.
5. Construa manualmente o que protege o cliente. Auth, pagamentos, privacidade, estados de erro. Isso não é território de vibe coding. É o que conquista confiança. Faça de forma deliberada.
A conclusão honesta
Vibe coding é um framework excelente para prototipar e experimentar. O loop de teste agentic, o padrão forward-backward, nos permitiu nos movermos muito mais rápido no desenvolvimento inicial do que jamais teríamos conseguido. Saímos de “e se construíssemos um bot de revisão de código” para um protótipo funcionando pegando bugs reais em questão de dias.
Mas o que torna um produto confiável exigiu humanos tomando decisões deliberadas com contexto completo. O grounding em padrões. A escolha dos modelos. Os fluxos de pagamento. A arquitetura de privacidade.
Prototipe e experimente com vibe coding. Construa manualmente o que protege o cliente. Essa é a linha. Achamos que é a certa.
Teste nos seus próprios repositórios
Surmado Code Review. US$15/mês por 100 PRs. Construído por uma equipe de cinco pessoas. Rodado internamente em 14 repositórios.
Veja como o Surmado Code Review funciona ou inicie uma revisão no seu próximo PR.
Leituras relacionadas: