Como construímos o NexFlow com agentes de IA, e onde o humano entra
Agentes de IA escrevem parte do código e dos documentos. Um engenheiro especifica, revisa e aprova tudo antes de ir para produção. Aqui estão o método, os números com fonte e os erros.
- 32 concluídas de 41 iniciativas registradas desde 29/06/2026; o resto está em andamento, em espera ou sem estado
- 34 + 34 versões publicadas do backend e do app web
- 74,6% das linhas do backend cobertas por testes (471 testes)
- 28,9% das linhas do app web cobertas (368 testes); a medição inclui os arquivos de tela
A primeira versão do NexFlow em produção é de 26/04/2026, anterior a este método. Depois de 29/06/2026, cada iniciativa nasce como especificação. O git não distingue o que veio de agente e o que veio de gente, por isso não publicamos "proporção de código por IA". Não afirmamos que o NexFlow foi feito só por IA.
Fonte e data de cada número
- 32 concluídas de 41 iniciativas registradas desde 29/06/2026; o resto está em andamento, em espera ou sem estado. Fonte: nexFlow-specs: campo Status do aidlc-state.md de cada iniciativa (PLN-01 a PLN-41; as 4 specs iniciais não têm estado e não entram nas concluídas). Conferido em 2026-10-22.
- 34 + 34 versões publicadas do backend e do app web. Fonte: Tags de versão dos repositórios do backend e do app web (git). Conferido em 2026-10-21.
- 74,6% das linhas do backend cobertas por testes (471 testes). Fonte: Jest com cobertura, backend, execução local. Conferido em 2026-10-21.
- 28,9% das linhas do app web cobertas (368 testes); a medição inclui os arquivos de tela. Fonte: Vitest com cobertura, app web, execução local. Conferido em 2026-10-21.
O problema
Uma pessoa, pouco tempo e um produto que não pode quebrar.
O NexFlow lida com o dinheiro de quem o usa. Errar uma projeção custa confiança. Quem o constrói tem emprego, mestrado e família, então o tempo é o recurso mais escasso.
Agentes de IA aceleram o que é repetível. O risco é acelerar também o erro. Por isso o método existe: deixar claro o que o agente pode fazer sozinho e o que só vale depois de uma pessoa aprovar.
O método
Especificar, aprovar, construir, testar, publicar.
Cada iniciativa passa pelas mesmas etapas. Os critérios de qualidade são definidos antes do código.
Levantar o que já existe
O agente lê o código e resume o estado atual. O engenheiro confere se o resumo bate com a realidade antes de aceitar o pedido.
Especificar
Requisitos, regras e critérios de aceite viram documento. O que o agente supôs aparece marcado como premissa.
Aprovar o plano
O engenheiro lê o plano e aprova. Sem aprovação, não há código.
Construir e testar
O agente escreve o código e os testes, uma unidade por vez. Se o teste falha, o trabalho para e a falha é discutida.
Revisar e publicar
O engenheiro revisa o que mudou. A publicação só acontece com o pedido dele, e o pipeline é acompanhado até ficar verde.
Agente e engenheiro
Quem faz o quê.
Quem decide é sempre a pessoa. O agente propõe.
Onde a IA errou
Três erros reais e o que o processo fez com cada um.
Escolhidos do nosso próprio registro de aprendizados. Cada um virou uma regra para as iniciativas seguintes. Um deles se repetiu antes de virar regra.
O corte que apagou os avisos
O que aconteceu. Ao reorganizar o layout do painel, o agente cortou um arquivo de tela por posição de texto. Um comentário repetido fez o corte apagar os avisos de período de teste e de assinatura.
O que o processo fez. O erro apareceu na conferência visual da entrega e foi corrigido na mesma iniciativa, com os avisos restaurados. Regra: conferir a diferença de qualquer arquivo de tela movido, nunca cortar por posição.
O cliente que chegou antes do servidor
O que aconteceu. Um cliente passou a depender de um endpoint novo e foi instalado antes de o servidor ser publicado. O 404 virou lista vazia, e a tela dizia "Tudo em ordem", o que enganava.
O que o processo fez. O episódio virou regra do projeto, registrada na iniciativa em que aconteceu: publicar o servidor, depois o painel, depois os clientes.
O tipo de coluna que o teste não conhecia
O que aconteceu. O agente declarou uma coluna de data com um tipo que o banco de produção aceita, mas o banco dos testes não reconhece. Em vez de um erro claro, a conexão ficava tentando de novo em silêncio.
O que o processo fez. Os testes falharam com um aviso genérico de conexão. O mesmo erro apareceu em duas iniciativas diferentes, e só na segunda virou regra do projeto: usar tipos aceitos pelos dois bancos.
Stack
Começar barato, escalar depois.
- Backend: NestJS e TypeORM, com PostgreSQL no Supabase.
- Infraestrutura: AWS Lambda com API Gateway.
- Painel web: Angular.
- Login: Supabase Auth. Cobrança: Stripe Billing.
- Aplicativos: Kotlin Multiplatform com interface nativa (ainda sem publicação nas lojas).
O código do NexFlow não é aberto. O que abrimos é o processo.
As três regras no desenvolvimento
As mesmas regras da marca, aplicadas ao método.
- Mostrar a conta
- Todo número deste texto tem fonte e data de conferência.
- Você decide
- Nada vai para produção sem aprovação humana, e o agente para quando um teste falha.
- IA identificada
- Cada iniciativa mantém um registro de pedidos e decisões, e os documentos marcam o que foi pedido, o que está no código e o que é suposição. O histórico do git, por si só, não identifica a origem.
O que aprendemos
Quatro lições.
- Levantar o que existe antes de aceitar o pedido. Um pedido descreveu como "quase vazio" um site que tinha três páginas completas, e o levantamento evitou refazer tudo.
- A ordem de publicação faz parte do desenho. Servidor, depois painel, depois clientes; no site, primeiro o conteúdo e depois a regra de redirecionamento.
- Texto copiado à mão diverge. O que aparece em vários lugares deve ter uma fonte única.
- Decisão delegada sem o fato por trás: o item sai, não vira palpite. Pedimos ao agente para "sugerir o melhor" texto legal da empresa sem termos a razão social e o CNPJ; o campo saiu do site em vez de receber um valor plausível.
O processo está aberto: modelos, prompts, critérios de qualidade e um exemplo fictício percorrendo o fluxo. Abrir o playbook no GitHub