DB1 Itênex
BRENES
Falar com especialista
Produto DB1 Itênex · Clovis Agentic

Engenharia de Software Agêntica sem abrir mão do controle de especialistas.

Conheça o Clovis, nossa ferramenta de orquestração de agentes de IA que garante a governança e a qualidade das decisões e do código gerado em todo o ciclo de desenvolvimento, do discovery ao deploy.

Funciona com a IA que o seu time já usaPergunta antes de decidirDocumentado e rastreável

Quem já usa

  • BRK

    Migração 4x mais rápida, com 60% do custo

  • MAG

    Da ideia à solução documentada em 1 semana

  • Votorantim

    Análises de impacto mais certeiras desde que o Clovis entrou

  • CrediSis

    9x mais entregas do time em 4 meses

O problema

O seu time já usa IA para programar. Mas ele controla o que ela decide?

Ferramenta de IA não é mais o problema.

O seu time já tem uma. Dividir o trabalho em etapas e gerar documento também já existe, muitas vezes de graça.

Velocidade sem método vira retrabalho.

A IA preenche o que ninguém explicou com o palpite mais provável. O erro aparece depois, em produção.

Mais IA nem sempre é mais resultado.

Parte do mercado ganha quando a IA consome mais, não quando ela entrega melhor.

No dia a dia do time

A demanda chega pela metade

Sem analista dedicado, o card é escrito às pressas na planning. O desenvolvedor começa com dúvida e a reunião vira redação.

A IA decide o que era seu

Regra de negócio, erro antigo do sistema, o que manter e o que apagar: ela escolhe sozinha, e ninguém fica sabendo.

O conhecimento vai embora com a conversa

O que a IA descobriu sobre o seu negócio fica num chat que some no fim do dia. A documentação, quando existe, vem depois.

Não falta capacidade à IA.Falta garantir controle sobre as decisões que ela toma e consistência nos artefatos que ela produz.É isso que o Clovis faz.

O que o Clovis faz

Três jeitos de trabalhar com IA, sempre com você no controle.

01Descoberta

Da ideia vaga ao requisito pronto.

Você descreve a necessidade do seu jeito. O Clovis faz as perguntas certas e devolve um documento que o time inteiro entende.

  • Perguntas curtas, com opções para escolher
  • O que você não sabe vira pendência, não suposição
  • O documento vai direto para Confluence, Jira ou Azure DevOps
“Pela primeira vez conseguimos entrar na sprint com cards bem estruturados, com contexto, objetivo e critérios de aceite definidos. A planning ficou mais curta e focada no que importa: priorizar e planejar.”
Squad MAG, sem analista dedicado
Para o time técnico
  • O documento sai em 11 seções: contexto, objetivo, escopo, atores, regras de negócio, fluxos, casos-limite, critérios de aceite, glossário, pendências técnicas e perguntas abertas.
  • Cada resposta sua fica marcada no documento. Decisão técnica é registrada como pendência para o tech lead, sem interromper quem está descrevendo o negócio.
  • Não exige nenhuma etapa anterior: dá para começar por aqui em qualquer projeto.

02Conversa livre

Pergunte ao sistema antes de mexer nele.

Uma conversa aberta sobre o seu código, para entender como algo funciona hoje, planejar uma mudança e, com o seu ok, executar.

  • Entende sistemas que ninguém documentou
  • Mostra o plano antes de alterar qualquer coisa
  • Funciona em qualquer projeto, sem preparação
Na MAG, a leitura do código de serviços de vários times reuniu num só mapa, na mesma semana, as integrações de que o novo assistente precisava.
MAG
Para o time técnico
  • Modo agente: investiga, edita e roda comandos, sem restrição.
  • Modo plano: somente leitura. Apresenta um plano para você revisar antes de mandar executar.
  • A conversa é transitória por decisão de projeto: o que direciona o projeto vive em arquivo versionado, não no histórico de um chat.

03Codificação com observabilidade

Você acompanha cada passo. E decide o que é seu.

