Explorando desenvolvimento AI-first, guardrails de código e a arquitetura da descartabilidade.
A maioria dos times corrige defeitos e segue em frente. Os mesmos defeitos voltam. Aqui está como executar análise causal dentro de uma inspeção Fagan para parar de escrever o mesmo bug duas vezes.
Todo time tem aquele defeito que não para de voltar. Um off-by-one na paginação. Uma verificação de nulo faltante no middleware de autenticação. Uma race…
Múltiplos estudos na IBM, AT&T, HP e Microsoft confirmam que a revisão informal de código captura aproximadamente um quarto dos defeitos. Aqui está o que os dados realmente dizem, por que o número é tão baixo e como corrigi-lo.
A revisão informal de código captura entre 15 e 30 por cento dos defeitos presentes no código sendo revisado. Isso não é uma opinião. É uma constatação que foi…
A maioria dos checklists de revisão são listas copiadas e coladas de boas intenções. Um checklist estruturado no estilo Fagan inspection é construído a partir de dados reais de defeitos, direcionado a tipos específicos de artefatos e usado durante a preparação individual. Veja como construir um que funcione.
Se sua equipe tem um checklist para code review, há uma boa chance de que ele viva em uma página wiki que ninguém abre. Ele provavelmente diz coisas como…
Inspeções Fagan precisam de quatro a seis pessoas e duas horas para revisar 250 linhas. Um LLM pode cortar esse custo ao cuidar da preparação e da aplicação de checklist, mas não pode substituir os papéis humanos que encontram os defeitos mais caros.
Uma inspeção Fagan completa precisa de um moderador, um leitor, dois a quatro inspetores e o autor. A equipe gasta duas horas revisando aproximadamente 250…
O processo de revisão estruturado de Michael Fagan na IBM capturava quase todos os defeitos antes que chegassem ao compiler. Também consumia 15-20% do esforço total do projeto. Veja por que o método de revisão mais eficaz da história do software desapareceu, e o que as equipes realmente perdem.
Em 1976, Michael Fagan publicou um artigo no IBM Systems Journal descrevendo um processo de revisão tão eficaz que se tornou o padrão ouro para qualidade de…
Mesmo engenheiros sênior detectam apenas uma fração dos defeitos em revisões não estruturadas. A pesquisa de Michael Fagan na IBM mostrou por quê, e construiu um processo de inspeção estruturado para corrigir isso.
Dois engenheiros sênior revisam o mesmo pull request. Um sinaliza um null check faltante. O outro detecta uma race condition no cleanup path. Nenhum dos dois…
A revisão de código informal encontra 15-30% dos defeitos. As Fagan inspections, um processo estruturado com 50 anos, relatam consistentemente taxas de remoção de 60-90%. Veja como funcionam, por que as equipes as evitam e como executar uma versão simplificada.
A maioria dos code reviews encontra entre 15 e 30 por cento dos defeitos que deveriam encontrar. Isso não é um palpite. A IBM mediu isso nos anos 1970, e…
AutoVerus utiliza uma rede de agents LLM para gerar proofs de correção Verus para código Rust, automatizando mais de 90% das proof obligations por meio de um loop gerar-reparar-discharge impulsionado pelo feedback do solver SMT.
A parte mais difícil da verificação formal nunca foi o verificador. É escrever o proof. Dê a um engenheiro sênior de Rust o Verus, o verificador baseado em SMT…
Grandes modelos de linguagem escrevem código Rust surpreendentemente bom, mas quando você pede uma prova formal, eles alucinam invariantes e inventam sintaxe que nenhum verificador aceita. Veja o que eles realmente acertam, onde falham e como usá-los mesmo assim.
LLMs conseguem escrever Rust que compila e até passa em . O que não conseguem fazer de forma confiável é escrever uma prova formal de que o código está correto…
Por que o model checking supera dias de execução em produção para encontrar bugs de concorrência, e como aplicá-lo ao seu próprio código.
Esperar que race conditions surjam em produção não é testar. É esperança disfarçada de diligência. Você pode executar seu app por semanas, monitorar seus…