Como a BIA registra checks antes de publicar
(e o que isso não prova)

O problema: código gerado não é sistema entregue

Quem já pediu para uma IA gerar qualquer coisa conhece a sensação: o resultado parece ótimo. O texto é fluente, a tela é bonita, o código tem cara de código. E aí você usa — e a terceira tela não abre, o cadastro não salva, o total não soma.

Isso não é um defeito passageiro; é da natureza da geração. IA produz o provável, não o garantido. Para software, a resposta responsável é declarar critérios observáveis, executar checks e preservar o resultado — sem transformar uma amostra verde em garantia universal.

A regra da casa é uma frase: geração cria um candidato; checks declarados criam evidência sobre aquele candidato.

O ciclo: gerar → compilar → publicar → exercitar → corrigir

Quando a BIA termina de gerar um candidato, começa a coleta de evidência. O ciclo abaixo descreve classes de checks; o comprovante da entrega registra quais delas realmente foram executadas, sem presumir cobertura que não existe.

Portão 1: compilar sem erros

O candidato da BIA é compilado a partir de uma especificação estruturada. O compilador detecta inconsistências cobertas pela linguagem, como referências a campos ausentes ou tipos incompatíveis. Um compile verde é necessário, mas isoladamente não prova que o app inicializa ou que um fluxo de negócio está correto.

Portão 2: subir e ficar de pé

Compilar prova uma classe de consistência, não execução. O check de inicialização observa se o candidato publicado sobe e responde no momento testado. Esse resultado não é uma promessa de disponibilidade futura; é uma evidência datada ligada à entrega.

Portão 3: os smokes declarados precisam responder

Com o candidato no ar, a BIA executa os smokes declarados para aquela entrega: métodos, rotas e respostas selecionadas ficam associados ao resultado. Isso comprova aqueles checks, não todos os caminhos possíveis do produto. Regras de negócio e experiência de uso ainda exigem homologação do builder.

exemplo ilustrativo · rodada 1
──────────────────────────────────────
compilação ................. ✓ sem erros
build do app ............... ✓ concluído
inicialização .............. ✓ observada
GET /health ................. ✓ respondeu
POST /solicitacoes .......... ✗ falhou → erro capturado
──────────────────────────────────────
→ candidato bloqueado
→ ajuste alimenta uma nova rodada

exemplo ilustrativo · rodada 2
──────────────────────────────────────
POST /solicitacoes .......... ✓ respondeu
resultado .................. ✓ checks declarados registrados
limite ..................... homologação ainda necessária

Quando algo falha: correção com o erro real

A parte mais valiosa do ciclo não é o teste que passa — é o que acontece quando ele falha. A BIA captura o erro real: a mensagem exata da falha, no ponto exato onde ocorreu. Não uma suposição do tipo "deve ser tal coisa" — a evidência.

Com o erro em mãos, uma nova rodada pode corrigir o ponto e reexecutar a política declarada. Como qualquer mudança invalida evidência anterior relevante, o novo candidato recebe um novo resultado. As rodadas têm limite: erro, timeout ou evidência ausente bloqueiam o candidato em vez de serem convertidos em sucesso.

Por que quase ninguém faz isso

Verificação custa mais do que apenas devolver arquivos. Há pelo menos três razões operacionais:

• Custa infraestrutura. Compilar, publicar e chamar o candidato consome recursos em cada rodada.
• Custa tempo. Checks adicionam trabalho entre a geração e o resultado apresentado ao builder.
• Exige registrar falha. Um ciclo verificável precisa preservar o vermelho, o timeout e a ausência de evidência — não apenas o caminho feliz.

A escolha da BIA é tornar esse custo observável. O builder vê o candidato, a política aplicada e o resultado disponível, em vez de inferir qualidade a partir de uma tela gerada.

O que isso significa para você, na prática

• O resultado tem denominador. O comprovante informa qual candidato passou por quais checks — e não esconde o que ficou fora do escopo.
• Mudança pede nova evidência. Alterou fonte ou configuração relevante? O receipt anterior fica desatualizado e um novo candidato precisa percorrer a política declarada.
• Depois de entregue, o sistema continua contando o que faz. A verificação termina; a observabilidade continua: registros ao vivo, rastreamento de cada requisição e painéis de erro e latência — na IDE, sem instalar nada. E se um erro aparecer em uso, ele vai dos registros direto para a IA corrigir, com um clique.
• Você tem um critério para comparar. Ao avaliar qualquer plataforma de geração, faça uma pergunta: "o que exatamente vocês verificam antes de me entregar — e o que acontece quando falha?". A qualidade da resposta vale mais que qualquer demo.