Da análise ao código entregue, você vê o que a IA está fazendo, e ela para e pergunta sempre que a decisão é de negócio.

  • O que construir fica escrito antes do código
  • Cada decisão sua fica registrada para as próximas entregas
  • Termina numa entrega pronta para revisão
Na Votorantim, ao especificar um ajuste no programa de cashback para lojistas, o Clovis mapeou fluxos que a análise inicial não tinha considerado e levantou as perguntas certas antes do código.
Votorantim
Para o time técnico
  • Quatro etapas encadeadas (Descoberta, Preparação, Especificação e Implementação), cada uma com um agente especializado e contexto próprio. Na Descoberta, vários agentes investigam em paralelo.
  • Antes do código saem a especificação, o plano, os cenários de teste e as tarefas. As decisões humanas ficam num arquivo próprio e valem para todos os agentes seguintes.
  • Divergência entre documentação e código vira decisão escalada, nunca correção silenciosa. O ciclo termina em Pull Request.
As quatro etapas da codificação, em detalhe

O Clovis executa as etapas 1 a 4 do método Core Up, da Descoberta à Implementação. Cada agente trabalha com contexto próprio e gera o insumo da etapa seguinte. A etapa 5, Runtime Intelligence, acompanha o sistema em produção.

Etapa 01

De uma intenção abstrata ao mapa de domínios de negócio.

Entra

  • O código a analisar, e o caminho do legado quando houver
  • Regras de negócio e documentação: 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

Etapa 02

A intenção abstrata vira documentação autoritativa.

Entra

  • O mapa funcional como ponto de partida
  • A memória da descoberta, relida a cada domínio
  • A lista de domínios, que define a ordem do trabalho
  • O código legado, quando disponível, ou a documentação de negócio

Faz

  • Gera as instruções globais do projeto, enxutas: stack, estrutura, convenções e comandos reais de build e teste
  • Documenta cada domínio a fundo: schemas, validações campo a campo, edge cases, tratamento de erro
  • Gera as skills técnicas transversais: arquitetura, testes, documentação de API, segurança
  • Verifica no fim se toda decisão transversal tem um lugar concreto na documentação

Sai

  • Uma skill por domínio, que passa a ser a fonte de verdade do negócio: descreve o comportamento esperado, agnóstica de framework e biblioteca
  • Os arquivos de instrução do repositório, lidos por qualquer agente de código que entre no projeto
  • Skills técnicas reutilizáveis

A partir daqui o legado não é mais lido. O que faltar na documentação vira pergunta ao humano.

Etapa 03

Do conhecimento de negócio a um plano executável.

Entra

  • A skill do domínio como contexto obrigatório, o mapa funcional e as instruções do projeto
  • A operação escolhida: domínio inteiro, evolução de um domínio, funcionalidade multi-domínio, bug de especificação ou bug de implementação
  • A descrição da feature ou do bug em texto livre, com documentos de referência

Faz

  • Trabalha a partir da documentação do domínio, não do legado, e produz tudo numa sequência só, sem perder o contexto entre uma parte e a próxima
  • Reconhece o código atual para declarar o que já existe e o que falta
  • Mantém o mesmo formato em tudo que gera, por um padrão de autoria versionado
  • Cria uma tarefa explícita de atualizar a documentação quando o comportamento documentado muda, e ela é sempre a primeira da fila

Sai

  • A especificação: o que precisa existir e por quê, com as regras de negócio que valem
  • O plano de execução: como construir, o que reaproveitar e o que falta
  • Os cenários de teste, cada um com identificador próprio, para validar a entrega de ponta a ponta
  • As tarefas, com dependências declaradas, cada uma entregando comportamento completo

Etapa 04

Executa em lotes, com supervisão a cada lote.

Entra

  • A spec a ser implementada
  • As tasks pendentes marcadas pelo humano
  • Aviso de dependência faltante antes de disparar

