Workflow de desenvolvimento com IA: spec, agentes, loops e revisão com dois modelos

Abri hoje, 13 de setembro de 2026, o histórico de um ERP¹ pra pequeno lojista que venho construindo sozinho na Waxi desde outubro de 2023. Entre abril e junho de 2026 o repositório recebeu 385 commits², 69% de tudo que existe em quase três anos, 247 deles assinados em co-autoria com o Claude. No mesmo período, 99 mudanças de especificação foram propostas, implementadas e arquivadas, e a suíte de testes foi de 1.684 pra 3.192 casos entre 3 de maio e 15 de junho. Neste fim de semana, num segundo projeto, uma POC³ de monitoramento de marketplaces em Python, foram 115 commits em 48 horas, 111 com co-autoria de IA.

Ou seja: o modelo que escreve esse código é o mesmo que qualquer pessoa aluga por assinatura. O que separa isso de vibe coding é o processo em volta do modelo: spec antes do código, agentes com papel definido, um loop de revisão que só para quando não sobra achado, e um segundo modelo, de outro fornecedor, procurando defeito no que o primeiro escreveu. Este post abre esse workflow de desenvolvimento com IA peça por peça, com os números dos dois projetos, o que quebrou no caminho e o que os próprios laboratórios dizem que fazem em casa.

Commits por mês no ERP

Dados próprios

out/202320

jul/202410

set/202552

out/202540

fev/20262

abr/2026127

mai/2026135

jun/2026123

Olha, vibe coding tem lugar

Sou entusiasta de IA escrevendo código desde antes de existir agente, e contei no post sobre a Cardeal como era fazer isso no Cursor em 2025. O termo vibe coding nasceu num post do Andrej Karpathy em 2 de fevereiro de 2025, registrado na Wikipedia: "se entregar às vibes" e esquecer que o código existe. Pra protótipo, pra script de uso próprio, pra testar uma ideia num domingo, funciona e eu uso.

O problema começa quando o código sai do localhost⁴. A Veracode testou mais de 150 modelos e publicou em 24 de março de 2026 que só 55% das tarefas de geração resultaram em código seguro, o mesmo patamar de dois anos antes. Na pesquisa da Stack Overflow de 29 de julho de 2025, com mais de 49 mil devs, 66% apontam como maior frustração o código "quase certo, mas não exatamente". O próprio Karpathy, um ano depois do post original, passou a chamar o que faz de "agentic engineering", segundo a cobertura de fevereiro de 2026: orquestrar agentes em vez de aceitar o que sai da tela.

Vibe coding é aceitar a vibe. Workflow é desconfiar dela por sistema, e o resto deste post é o custo dessa desconfiança.

Spec antes de código

No ERP nenhuma feature começa por prompt. Começa por uma change no OpenSpec, projeto open source de agosto de 2025 que guarda as especificações dentro do repositório: um arquivo de proposta com o porquê, um de design com o como e um de tarefas com a lista do que fazer, tudo versionado no git⁵ ao lado do código. O repositório tem hoje 98 capacidades especificadas e 99 changes arquivadas, cada uma commitada antes do código que ela descreve. A conta que saiu dessa disciplina me surpreendeu: são 85.608 linhas de markdown⁶ versionado contra 68.946 linhas de Ruby. Tem mais especificação do que código de produção.

Na POC de marketplaces o fluxo foi o do superpowers, plugin de Claude Code que o Jesse Vincent publicou em 9 de outubro de 2025 e que entrou no marketplace oficial da Anthropic em janeiro de 2026. A sequência é brainstorming em perguntas, spec de design, plano de implementação, e só então código. O spec ficou com 283 linhas. O plano, com 3.770, treze vezes o spec, e maior que todo o código-fonte final, que fechou em 3.727 linhas. O plano contém o código: cada tarefa traz os testes prontos, a implementação pronta pra colar e a saída esperada de cada comando, inclusive a mensagem de erro exata que o teste deve dar antes de a implementação existir. Entre o commit do plano e o primeiro commit de código passaram 14 minutos.

Não é ideia minha. As práticas oficiais do Claude Code pedem pra deixar o modelo entrevistar você e escrever um arquivo de spec antes de tocar em código, e o GitHub lançou o Spec Kit em 2 de setembro de 2025 dizendo que "a intenção passa a ser a fonte da verdade" no lugar do código. A conversa some, o arquivo fica.

