agentes de ia · software em produção

Seu agente sabe escrever código. Mas conhece o seu sistema?

Uma mudança pode afetar partes da aplicação que o agente nunca viu. E, sem bons testes, ninguém sabe se algo quebrou. O VirtDev mapeia o alcance, cria a proteção e entrega cada mudança com evidência.

Entrar na lista Como funciona

Leitura de impacto exemplo

diff   src/billing/invoice-service.ts   +18 −4
alcance reverso
  rota     POST /v1/invoices              alta
  rota     GET  /v1/invoices/:id/pdf      alta
  fila     invoice.issued                 média
  tabela   invoices · invoice_items
escopo      ampliado
regressão   41 casos · 0 divergências

Toda mudança começa por esta leitura. É ela que decide o que a regressão precisa cobrir.

O risco não é escrever a mudança. É não saber o que ela encosta.

Vale para qualquer aplicação que já está em produção, não só para a antiga: um serviço de dois anos, grande e pouco documentado, tem exatamente a mesma pergunta cara. Se eu mexer aqui, o que para de funcionar. Sem essa resposta, ou o time congela o sistema, ou descobre o alcance em produção.

Ninguém sabe o que mais depende daquele trecho de código.
“Os testes passaram” só prova que nada do que já era vigiado mudou.
O teste de verdade acaba acontecendo no cliente.

não tem teste: É o caso comum, não o impedimento: a regressão nasce do comportamento que a aplicação tem hoje. Se já existe suíte, ela é aproveitada e medida junto.
stack: O primeiro onboard roda em TypeScript e Node. Python e JVM usam o mesmo ferramental. Fora disso, a conversa começa por uma leitura do repositório.
encaixe: Serviço com banco relacional e bordas conhecidas. Idade do código não é o critério: o que pesa é o quanto ninguém sabe o que a mudança alcança.

Probabilístico para criar. Determinístico para entender e verificar.

O agente é probabilístico, e é isso que o faz bom em interpretar um pedido e escrever a mudança. Já descobrir o que depende do quê, medir o alcance de um diff e comparar comportamento antes e depois são problemas que ferramentas determinísticas de engenharia resolvem há décadas: compilador, indexador, grafo, histórico do Git e execução de verdade. E o agente pode mudar: o mapa, a proteção e a evidência continuam sendo do VirtDev.

O agente escreve. O VirtDev calcula o impacto e verifica o resultado.

menos loops
menos tokens
mais evidência

Não se pede ao modelo que adivinhe o que uma ferramenta consegue medir.

Quatro fases, na ordem em que acontecem.

1 · prepara
Onboard

Clona o repositório e levanta um ambiente isolado, com dados que não precisam ser os seus.
2 · mapeia
Compreender

Monta o mapa de como a aplicação está ligada por dentro: o que depende do quê, por onde entram as requisições, que tabelas cada parte toca e o que o histórico conta sobre cada arquivo.
3 · protege
Blindar

Grava como os fluxos se comportam hoje e mede quanto dessa rede realmente pega uma mudança. Onde não existe proteção, ela é criada.
4 · altera e verifica
Operar

Pega o card na ferramenta que você já usa, entrega o patch com a evidência anexa e abre o PR. A revisão e o merge continuam seus.

Duas vezes, ele para e espera você.

antes de escrever

O agente devolve o que entendeu: a tarefa reformulada, os critérios de aceite verificáveis por execução e o que ficou de fora. Enquanto houver pergunta em aberto, ele não escreve nenhuma linha.

antes de entregar

Ele devolve o patch com a evidência medida e espera de novo. É a sua aprovação que dispara a entrega, e o que é entregue é exatamente o que você revisou.

Entre um portão e outro, ele trabalha sozinho.

Tudo acontece no card da ferramenta de gestão que você já usa. Quatro pontos de contato, nenhuma ferramenta nova para aprender.
Se ele empacar, o card volta para você com o estado preservado. Agente que entendeu errado não é repetido no automático: tentativa cega só queima dinheiro.