Faz

  • Implementa as tasks marcadas: o agente de código decide o que fazer junto ou separado
  • Descobre sozinho a documentação e os artefatos que precisa abrir
  • Implementa código e testes, roda os checks do projeto ao final e marca cada tarefa como concluída

Sai

  • Código e testes no repositório
  • Documentação atualizada e spec fechada por decisão humana. A lista de tarefas registra o trabalho do agente; o fechamento registra a aprovação
  • Com a spec fechada, o ciclo reinicia na Especificação (próxima unidade) ou na Descoberta (novo domínio), agora sobre um código que já existe

Divergência descoberta agora entre documentação e código vira decisão escalada, nunca correção silenciosa.

Também no Clovis

Revisão de código

Revisa um Pull Request ou duas branches e você escolhe quais comentários publicar.

Abertura de Pull Request

Escreve título e descrição a partir das mudanças e só publica com a sua aprovação.

Como ele se encaixa

Não é mais uma IA para contratar. É o método que garante o resultado da que você já tem.

  • Você decide

    Regra de negócio, o que fazer com um erro antigo do sistema, o que entra e o que fica de fora.

  • O Clovis organiza

    Divide o trabalho em etapas, dá a cada agente só o que ele precisa e define onde parar para perguntar.

  • A IA do seu time executa

    O agente de código que o seu time já usa continua lendo o sistema, escrevendo a documentação e o código.

  • O seu repositório guarda

    Requisitos, decisões e documentação ficam em arquivo, junto do código. Se um dia você parar de usar o Clovis, tudo fica com a sua empresa.

Gestão e governança

Clovis Cockpit: a governança cumprida em tempo real.

Agentes de IA só funcionam em escala quando alguém enxerga o que eles estão fazendo. No Cockpit, cada sessão, cada decisão e cada token consumido fica visível, rastreável e sob o comando do seu time.

Dashboard do Clovis Cockpit com indicadores de consumo, sessões, specs, tarefas, code reviews, taxa de aceite e pull requests, e o consumo por organização, projeto e etapa.
Consumo, entrega e qualidade lado a lado
Por agente, modelo, projeto e etapa
Quem já usa

Clientes com nome, resultados com número.

Saneamento · migração de portal

BRK

4xmais rápido que o método tradicional, com 60% do custo

A BRK chegava a uma nova cidade e precisava migrar um portal em produção, num serviço do qual 16 milhões de pessoas dependem. A migração começou com um técnico especialista apoiado pelo Clovis, e entregou:

  • O portal migrado em 1 mês com 3 pessoas, onde o método tradicional pedia 4 meses com 5
  • A mesma qualidade e segurança esperadas de um serviço essencial
  • A primeira entrega de engenharia agêntica num portal real da BRK
Ler o case completo

Seguros · assistente de IA para corretores

MAG

1 semanano lugar de 7 a 10 semanas, a estimativa sem IA

O corretor conversaria com um assistente para receber recomendação de produtos, simular valores e acompanhar carteira e comissões. Em uma semana, uma pessoa sênior entregou:

  • Um protótipo ligado aos serviços reais, que confirmou a viabilidade
  • Três caminhos de arquitetura avaliados, com o porquê da escolha
  • A documentação dividida por frente, para o time desenvolver em paralelo

Programa de cashback para lojistas

Votorantim

Mais certeiraa análise de impacto, segundo o nosso time no projeto

Ao especificar um ajuste no programa, o Clovis mapeou os fluxos afetados, inclusive os que a análise inicial não tinha considerado, e levantou as perguntas a responder antes do código.

Cooperativa de crédito

CrediSis

9xmais entregas do time, de julho a outubro de 2026

11jul
23ago
67set
98out

Entregas por mês desde a chegada do Clovis. A média por pessoa subiu de 7,5 para 27,6.

Mais dois projetos, abertos por dentro
Case ACerca de 1 mês de uma dupla pelo caminho convencional.

Modernização de legado

Um sistema em SilverStream, com o código-fonte guardado dentro do banco de dados, reescrito em monorepo TypeScript.