Agentes com papel e memória

O ERP tem dez agentes definidos em arquivos de texto na pasta .claude/agents/, cada um com nome, modelo, ferramentas permitidas e uma descrição de papel. Pela documentação da Anthropic, cada subagente roda na própria janela de contexto, com o próprio prompt de sistema. Na prática o revisor não sabe o que o implementador estava pensando, e é isso que o torna útil.

• Arquiteto de solução: transforma uma issue⁷ em ADR⁸ e change de OpenSpec, investigando o código antes de propor.
• Implementador Rails: implementa uma change de ponta a ponta com TDD⁹ e termina com a suíte verde, sem commitar.
• Adversário de testes: lê as mudanças e adiciona testes pra borda que o implementador não cobriu, como CST inesperado, rejeição da SEFAZ ou job rodando duas vezes. Só escreve na pasta de testes.
• Revisor de navegador: abre o app num Chrome de verdade e clica. Se não conseguir rodar, escala em vez de aprovar em silêncio.
• Os outros seis cuidam de tela e de produto: fidelidade ao design system, pesquisa de mercado em fontes públicas, product manager, product designer, revisor de arquitetura e um crítico que só checa rigor, nunca direção.

Cada agente tem memória própria por projeto, 35 arquivos hoje. Um exemplo do crítico, gravado depois de um erro: "a tela irmã pode existir, mas o campo citado dentro dela não; conferir o âncora interno". É a mesma técnica do post sobre como criar skills: a correção vira regra depois do erro. Boris Cherny, criador do Claude Code, contou à Fortune em 11 de junho de 2026 que trabalha com "times de Claudes" com personas distintas fazendo revisão de código e de segurança.

Comandos e loops: o pipeline de uma issue até o PR

Agente solto é ferramenta. O que amarra os dez é um comando chamado /ship, também um arquivo de texto, que recebe o número de uma issue e roda seis passos: cria uma worktree¹⁰ isolada com o próprio banco em Docker¹¹, faz triagem, chama o arquiteto, roda um loop de revisão de arquitetura, dispara a implementação com o endurecimento de testes e de tela em paralelo, roda o loop de revisão de código e para. O merge¹² é meu, sempre. Hoje há 11 worktrees ativas no projeto, cinco delas em variantes de CST de ICMS ao mesmo tempo.

O motivo do comando está escrito no design dele, de 16 de junho de 2026: "hoje o founder é o orquestrador manual entre os estágios e o revisor final de tudo. Com o backlog crescendo, o founder virou o gargalo de vazão do projeto." A OpenAI chegou à mesma conclusão. No post harness engineering, de 11 de fevereiro de 2026, três engenheiros contam que produziram cerca de um milhão de linhas e 1.500 PRs¹³ em cinco meses sem escrever nenhuma à mão, num loop em que os agentes pedem revisões até "todos os revisores estarem satisfeitos". O lema deles: humanos dirigem, agentes executam.

O loop de revisão do ERP para por convergência de conteúdo, quando uma rodada não produz achado grave ou médio dentro do escopo, e nunca por contador: "um teto fixo é proibido, porque força entrega apressada e enviesa o implementador a adiar o que poderia corrigir". Decidir entre corrigir e adiar é do orquestrador, nunca do implementador. No PR 268 o loop foi até a quinta rodada em 27 de maio de 2026, cada uma com um achado de severidade alta corrigido e registrado no título do commit.

Revisão com dois modelos de fornecedores diferentes

Na rodada de código o PR passa por até seis revisores: os do plugin de revisão do Claude Code (revisor de código, caçador de falha silenciosa, analista de testes), o revisor de navegador, o Claude na nuvem via GitHub Actions¹⁴ e o Codex, da OpenAI, rodando gpt em modo adversarial. O Codex é obrigatório: se a linha de comando dele não estiver autenticada, o pipeline escala em vez de pular. O nome dele aparece em 53 mensagens de commit do repositório.

O motivo é viés de autopreferência. Panickssery, Bowman e Feng mostraram em abril de 2024 que modelos reconhecem a própria escrita e a avaliam melhor. As práticas do Claude Code admitem isso do próprio lado: recomendam revisor em contexto limpo "porque não estará enviesado pelo código que acabou de escrever", e avisam que "um revisor instruído a achar falhas geralmente acha, mesmo quando o trabalho está bom". A OpenAI disse em 15 de setembro de 2025 que o Codex já revisava "a vasta maioria" dos PRs internos antes de a revisão humana começar.

