Escrevi o método CERNE lendo seis especificações reais.

Em 7 de novembro, montei o manual do meu método para especificar produto com IA. Na mesma manhã, ele passou por quatro rodadas de revisão de outro modelo de IA. Cada rodada virou um commit de correção, e todas aconteceram antes do meio-dia.

Li seis especificações reais antes de escrever qualquer regra

Antes de escrever o método, li seis especificações reais. Li cada uma junto com o histórico do git, com os ADRs e com o código que saiu dela. ADR é o registro curto de uma decisão e do motivo dela.

A maior especificação tinha cerca de 325 mil palavras no primeiro commit e chegou a 347 mil palavras. As outras variavam bastante de tamanho, de uma especificação grande até a mais curta do grupo. Essa leitura mostrou o que continuou de pé depois da construção e o que precisou ser reescrito.

O manual usa exemplos ilustrativos de domínios variados, como um app de agendamento para barbearias, um emissor de faturas para freelancers e uma loja de assinatura de ração. Os exemplos mostram a forma do documento. Eles não dizem o que construir.

O tamanho aguentou e a repetição envelheceu

Uma especificação escrita por IA em um dia levou um agente a construir 18 módulos em cerca de 11 dias. Na contagem de 7 de novembro, 323 dos 356 IDs de requisito aparecem citados no código. Registro canônico, ID estável, aceite verificável, texto exato de tela e contrato de API foram peças que mais pagaram.

O que envelheceu foi a repetição. Um mesmo preço apareceu repetido em 106 lugares de 15 arquivos, e trechos diferentes passaram a dizer coisas diferentes sobre o mesmo fato. Na maior especificação, boa parte dos commits depois do lançamento serviu para recuperar a coerência entre trechos repetidos.

O outro problema foi a ordem de entrada no ar. Num dos casos, cerca de 710 requisitos eram obrigatórios antes do primeiro anúncio. Especificar tudo continua necessário, e cada parte precisa ter a marca de quando ela entra no ar.

As cinco etapas do CERNE organizam a escrita

O método se chama CERNE e tem cinco etapas. Caminho escreve a aposta de receita e a ordem em que o produto vai ao ar, com o que entra no lançamento, o que vem depois e o que o produto não faz. Esqueleto herdado marca o que a base já entrega e decide tudo o que o produto muda.

Registros escreve por completo, num lugar só, as decisões, as invariantes, as rotas, o catálogo, os eventos, o banco e os erros. Normas escreve cada fluxo por inteiro, com requisitos e aceite, estados, textos, contratos, IA e o lançamento. Evolução prova que não sobra dúvida e mantém o SRS verdadeiro enquanto o produto muda.

O SRS é completo e não tem limite de tamanho, de arquivos nem de requisitos. O tamanho é consequência do produto. Nenhuma regra de organização autoriza deixar algo sem especificar, e uma dúvida de quem implementa conta como defeito do SRS.

Invariantes e hipóteses mudam em ritmos diferentes

Todo requisito pertence a uma de duas camadas, e as duas são escritas por completo. Invariantes guardam o que nenhum número justifica quebrar, como linhas vermelhas de marketing, integridade de cobrança e de acesso, lei, privacidade e segurança. Um defeito numa invariante bloqueia o lançamento.

Hipóteses cobrem oferta, texto, funil, canal, cadência e limites de plano. Elas entram porque se espera que vendam, e mudam quando o dado mostra outro caminho. A mudança acontece no mesmo commit do código, com um ADR curto que registra o que foi visto.

Essa separação evita dois erros comuns. A regra que sustenta a confiança do produto fica protegida de uma oscilação de resultado. A oferta que precisa aprender com o uso continua livre para mudar, desde que a mudança fique registrada.

Um fato tem um dono e o teste do implementador fecha as lacunas

A regra que amarra o documento é simples de enunciar: um fato, um dono. Cada fato fica escrito uma vez, e os outros trechos apontam para ele. Antes do código, o dono é o SRS, e depois do código alguns fatos passam para o código, como mensagens da interface, schema do banco e arquivo do prompt.

A melhor verificação de completude disponível sem uma pessoa é o teste do implementador; ele não substitui a construção. Um agente novo, só com o SRS, lista as perguntas que mudariam o produto, e cada uma vira texto no documento. O teste roda em até três rodadas, sempre com um agente novo em cada rodada.

Os portões ajudam a achar lacunas e nunca param a entrega. O SRS sai ao fim das rodadas com o relatório do que foi achado e do que sobrou como decisão em aberto com valor padrão. Quem quer aplicar a mesma lógica na construção pode continuar por desenvolver com IA além do código.