3

dias de trabalho

4

domínios entregues

21

tarefas concluídas

4

decisões escaladas

O ponto de partida

  • Backend Java e frontend HTML armazenados como registros em tabelas do banco. Não havia repositório para clonar nem arquivo para abrir.
  • O modelo de dados de negócio vive em um banco com 4 schemas; o código legado, em outro.
  • Restrições declaradas: schema preservado, fluxo de telas compatível com o legado e cobertura de testes acima de 95%.

O alvoMonorepo TypeScript: Node/Express com SQL Server e Clean Architecture, frontend React/Vite com Tailwind.

O diferencial do trabalho

  • Leu as classes Java e as páginas HTML de dentro das tabelas do banco e reconstruiu os dois fluxos de tela, ligando cada tela às views e tabelas que ela consulta.
  • Documentou cada domínio antes de implementar: schema, validações campo a campo, mensagens e casos de borda. Com as técnicas, o repositório fecha com 33 skills.
  • 42 arquivos de teste, cerca de 1 para cada 6 de código, escritos junto e não depois.
  • 70 documentos versionados, cerca de 13,7 mil linhas.

A decisão que subiu para o humano

A anomalia que não foi copiada nem corrigida em silêncio

Ao documentar, o agente achou um defeito do legado: salvar uma resposta de múltipla escolha apagava as respostas de todos os egressos para aquela pergunta e reinseria só as de quem estava respondendo. Ele não reproduziu por imitação nem consertou por conta própria. Escalou, virou três caminhos e uma espera. A decisão humana foi escopar a exclusão a quem responde, e a documentação guarda o contraste com o legado para que ninguém o recopie.

Sem governança: O agente teria replicado o defeito por imitação, ou o corrigido em silêncio, sem ninguém saber. A regra de negócio continuaria só na cabeça de quem leu o código.

Case BCerca de 3 semanas de uma dupla pelo caminho convencional.

O schema como requisito

Um schema de banco de dados como única fonte de requisitos, virando backend e frontend completos.

2

dias de trabalho

3

domínios entregues

24

tarefas concluídas

7

decisões escaladas

O ponto de partida

  • Um único schema com 4 tabelas: compromissos de doação, seus tipos, estados e status.
  • Nenhum documento de requisito, história de usuário ou tela de referência. O comportamento esperado só existia implícito nas colunas e nas constraints.
  • Do lado do código, apenas o esqueleto das duas stacks: nada de domínio, autenticação ou regra de negócio.

O alvoBackend .NET 10 com EF Core e SQL Server em clean architecture, frontend Angular 22 com Angular Material.

O diferencial do trabalho

  • Buscou evidência nos arquivos de configuração para sustentar o que afirmava sobre stack, comandos e estrutura, em vez de supor pelo nome das pastas.
  • Deixou as ambiguidades marcadas como pendentes até a resposta humana, em vez de resolvê-las por conta própria.
  • Cada spec declara o que já existe e o que falta; cada cenário de teste sai com identificador próprio e resultado esperado explícito.
  • 66 arquivos de teste e 98 cenários amarrados às tarefas que os originaram, e 116 documentos versionados.

A decisão que subiu para o humano

A entidade que o schema não previa

Cada compromisso de doação apontava para a pessoa que doou, mas essa tabela não existia no schema. O agente não inventou a entidade nem ignorou a referência: escalou. A decisão humana foi criá-la com a chave estrangeira, o que acrescentou um domínio inteiro ao projeto. Outras lacunas seguiram o mesmo caminho: se o valor mínimo da categoria orienta ou barra, o que o sistema faz com a marca de recorrência, e como guardar as senhas.

Sem governança: Quatro lacunas do schema receberiam quatro respostas plausíveis e desencontradas entre si. A entidade que faltava seria inventada ou ignorada, e a escolha de uma dependência central seria feita por inércia.

