Ideia principal

Atualizar um artefato de produto sempre significou corrigir a versão anterior: você reabre a especificação escrita há dezoito meses, procura os parágrafos afetados pela última entrega e os reescreve. O documento herda então tudo o que não foi relido — comportamentos removidos desde então, telas que não existem mais, premissas desmentidas pelo desenvolvimento.

O outro caminho é jogar fora a versão anterior e regenerar o artefato a partir do repositório: a documentação de suporte depois de uma entrega, o changelog, a especificação funcional do estado atual. O documento deixa de carregar o acúmulo das suas versões e passa a carregar uma data de leitura do código.

O ganho não é a velocidade de escrita. É que o artefato deixa de ser um estoque que precisa de manutenção e vira uma projeção que a gente roda de novo. Uma projeção não diverge: ou está vencida, ou é refeita.

A regra vale dentro de um mesmo documento assim que ele mistura dois tipos de conteúdo. Numa ficha de objeto de produto, o corpo descreve a realidade como ela está no código: dá para jogá-lo fora e refazê-lo sem perder nada. Já as diferenças entre essa realidade e o que se gostaria vêm de uma decisão humana, não são encontradas em lugar nenhum se forem perdidas e, por isso, ficam num bloco separado que nenhuma regeneração toca. O que se regenera e o que se mantém só convivem se estiverem visivelmente separados.

Camada trazida por "Escrevi a ontologia de um produto. Três vezes achei que tinha terminado." (2026-08-11).

Camada trazida por "Quatro dias de vibe coding…" (2026-07-28). A inversão não diz respeito só à atualização de um documento existente: ela também afeta o momento em que o primeiro documento é escrito. Numa ferramenta interna construída diretamente por alguém de produto, não houve especificação prévia — a pessoa começou, construiu, mostrou, recebeu pedidos de evolução e foi iterando. O comportamento surgiu no produto, e a documentação funcional foi gerada depois, a partir do código. A sequência habitual se inverte então por completo: ninguém regenera um documento por não ter conseguido mantê-lo; ele é gerado porque nunca foi escrito antes.

Por que isso importa

É isso que torna a distância entre o produto e a sua documentação tratável sem disciplina. Enquanto a gente atualiza, a divergência se acumula a cada iteração pulada; a partir do momento em que a gente regenera, uma iteração pulada não deixa nenhuma dívida — a regeneração seguinte parte do mesmo lugar.

Isso também muda o que se arquiva: passa a ser mais útil guardar a capacidade de regenerar do que a última versão produzida.

Nuances e limites

O código não carrega a intenção. Uma especificação regenerada diz o que o produto faz, não por que aquele comportamento foi escolhido nem o que foi descartado — e essa perda é invisível, já que o documento parece completo.

A regeneração também não é de graça: ela exige uma revisão, e uma saída errada com cara de certa custa mais caro do que um documento claramente desatualizado.

Camada trazida por "Ontology-Driven Design: e se a ontologia virasse a rede de segurança do código gerado por IA?" (2026-10-29). Reconstruir a partir do código uma ontologia de negócio, em vez de uma especificação, traz um limite próprio: o resultado é uma interpretação estruturada do negócio a partir da sua implementação. Uma regra implícita pode escapar da extração, e um comportamento histórico — uma gambiarra, um resquício — pode ser lido, por engano, como uma regra intencional.

Questões em aberto

• Como perceber que uma regeneração apagou uma decisão humana, se ela entrega um documento perfeitamente bem formado?