Reprodutibilidade é um problema de engenharia

Engenheiros resolveram o 'na minha máquina funciona' anos atrás, não com disciplina, mas com ferramentas que fizeram do caminho disciplinado o padrão. Lock files, containers, builds imutáveis, CI que roda numa máquina limpa. Quando ouço um pesquisador dizer que uma análise não pode ser rodada de novo porque o aluno que escreveu se formou, não ouço uma falha moral. Ouço um sistema de build que não existe.

O que reprodutível significa de verdade

Mesmas entradas, mesmo código, mesmo resultado, em outra máquina, rodado por outra pessoa, um ano depois. Cada trecho dessa frase é um requisito de engenharia separado. 'Mesmas entradas' exige que os dados brutos sejam imutáveis e endereçados por hash, não por nome de arquivo. 'Mesmo código' exige a versão exata de cada biblioteca: não 'pandas', mas 'pandas 2.2.1 com numpy 1.26.4'. 'Outra máquina' exige o ambiente declarado, não presumido. 'Um ano depois' significa que as dependências ainda precisam resolver, o que significa fixar ou vendorizar, porque a internet esquece.

A maioria das análises falha no segundo trecho. Uma seed aleatória definida interativamente e não no script. Uma atualização de biblioteca que mudou um padrão. Um caminho que só existe num laptop.

Dado bruto é somente leitura, para sempre

A primeira regra que dou a qualquer time, em software ou em ciência, é que dado bruto nunca é editado. Ele cai numa pasta em que ninguém tem permissão de escrita, com o checksum registrado ao lado, e cada etapa de limpeza é um script que lê dali e escreve em outro lugar. Se um valor está errado no dado bruto, você documenta e corrige numa transformação, para que a correção seja visível e reversível.

Essa regra sozinha elimina a falha mais comum que vejo: alguém corrigiu um erro de digitação na mão, na planilha, a correção estava certa, e agora ninguém consegue provar como era o original nem se outras células foram tocadas na mesma sessão.

A análise é software, trate como tal

Um notebook de análise é um programa. Programa precisa de controle de versão, de um jeito de rodar pela linha de comando sem um humano clicando célula por célula na ordem certa, e de pelo menos um teste que afirme algo conhecido sobre a saída. O teste não precisa ser sofisticado. 'A coorte tem 412 linhas depois do filtro' é um teste. 'A idade média está entre 40 e 80' é um teste. Quando o número muda, você descobre no dia em que mudou, não na revisão por pares.

Depois, coloque tudo num container e rode em integração contínua a cada commit. Se produz as mesmas figuras numa máquina limpa, você tem reprodutibilidade. Se não produz, você encontrou a dependência escondida agora, barato, em vez de depois, caro.

Determinismo é uma escolha feita cedo

Parte da computação é não determinística por natureza: reduções paralelas, kernels de GPU, amostragem. Nem sempre dá para ser idêntico bit a bit, mas dá para decidir o que 'mesmo resultado' significa e verificar: faixas de tolerância, seeds fixas, equivalência estatística. O que não dá é descobrir isso depois. Já auditei pipelines em que duas execuções divergiam na terceira casa decimal e ninguém sabia dizer se era ruído ou bug, porque ninguém tinha decidido antes.

Por que um engenheiro se importa

Reprodutibilidade não é uma virtude a ser pregada. É uma propriedade de um sistema, e sistemas ganham propriedades por design. Cada prática acima é padrão em qualquer time de software decente e não exige ciência nova. Exige alguém tratando o trabalho computacional do laboratório como infraestrutura e dando a ele o mesmo cuidado que damos a um serviço de pagamentos. Esse é um papel que eu reconheço, e um trabalho que acho que vale a pena fazer.