virtdev

manutenção de software · agente autônomo

Mexer em código antigo sem apostar.

O virtdev entra no seu repositório, mapeia o que cada mudança alcança e grava o comportamento atual antes de tocar em qualquer linha. A entrega chega como patch mais a prova de que o resto continua igual.

Pedir um piloto 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.

Em sistema que ninguém escreveu ontem, a pergunta cara é sempre a mesma: 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 quais rotas dependem daquele módulo.
  • A suíte que existe não cobre o caminho que vai ser mexido.
  • O teste de verdade acaba acontecendo no cliente.

Quatro fases, na ordem em que acontecem.

  1. 1

    Onboard

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

  2. 2

    Compreender

    Monta o mapa: imports, referências cruzadas, entrypoints, tabelas e o que o histórico do git conta sobre cada arquivo.

  3. 3

    Blindar

    Grava o comportamento atual como golden master e mede o quanto essa rede pega de verdade.

  4. 4

    Operar

    Pega o card, entrega o patch com a evidência anexa e abre o PR. A revisão e o merge continuam seus.

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.

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.

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.

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

pilotos abertos

Tem um sistema que ninguém quer tocar?

É exatamente o caso. Estamos rodando os primeiros onboards e escolhendo poucos repositórios por vez.

Manda a stack, o tamanho aproximado do repositório e uma tarefa real que está parada.

Falar sobre um piloto