A maior parte do que se escreve sobre desenvolvimento com IA assume um cenário que quase nenhum decisor B2B vive: a folha em branco. Greenfield. Um repositório vazio onde a especificação nasce limpa e o código nasce dela. Mas o sistema que sustenta a sua operação não é uma folha em branco. É um módulo que roda há anos, que integra com um ERP que ninguém quer tocar, que tem uma regra de comportamento enterrada numa condição de três linhas — e que "funciona e ninguém mexe".
Essa regra invisível é exatamente onde a IA rápida quebra o sistema. Não porque o modelo seja ruim, mas porque a regra nunca foi explicitada em lugar nenhum. Ela vive no código, no hábito da equipe e na memória de quem estava lá quando a exceção foi criada. Quando você pede pra uma IA modernizar aquele módulo e ela nunca leu a regra — porque ninguém a escreveu —, o código gerado a viola em silêncio. E o retrabalho de descobrir o que quebrou, três semanas depois, custa mais caro do que a especificação caprichada teria custado no começo.
Principais pontos
- O contrato não documentado do legado é uma das maiores fontes de subespecificação, mais do que qualquer requisito novo mal escrito — porque a regra que nunca virou documento não pode ser verificada por ninguém, humano ou máquina.
- Spec retroativa do sistema inteiro é impraticável e cara; o caminho viável é a change-level spec — especificar só a área da mudança, com granularidade máxima perto de onde a IA vai tocar.
- Delta specs marcam explicitamente o que é ADDED, MODIFIED e REMOVED sobre o comportamento existente, pra o agente não alucinar requisito novo em cima do que já está lá.
- SDD como engenharia reversa manda a IA ler o módulo legado e propor um baseline do comportamento atual — uma hipótese a confrontar, não um veredito, e a refatoração depois tem que conformar ao que ficou validado.
- Baseline sem teste ainda é documentação: teste de caracterização congela o comportamento observável antes da mudança, pra qualquer divergência fora do delta virar sinal de regressão.
- O limite honesto continua humano: a IA traduz spec em código, mas garantir que a spec captura o requisito real é responsabilidade de quem conhece o negócio.
Pra empresas com sistemas em produção, a pergunta raramente é "IA acelera desenvolvimento?" — acelera. A pergunta é "como deixo a IA tocar no legado sem que ela quebre a regra que ninguém escreveu?". É nesse tipo de disciplina — mapear o que já existe antes de mudar — que parceiros como a Vertis Tech entram em consideração, porque integrar com sistema legado sem reescrever é uma das frentes onde a casa opera há tempo.
Por que o brownfield é um problema diferente
Boa parte das abordagens recentes de spec-driven development (SDD) — a prática de tratar a especificação como fonte de verdade que humanos e agentes de IA seguem — foi desenhada com projetos novos em mente. Você escreve a spec, a IA gera o código, e como não havia nada antes, a spec é a única realidade. Em brownfield, existe uma segunda realidade que ninguém escreveu: o sistema atual.
E essa segunda realidade é traiçoeira. Um módulo de faturamento que arredonda de um jeito específico por causa de uma exigência fiscal de 2019. Uma integração que espera o campo status chegar em maiúsculo porque o sistema do outro lado nunca padronizou. Uma fila que reprocessa em silêncio quando o webhook falha, e a operação inteira depende desse comportamento sem saber que ele existe. Nenhuma dessas regras está num documento. Todas estão no código — e nenhuma IA vai adivinhar a intenção por trás delas só olhando o if.
Frameworks de SDD começaram a levar isso a sério. O OpenSpec, projeto open source da Fission-AI que chegou à versão 1.0 em janeiro de 2026, assume explicitamente uma filosofia brownfield-first: trabalhar sobre sistemas existentes sem exigir que toda a base seja especificada antes da primeira mudança (documentação oficial do OpenSpec). É uma inversão importante de premissa. O problema deixou de ser "como escrever a spec perfeita" e passou a ser "como especificar uma mudança sem ter que descrever o universo inteiro que já existe".
Change-level spec: especifique a mudança, não o sistema
A primeira tentação de quem descobre SDD e tem legado é a pior: parar tudo e documentar o sistema inteiro antes de mexer. É uma armadilha. Sistemas grandes têm anos de comportamento acumulado, e uma spec retroativa completa costuma ser cara, demorada e desatualizada no dia em que fica pronta. Ninguém termina esse projeto.
O caminho praticável é o oposto: change-level spec. Você especifica só a área que vai mudar. Se a alteração é no cálculo de comissão, a spec cobre o cálculo de comissão e suas fronteiras diretas — as entradas que ele recebe, as saídas que outros módulos esperam dele — e não o CRM inteiro. A regra prática é que a granularidade tem que ser máxima perto de onde a IA vai tocar e pode ser grossa longe dali. Quanto mais perto do bisturi, mais detalhe; quanto mais longe, mais é suficiente saber que existe um contrato a respeitar.
Isso resolve o problema econômico da spec retroativa. Você não paga pra documentar o que não vai mudar. Paga pra documentar com precisão cirúrgica o que vai — que é justamente onde o risco mora.
Delta specs: o vocabulário do que muda
Aqui entra o mecanismo que torna o brownfield gerenciável: a delta spec. Em vez de reescrever a especificação inteira de um módulo a cada mudança, você descreve apenas o que está mudando em relação ao que já existe. O OpenSpec adota esse modo "delta" como conceito central, e a documentação oficial é direta ao dizer que é isso que faz o framework funcionar em código existente: descrever a mudança, não reafirmar a spec toda (guia do OpenSpec).
Na prática, a delta spec usa marcadores explícitos — o guia oficial trabalha com ADDED, MODIFIED e REMOVED. Cada requisito da mudança é etiquetado: isto é comportamento novo, isto altera um comportamento que já existia, isto remove uma regra antiga. Parece burocracia até você entender o que esses marcadores evitam.
O agente de IA, quando lê uma spec sem marcação de delta sobre um sistema que já existe, tende a tratar tudo como novo. Ele "alucina" requisitos — inventa que um comportamento é uma criação sua quando na verdade ele já estava lá, com uma razão de ser. Ou pior: sobrescreve uma regra existente achando que está implementando algo do zero. Os marcadores de delta são uma cerca. Eles dizem ao agente, de forma inequívoca, o que é território novo e o que é território que ele precisa respeitar. É a diferença entre "construa isto" e "mude isto, sem tocar naquilo".
O núcleo do fluxo passa por explorar o contexto, propor a mudança, aplicar, sincronizar a especificação e arquivar o resultado. Assim, cada delta deixa um registro versionado do que mudou e por quê. Pra quem opera sistema em produção, essa auditabilidade não é detalhe: é o que permite entender, meses depois, qual mudança introduziu qual comportamento.
SDD como engenharia reversa: gerando o baseline
As delta specs resolvem como descrever a mudança. Falta resolver o problema anterior: como você sabe qual é o comportamento atual, se ele nunca foi escrito? A resposta mais interessante que emergiu na prática é usar a própria IA como ferramenta de engenharia reversa.
O movimento é este: antes de mudar qualquer coisa, a IA pode ajudar a extrair um baseline inicial do comportamento atual, lendo o módulo, seus testes, contratos, configurações e dependências. Esse documento vira o baseline: uma descrição estruturada do que o sistema aparenta fazer hoje, incluindo as regras esquisitas que ninguém lembrava de ter escrito. Mas o baseline não é a verdade do sistema — é uma hipótese que precisa ser confrontada com logs, dados reais e com quem conhece a operação. Só ler o código não revela necessariamente o comportamento real: a regra que importa pode depender de configuração de produção, de um trigger no banco, de dados históricos, de um contrato informal com outro sistema, de uma feature flag, de uma rotina agendada ou de um comportamento emergente que só aparece nos logs. Por isso vale o princípio: em brownfield, baseline confiável não nasce só da leitura do código — nasce da triangulação entre código, testes, telemetria e conhecimento operacional.
O ganho vem no passo seguinte. Uma vez que você tem o baseline validado, a refatoração tem uma âncora: o código novo tem que conformar ao baseline naquilo que não era pra mudar. Você deixa de refatorar no escuro. Em vez de "espero que eu não tenha quebrado nada", você tem um contrato explícito de consistência comportamental — o que o sistema fazia antes, ele continua fazendo, exceto exatamente nos pontos que o delta marcou como MODIFIED ou REMOVED. A regra invisível vira visível antes de virar risco.
Há uma sutileza que precisa ser dita com honestidade: o baseline gerado por IA é um ponto de partida, não um veredito. A IA descreve o que o código faz. Ela não sabe se o que o código faz é o que o negócio precisa — às vezes o comportamento atual é o próprio bug que alguém aprendeu a conviver. Por isso o baseline exige revisão de quem conhece o negócio. É aí que se separa "isto é uma regra que existe por um motivo" de "isto é uma gambiarra que a gente vai aproveitar pra consertar".
Baseline sem teste ainda é documentação
Uma spec retroativa descreve o comportamento; um teste de caracterização ajuda a congelá-lo. Testes de caracterização — também chamados, conforme o caso, de golden master ou snapshot comportamental — capturam o que o sistema faz hoje antes de qualquer mudança. Antes da refatoração, o time registra as entradas e saídas relevantes do módulo, os contratos de API, os efeitos colaterais e os casos de borda conhecidos. Depois da mudança, qualquer divergência fora dos deltas declarados vira sinal de regressão.
O objetivo não é eternizar todo comportamento legado — inclusive os bugs. É tornar a diferença visível, para que alguém decida conscientemente o que preservar, corrigir ou remover. É isso que fecha o ciclo: o baseline descreve o comportamento, a delta spec marca o que muda, o teste de caracterização congela o que não deveria mudar, e a revisão humana decide o que fazer com cada divergência.
Contexto antes da spec
Amarrando tudo, existe um princípio que virou consenso silencioso na prática de SDD em brownfield: contexto antes da spec. Antes de escrever qualquer requisito, você educa a IA sobre o sistema real — a arquitetura, as integrações, as convenções, os pontos sensíveis. A ordem importa. Se você escreve a spec primeiro e só depois dá contexto, os artefatos já nasceram contaminados por suposição. Se você dá contexto primeiro, a spec reflete o que existe.
Isso conecta com uma verdade mais ampla sobre desenvolvimento com IA que já tratamos em outros textos: o modelo não programa melhor porque recebeu um prompt maior. Ele programa melhor quando recebe contexto estruturado, requisitos claros e limites definidos. Em greenfield, esse contexto você inventa. Em brownfield, ele já existe — enterrado no legado — e o trabalho é extraí-lo antes, não presumi-lo depois.
Como a Vertis Tech ajuda em modernização de legado com IA
A Vertis Tech desenvolve software sob medida com foco em CRM, automação e IA aplicada. Cada projeto é dimensionado conforme a complexidade do sistema existente, as integrações em jogo, a sensibilidade dos dados e a maturidade operacional do cliente. Quando o escopo envolve mexer em algo que já roda em produção, a implantação pode contemplar:
- Discovery técnico orientado a outcome, pra mapear o comportamento real do sistema antes de comprometer qualquer linha de código — a mesma disciplina de triangular código, testes e telemetria que este texto defende.
- Integração com sistemas legados sem reescrever o que já funciona, tratando o contrato existente como algo a respeitar, não a atropelar.
- Experiência da liderança técnica com integração de legado, incluindo ambientes bancários com COBOL/CICS e aplicações .NET via webservices — repertório que ajuda a tratar comportamento antigo como contrato a investigar, não como obstáculo a apagar.
- Aprovação humana em pontos críticos, porque baseline gerado por IA e refatoração sobre legado são exatamente o tipo de decisão que não deve rodar sem revisão de quem conhece o negócio.
- Auditoria append-only das mudanças, pra que cada alteração fique rastreável — qual delta introduziu qual comportamento, e quando.
Perguntas frequentes
Preciso documentar meu sistema inteiro antes de usar IA pra modernizá-lo?
Não, e tentar isso costuma travar o projeto. O caminho praticável é a change-level spec: especificar com detalhe só a área que vai mudar e suas fronteiras diretas, e deixar o resto do sistema como contexto de fundo. Spec retroativa completa é cara e desatualiza rápido.
O que exatamente são delta specs e por que eles importam em legado?
Delta specs descrevem só o que está mudando em relação ao comportamento existente, usando marcadores como ADDED, MODIFIED e REMOVED. Importam porque impedem o agente de IA de tratar comportamento antigo como se fosse novo — o que evita que ele sobrescreva em silêncio uma regra que existia por um motivo.
Dá pra confiar numa spec do comportamento atual gerada por IA?
Como ponto de partida, sim; como veredito final, não. A IA pode ajudar a descrever o que o código aparenta fazer, mas não captura sozinha configurações, dados históricos, integrações e comportamentos observados apenas em produção — e não sabe se o comportamento atual é o que o negócio precisa. Por isso o baseline precisa ser confrontado com logs, testes de caracterização e a revisão de quem conhece a operação.
A IA não deveria simplesmente "entender" meu código sem tanta cerimônia?
Ela entende a sintaxe. O que ela não adivinha é a intenção por trás de regras que nunca foram explicitadas — a exceção fiscal, a integração que espera um formato específico, o reprocessamento silencioso. Essas regras vivem no código sem estarem documentadas, e é justamente onde a geração rápida sem baseline costuma quebrar o sistema.
Isso vale pra qualquer stack ou só pra projetos novos?
Vale especialmente pra quem tem sistema em produção. A disciplina de gerar baseline, marcar deltas, congelar comportamento com teste de caracterização e dar contexto antes da spec foi pensada para brownfield — o cenário da maioria dos decisores, que não parte de folha em branco.
Modernizar legado com IA não é sobre ter o modelo mais rápido. É sobre não deixar a velocidade atropelar a regra que ninguém documentou. O sistema que "funciona e ninguém mexe" funciona por razões — algumas boas, outras herdadas — e a única forma de mudá-lo com segurança é tornar essas razões visíveis antes de tocar nelas. Delta specs, baseline por engenharia reversa, testes de caracterização e contexto antes da spec são as ferramentas que transformam a regra invisível em contrato explícito. O resto é revisão humana, que continua insubstituível.