O patch é metade. A outra metade é a prova.

Cada entrega chega com o que foi verificado, como foi verificado e o que mudou no mapa do sistema. Sem isso, revisar o trabalho de um agente é acreditar nele.

um agente sozinho: com o VirtDev
“os testes passaram”: Quais comportamentos foram verificados, um a um.
depende da suíte que já existir: Cria a proteção onde ela não existe, e mede a força dela.
contexto refeito a cada tarefa: Mapa da aplicação que persiste, e que se atualiza a cada commit.
gasta token redescobrindo o que já foi calculado: Consulta o mapa pronto, e o token fica para o julgamento.
você confia no agente: Você inspeciona a evidência.

o comportamento de hoje vira a referência

Em vez de escrever à mão o resultado esperado, captura-se o que a aplicação já faz, e isso passa a valer como contrato. Depois da mudança, tudo roda de novo e é comparado. É o que permite proteger um sistema sem conhecer nenhuma regra de negócio e sem depender de documentação que talvez não exista. A técnica tem nome de mercado: characterization testing, também chamada golden master.

a rede é medida, não presumida

Mudanças de comportamento são injetadas no código, uma por vez, e conta-se quantas a proteção percebe. O que passa despercebido mostra onde a rede ainda tem furo, com número em vez de opinião. Cobertura diz que a linha executou, não que alguém repara se ela mudar. Essa técnica se chama teste de mutação.

patch: Diff aplicável. Nada entra no seu main sem revisão humana.
verify: As capturas do golden master rodadas de novo contra a imagem candidata.
delta: O que mudou na estrutura: rota nova, tabela tocada, entrypoint criado.
escopo: Quais testes o impacto selecionou, e por que os outros ficaram de fora.
custo: Tempo e consumo do trabalho, por card.

Todo relatório diz também o que ele não cobre.

Entrypoint que ficou de fora, com o motivo pelo qual ficou.
Caso que rodou com valor sintético em vez de registro real.
Campo que a verificação ignora de propósito, por ser volátil.
Em que ambiente aquela referência foi capturada, porque isso é o teto da confiança dela.

Cobertura alta lida como segurança alta é como se perde um sistema.

Você decide até onde abrir.

A conversa sobre acesso costuma travar antes da técnica. Por isso o onboard tem três degraus, e o primeiro já é suficiente para começar.

nível 1

Só leitura

Uma deploy key de leitura no repositório. O agente lê o código e mais nada.

nível 2

Ambiente sintético

Banco e cenário gerados a partir do seu próprio schema. Nenhum dado real sai da sua casa.

nível 3

Cópia anonimizada

Snapshot anonimizado ou staging, quando a fidelidade do dado muda o resultado.

não custódia: Dado seu não fica com a gente. A base de testes é provisionada na sua infra, e o mascaramento acontece lá dentro: o que atravessa a fronteira já saiu sem informação pessoal.
sem credencial: O ambiente que executa o seu código nasce sem identidade e sem segredo, e só alcança a internet pela lista do que foi autorizado. Não há token ali para vazar.
quem decide: O agente não faz merge sozinho, em nenhum degrau. A última palavra sobre o que entra no seu código é sempre de uma pessoa.

Produção nunca é palco de teste. Em nenhum degrau.

lista de espera · primeiros pilotos

Tem um sistema que ninguém quer tocar?

É exatamente o caso. Estamos rodando os primeiros onboards e escolhendo poucos repositórios por vez. A lista define a ordem.

o que você faz: Uma conversa sobre o ambiente e uma base de testes provisionada do seu lado. O acesso começa em leitura.
o que você recebe: O mapa de impacto do repositório, a regressão gerada com o número que mede a força dela, e uma tarefa real entregue como patch com evidência.
em que ordem: Primeiro o ambiente de pé, depois o mapa, depois a blindagem. Só então a primeira tarefa. Cada etapa termina em algo que você consegue conferir sozinho.