Você deve corrigir seus asserts

Asserts não são 'comentários executáveis' nem ferramentas de depuração descartáveis: são contratos explícitos entre o programador e o compilador, e, por extensão, entre o código e sua própria lógica. Quando usados como precondições, invariantes ou pós-condições, eles formalizam o que o código *deve* manter em cada ponto crítico, alinhando-se com a metodologia Design by Contract, presente desde Eiffel e agora incorporada de forma nativa em Rust (assert!, debug_assert!, const_assert!) e C++11+ (static_assert). O estudo empírico da Microsoft mostra que projetos com densidade de asserts entre 2% e 3% do código têm menor taxa de falhas, não porque os asserts 'consertam' bugs, mas porque forçam os desenvolvedores a nomear e validar suposições implícitas antes que se tornem corrupção silenciosa de estado.

A desativação cega em produção, comum em C, Python e Java, é uma otimização prematura que troca visibilidade por falsa estabilidade. Um panic controlado ao violar um assert é tecnicamente mais seguro do que continuar executando sob premissas falsas: isso evita estados inconsistentes, vazamentos de memória não detectados (como em Go sem GC preciso) e até condições exploráveis por ataques à supply chain, já que código com invariáveis quebradas pode processar dependências maliciosas sem sinalizar erro. Em Rust, por exemplo, debug_assert! mantém a verificação em testes e CI, enquanto assert! permanece ativo em produção, uma divisão intencional entre otimização e correção, não entre 'desenvolvimento' e 'operação'.

A cobertura anterior de 2026-05-25 sobre migração de Go para Rust já destacava as garantias em tempo de compilação como vantagem central. Agora, com a nova orientação de 2026-06-01, fica claro que Rust não só move verificações para compile-time, mas também reconfigura o papel do assert em runtime: ele deixa de ser um artefato descartável e passa a ser um mecanismo de defesa ativa, integrado ao modelo de propriedade e ao sistema de tipos. Enquanto a matéria anterior tratava de migração como escolha técnica, esta atualiza o entendimento operacional, o assert em Rust não é 'mais seguro que em Go', mas 'funciona em outro nível de contrato': ele é parte do fluxo de controle, não um adendo opcional.

Para desenvolvedores que usam IA para gerar código, asserts bem colocados são a primeira linha de defesa contra alucinações: se um agente sugere uma função que viola um invariante conhecido (ex: 'retorna nil quando deveria retornar Result<T, E>'), um assert falhando no CI expõe o problema antes que vire débito técnico. Isso complementa diretamente a cobertura de 2026-06-03 sobre o novo débito técnico gerado por IA. Além disso, asserts consistentes melhoram a DX ao reduzir o tempo de diagnóstico de falhas em ambientes complexos, algo crítico em pipelines que já usam boas práticas de supply chain (como na matéria da AWS de 2026-06-02), onde confiança no comportamento interno do código é tão importante quanto a integridade das dependências externas.