O dado mais honesto que achei é um estudo submetido em 22 de julho de 2026 por Xiang e colegas: em 116 tarefas, o Claude revisando código do Codex elevou a taxa de aprovação de 71,6% pra 89,7%; o Codex revisando código do Claude derrubou de 91,4% pra 82,8%. Segundo modelo ajuda, mas o par precisa ser medido, e por aqui eu meço pelo commit. Em 6 de junho de 2026 o Codex levantou três achados num PR de variantes de produto. Um formulário gravava estoque direto no banco, furando o razão de movimentações. Um componente de kit não validava se o item era do mesmo lojista, o que deixaria uma requisição forjada ligar produto de outro cliente. Os dois foram corrigidos. O terceiro, que o Codex classificou como crítico, era migração sem preenchimento de dado antigo num sistema pré-produção que recria o banco do zero. Foi rejeitado com justificativa no PR, e a mensagem do commit registra que "o próprio Codex admite 'se for intencionalmente reset-only'".

Teste antes, como trilho

Nos dois projetos a IA escreve o teste antes do código, e o plano prevê a falha. No plano da POC, o segundo passo de cada tarefa é "rodar e ver falhar", com a saída esperada escrita, ModuleNotFoundError: poc.identity.names. O quarto é "rodar e ver passar", com a contagem, 4 passed. A suíte roda sem rede, com clientes falsos, e com avisos tratados como erro. Fechou em 259 funções de teste pra 50 módulos, quase uma linha de teste por linha de produção.

Dados próprios

3.192

casos de teste na suíte do ERP em 15 de junho de 2026, contra 1.684 em 3 de maio

Cobertura de linhas em 79,5% pelo SimpleCov; os números vêm das mensagens de commit, que registram a contagem da suíte a cada PR

No ERP a suíte quase dobrou em seis semanas, com cobertura¹⁵ de linhas em 79,5%. Parte disso é o adversário de testes. Parte é convenção codificada em teste: existe um que quebra se alguém adicionar uma coluna decimal sem precisão declarada, porque em nota fiscal 0,1 mais 0,2 diferente de 0,3 vira rejeição da SEFAZ por divergência de somatório, e a IA adora "converter preventivamente" pra float. Os times da Anthropic descrevem o mesmo hábito no relato de 24 de julho de 2025 sobre como usam o Claude Code: dar ao modelo um jeito de verificar o próprio trabalho e pedir os testes antes do código.

O que quebrou

A parte da conta que não cabe em carrossel.

• O review na nuvem não postava. Entre os PRs 285 e 290, em junho de 2026, o plugin de revisão automática rodava no GitHub e não conseguia comentar, mesmo com token válido e permissão de escrita. Desenhei uma alternativa, registrei o motivo de descartar o caminho antigo, e dias depois reverti a decisão: o que funcionou foi a menção @claude no comentário do PR. O workflow automático está desligado, com o motivo no cabeçalho do arquivo.
• O isolamento falhou em silêncio. A derivação do nome da stack Docker apagava maiúsculas e separadores, então duas worktrees chamadas dryA e dryB caíam no mesmo banco. Só apareceu num teste a seco em 22 de junho.
• Na POC, metade do histórico é correção: 54 commits com prefixo fix contra 33 com feat, quase todos concentrados em três rodadas de revisão, uma delas com 15 commits em 38 minutos.

Commits da POC por tipo, em 48 horas

Dados próprios

fix54

feat33

docs18

test8

chore2

E tem o custo de tempo do processo. O estudo da METR de 10 de julho de 2025, com 16 devs experientes em projetos open source, mediu que com IA eles levaram 19% mais tempo por tarefa enquanto achavam que tinham sido 20% mais rápidos. Eu não meço tempo por tarefa. Meço quanto backlog fecha por mês com a suíte verde, e o painel do começo do post mostra onde isso foi parar.

O que os labs fazem com as próprias ferramentas

O Anthropic Institute publicou em 4 de junho de 2026 que, em maio, mais de 80% do código mergeado na base da empresa foi escrito pelo Claude, contra poucos por cento antes de fevereiro de 2025, com a ressalva da própria empresa de que medir em linhas exagera. O Google disse pela boca do Sundar Pichai, em 22 de abril de 2026, que 75% do código novo é gerado por IA e aprovado por engenheiros, vindo de 25% em outubro de 2024. Na OpenAI, 99,8% dos tokens de saída gerados internamente vêm do Codex, segundo telemetria de 25 de junho de 2026.

