IA sem governança erra rápido, e você descobre em produção.
Um agente de código sozinho não distingue o que é regra de negócio do que é defeito, nem o que é decisão sua do que é detalhe de implementação. Ele preenche a lacuna com a resposta mais plausível e segue em frente.
Copia o defeito por imitação
O legado tem uma anomalia. Para o agente, aquilo é só o comportamento atual, então ele reproduz. Ou pior: corrige por conta própria, sem ninguém saber que o comportamento mudou.
Respostas plausíveis que não combinam
Cada lacuna ambígua recebe uma escolha razoável, tomada isoladamente. Juntas, elas se contradizem. A incoerência só aparece em produção, como comportamento inesperado.
A regra fica na cabeça de quem leu
O conhecimento de negócio foi extraído do código para gerar a entrega e evaporou junto com a sessão. A documentação, se existir, vem depois, quando já virou dívida.
Apaga o que parece morto
Código sem uso aparente é removido por iniciativa própria. Ninguém confirmou que era mesmo órfão, e ninguém registrou a remoção.
Fronteiras decididas por conveniência
O que é domínio de negócio e o que é camada técnica acaba definido pelo que era mais fácil de gerar naquele prompt, não pelo desenho do negócio.
Nenhum rastro de quem decidiu o quê
O raciocínio vive no histórico de um chat que ninguém revisa e que some ao fim da sessão. Depois não há como auditar a escolha, reaproveitá-la em outro projeto ou saber de quem ela foi.
Nenhum desses problemas é falta de capacidade do modelo. São decisões de produto e de arquitetura que o agente não tinha como tomar, e tomou mesmo assim, porque ninguém desenhou onde ele deveria parar.
Ele decide o que o agente vê, em que ordem, e onde você entra.
O que ele é
- Uma camada de orquestração sobre um agente de código: distribui o trabalho entre agentes especializados, monta o contexto de cada um, controla a sessão e define o critério de saída.
- Cada agente trabalha com contexto próprio e limpo. Recebe o que precisa ver para aquele recorte, e nada além.
- Ler o legado, escrever a documentação e implementar segue sendo trabalho do agente de código.
O que ele não é
- Não é um scanner. Nenhuma heurística proprietária tenta entender o código no lugar do agente de código.
- Não é só um chat. A conversa livre existe e é útil, mas é transitória por decisão de projeto: o que direciona o projeto vive em artefato versionado, não no histórico de uma conversa.
- Não é mais uma IA para contratar. O Clovis orquestra o agente que o seu desenvolvedor já usa no dia a dia.
Onde o resultado fica
Tudo em arquivo de texto, dentro do próprio repositório.
A memória da descoberta e das decisões humanas
O mapa funcional: domínios, dependências e ordem
A documentação autoritativa de cada domínio
As specs, planos, cenários de teste e tarefas de cada unidade de trabalho
O conhecimento fica em arquivo, no Git, revisável em Pull Request e reutilizável pelo próximo agente e pelo próximo desenvolvedor.
Quatro agentes. Cada um com uma entrada, um trabalho e uma saída.
O trabalho não vai todo para o mesmo lugar. Cada etapa tem um agente com contexto próprio, e a saída de uma é a entrada da seguinte. Escolha uma etapa para ver o que entra, o que ela faz e o que sai.
Etapa 01
De repositório desconhecido a mapa de domínios de negócio.
Entra
- O código a analisar, e o caminho do legado quando houver
- Regras de negócio em projeto novo: texto livre, arquivos, URLs ou espaços de MCP (Jira, Confluence, wiki)
- Tipo de sistema e restrições críticas: stack-alvo, contratos a preservar, schema fixo, exigência de testes
Faz
- Investiga o código legado ou a documentação de negócio em várias frentes ao mesmo tempo
- Correlaciona telas, endpoints, tabelas e regras para identificar bounded contexts: domínios de negócio, não estrutura de pastas
- Cita evidência de cada inferência e classifica o grau de confiança
- Escala como decisão tudo que não se sustenta na evidência
Sai
- O mapa funcional: os domínios, as dependências entre eles e a ordem de implementação sugerida
- A memória da descoberta: restrições declaradas e o registro das decisões humanas, que têm precedência sobre o comportamento do código para todos os agentes seguintes
- A lista de domínios a documentar e as skills técnicas a gerar
Cinco decisões de projeto, e o que cada uma evita.
Escala em vez de supor
O que não se sustenta na evidência vira pergunta, não palpite. Foram 39 pontos ambíguos elevados ao humano nos três projetos, e nenhuma dessas perguntas atrasou a entrega.
- 39 decisões escaladas
- 0 atraso
Contexto limpo por agente
Cada agente recebe o recorte dele e nada além. É o que evita o agente perder o fio no meio de um domínio grande e o que mantém a resposta previsível.
Conhecimento em arquivo, não em chat
Spec, plano, tarefas e decisões vivem no repositório e passam por Pull Request, como qualquer outra mudança. O histórico de uma conversa não passa por revisão e não sobrevive à sessão.
Documentação antes da implementação
O domínio é documentado a fundo antes de virar código, e é dessa documentação que a spec sai. Por isso não sobra débito de documentação no fim do ciclo.
Não substitui o seu agente
O Clovis orquestra o agente de código que o time já usa. O desenvolvedor continua na ferramenta dele, e a sua empresa não aprova mais uma assinatura de IA para isso funcionar.
Três ferramentas que você usa a qualquer momento, sem entrar no fluxo.
Conversa livre
Conversa aberta com o agente de código, sem fluxo estruturado e sem pré-requisito de descoberta.
- Modo agente: sem restrição, investiga, edita e roda comandos
- Modo plano: somente leitura, apresenta um plano para você revisar antes de mandar executar
- Transitória: a conversa não é gravada, e sair descarta o histórico
Code review
Revisa duas branches locais ou um Pull Request, rodando os checks do projeto.
- Levanta achados estruturados a partir dos checks do projeto
- Você escolhe quais publicar no PR e pode ajustar o texto de cada comentário
- No modo local, consolida os achados em arquivo fora do versionamento
Criar Pull Request
O agente analisa o diff entre as branches e detecta o provedor de hospedagem.
- Usa o template de PR do projeto quando existe, e gera título e corpo
- Publica só após aprovação e devolve a URL do PR
- Também acessível como atalho ao fechar um lote na implementação
Pré-requisito único: um agente configurado
Nenhum dos três exige descoberta, documentação ou especificação prévia. Dá para entrar em um projeto qualquer e usar só a ferramenta de que você precisa. A disciplina é a mesma do fluxo: o agente investiga, escala o que não consegue decidir e só age depois da sua resposta.
Três projetos reais, três pontos de partida diferentes.
Os clientes estão anonimizados; os números vêm do material original. Cada case traz o prazo e também as decisões em que o agente parou para perguntar antes de seguir.
Os prazos convencionais dos cases A e B são estimativa de referência para o escopo entregue. O do case C é a previsão formal do projeto.
A velocidade apareceu. A decisão continuou humana.
A velocidade que apareceu
- Case A~1 mês de uma dupla3 dias de trabalho
- Case B~3 semanas de uma dupla2 dias de trabalho
- Case C3 meses com 5 pessoas1 mês com 3
A decisão que continuou humana
- 39 pontos ambíguos viraram pergunta ao humano nos três projetos
- Regra de negócio, fronteira de domínio, defeito de legado e escolha de arquitetura: nenhum foi resolvido por suposição
- Nenhuma dessas perguntas atrasou a entrega
A velocidade não veio de afrouxar a supervisão. Veio de tirar do caminho o trabalho de contexto, investigar, documentar e especificar, que é o que consome o tempo de quem decide. O humano entra onde a decisão é dele, e o que ele decide vira regra escrita, versionada junto do código.
O que costumam perguntar
O Clovis substitui o agente de código que a gente já usa?
Não. Ele orquestra o agente que o seu time já usa. Ler o legado, escrever a documentação e implementar continua sendo trabalho do agente de código; o Clovis decide o que ele vê, em que ordem, e onde você entra. O pré-requisito é justamente ter um agente configurado.
Preciso rodar o fluxo inteiro para usar?
Não. Conversa livre, code review e criar Pull Request funcionam fora do fluxo e não exigem descoberta, documentação ou especificação prévia. Dá para entrar em um projeto qualquer e usar só a ferramenta de que você precisa naquele momento.
Quanta supervisão isso exige do time?
A supervisão acontece onde a decisão é sua, e não a cada linha gerada. Investigação, documentação, especificação e implementação chegam prontas para revisão, com o raciocínio à vista. Nos três projetos foram 39 decisões escaladas ao todo, e nenhuma atrasou a entrega.
Onde fica o que ele produz? Some quando a sessão fecha?
Fica no repositório, em arquivo de texto versionado: mapa funcional, memória da descoberta, documentação por domínio, specs, planos, cenários de teste e tarefas. Passa por Pull Request como qualquer outra mudança. A conversa livre é o único artefato transitório, e isso é decisão de projeto.
Funciona em legado sem documentação nenhuma?
É o caso mais comum. Em um dos projetos o código-fonte estava guardado dentro de tabelas do banco, sem repositório para clonar. O agente de Descoberta investiga, correlaciona telas, endpoints e tabelas para identificar domínios de negócio, cita evidência de cada inferência e escala o que não se sustenta.
E quando ele encontra um defeito no legado?
Ele não reproduz por imitação nem corrige por conta própria. Apresenta os caminhos possíveis e espera a sua decisão. Foi o que aconteceu com uma exclusão indevida de respostas em um dos cases: a decisão humana entrou na documentação junto com o contraste com o legado, para que ninguém recopie o defeito depois.
Dá para trabalhar em várias aplicações ao mesmo tempo?
Sim. Em um dos projetos foram cinco aplicações do mesmo cliente em paralelo, com decisões de arquitetura valendo nas cinco ao mesmo tempo, sem perder o rastro de quem decidiu o quê em qual frente.
Traga um repositório seu. A gente roda a Descoberta em cima dele.
Uma conversa técnica com o CLI rodando. Você vê o mapa funcional saindo do seu próprio código e as primeiras decisões subindo para você, em vez de ver slide.