A velocidade que apareceu e o custo que baixou.

  • Case BRK4 meses com 5 pessoas1 mês com 3 pessoas
  • Case MAG7 a 10 semanas (estimativa sem IA)1 semana de 1 pessoa
  • Case A~1 mês de uma dupla3 dias de trabalho de 1 pessoa
  • Case B~3 semanas de uma dupla2 dias de trabalho de 1 pessoa

A governança que se fortaleceu.

  • 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
Como começar

Use o Clovis com o nosso time ou direto no seu.

Consultoria SDLC Agêntico

Com o nosso time

Engenheiros sênior montam o método com o seu time num projeto real, usando o Clovis. No fim, o método fica com vocês.

Conhecer a consultoria

Clovis Agentic

No seu time

O seu time usa o Clovis com a IA que já tem. Comece com uma sessão ao vivo no seu próprio código.

O Clovis nasceu nos nossos projetos de consultoria. É a mesma ferramenta que o nosso time usa no dia a dia para clientes.

Perguntas frequentes

O que costumam perguntar

Preciso contratar a consultoria para usar o Clovis?

Não. Dá para usar o Clovis direto no seu time, com a IA que vocês já têm. Se quiser ajuda para montar o método junto com o seu time, a Consultoria SDLC Agêntico faz isso num projeto real, usando o Clovis.

O Clovis substitui a IA que o meu time já usa?

Não. Ele trabalha com o agente de código que o seu time já usa, como Copilot, Cursor ou Claude Code. O Clovis organiza o trabalho, decide o que cada agente vê e define onde você entra. Por isso não é preciso aprovar mais uma assinatura de IA.

Quem não programa consegue usar?

Sim, na Descoberta. Ela foi feita para quem conhece o negócio: você descreve a necessidade com as suas palavras, responde perguntas curtas e recebe um documento de requisitos pronto para o time. Pode publicar direto no Confluence, no Jira ou no Azure DevOps.

Quanta supervisão isso exige do time?

A supervisão acontece onde a decisão é sua, não a cada linha de código. Análise, documentação e código chegam prontos para revisão. Em três projetos foram 39 perguntas levadas a uma pessoa, e nenhuma atrasou a entrega.

Onde fica o que ele produz? E se a gente parar de usar?

Fica no seu repositório, em arquivos de texto junto do código: requisitos, documentação de cada área do sistema, planos, testes e o registro das decisões. Passa por revisão como qualquer mudança. Se vocês pararem de usar o Clovis, tudo continua lá e vale para o próximo desenvolvedor.

Funciona em sistema antigo, sem documentação?

É o caso mais comum. Em um dos projetos o código estava guardado dentro do banco de dados, sem repositório para abrir. O Clovis investigou, documentou o que o sistema fazia e trouxe para decisão humana tudo que não dava para afirmar com certeza.

Ver o produto

Veja o Clovis rodando no seu próprio código.

Um engenheiro do nosso time roda o Clovis com você, ao vivo, num projeto seu. Você vê as primeiras perguntas chegando para quem decide. Sem slide.

O próximo passo

Trinta minutos com quem constrói. O horário é você quem escolhe.

Você já viu o que a Descoberta produz. Daqui para a frente é só logística: a agenda é pública, o horário é seu, e do outro lado senta engenheiro.

  • Traga o repositório, ou só o problema. Os dois servem.
  • Do outro lado tem engenheiro, não roteiro de vendas.
  • Se não fizer sentido para você, a gente diz na hora.
CMMI DEV/3ISO/IEC 27001ISO/IEC 27701

Escolha um horário

Trinta minutos na agenda do nosso time de engenharia. Você recebe o convite com o link da chamada na hora.

  • 30 minutos. Direto ao ponto, sem apresentação de slides.
  • Pauta sua. Legado, arquitetura, governança de IA, o que estiver travando.
  • Com quem constrói. Quem conversa com você é quem assina o gate no seu projeto.

Agenda pública · sem formulário

CMMI DEV/3ISO/IEC 27001ISO/IEC 27701