O que os três têm em comum raramente vira manchete: explorar, planejar, implementar e commitar como fases separadas; verificação automática; commits pequenos com ponto de retorno; revisor separado do implementador; e humano no leme. O DORA 2025, publicado pelo Google Cloud em 23 de setembro de 2025, mediu que adoção de IA aumenta a vazão de entrega e continua reduzindo a estabilidade, e apontou lotes pequenos e controle de versão entre as capacidades que revertem isso. É a mesma lista.

O trilho continua sendo meu

O modelo qualquer um aluga. O processo em volta dele é o que tenho de meu, e está inteiro em arquivos de texto versionados no repositório: agentes, comandos, specs, planos, políticas de escalonamento e a memória do que deu errado. Um dev novo, humano ou não, abre a pasta e roda o mesmo pipeline. Se quiser acompanhar o que vou escrevendo sobre isso, o feed RSS do blog, o meu LinkedIn e o Instagram danielsilvestre.ai são os lugares.

IA escreve o código. O trilho continua sendo meu.

FAQ

O que é um workflow de desenvolvimento com IA?

É o processo em volta do modelo: como a tarefa vira especificação, quem implementa, quem revisa, quando o loop para e o que fica registrado. No meu caso vive em arquivos de texto dentro do repositório, versionados junto com o código.

Qual a diferença entre vibe coding e um workflow de desenvolvimento com IA?

Vibe coding aceita o que o modelo entrega e segue. O workflow desconfia por sistema: spec antes, teste antes, revisão por agente que não escreveu o código e humano decidindo o merge. Pra protótipo o primeiro basta. Pra código que atende cliente, o segundo é o mínimo.

Precisa mesmo de um modelo de outro fornecedor pra revisar?

Modelos avaliam melhor a própria escrita, então um segundo par de olhos de outra família pega coisa diferente. O ganho depende do par, e o estudo de julho de 2026 mostra que a direção importa. Meça no seu código: conte os achados que você corrigiu e os que rejeitou com motivo.

Notas

1. ERP é o sistema de gestão que junta pedido, estoque, nota fiscal e financeiro num lugar só. No caso, feito pra lojista pequeno que vende em marketplace. ↩

2. Commit é cada gravação registrada no histórico de um projeto: o que mudou, quem mudou e quando. ↩

3. POC, sigla de proof of concept, é um protótipo pra provar que uma ideia funciona antes de investir no produto. ↩

4. Localhost é o endereço da sua própria máquina. Código que "roda no localhost" funciona no computador de quem escreveu e ainda não foi testado por mais ninguém. ↩

5. Git é o sistema que guarda arquivos com histórico e permite voltar a qualquer versão. Repositório é a pasta de um projeto dentro dele. ↩

6. Markdown é texto comum com uma marcação leve pra título, lista e link, legível por gente e por máquina. ↩

7. Issue é o registro de uma tarefa ou problema no GitHub, com número, descrição e discussão. ↩

8. ADR, sigla de architecture decision record, é um documento curto que registra uma decisão de arquitetura, o contexto e as alternativas descartadas. ↩

9. TDD, sigla de test-driven development, é escrever o teste antes do código, vê-lo falhar, escrever só o necessário pra passar e repetir. ↩

10. Worktree é uma cópia de trabalho separada do mesmo repositório, com a própria pasta e o próprio branch, pra mexer em duas coisas em paralelo sem uma atrapalhar a outra. ↩

11. Docker empacota um programa com tudo que ele precisa pra rodar. Uma stack Docker é o conjunto de banco, filas e serviços de um projeto subindo juntos. ↩

12. Merge é o ato de juntar as mudanças de um branch ao código principal. É o ponto em que o código vira oficial. ↩

13. PR, sigla de pull request, é o pedido pra incluir um conjunto de mudanças no código principal, com revisão antes do merge. ↩

14. GitHub Actions é o serviço do GitHub que roda scripts automaticamente quando algo acontece no repositório, como abrir um PR ou comentar nele. ↩

15. Cobertura de testes é a fração das linhas do código que algum teste executa. Não garante que o teste esteja certo, só que ele passou por ali. ↩