No filme de ficção científica de Minority Report, a premissa é sedutora: um sistema infalível que prevê assassinatos antes que aconteçam, permitindo que a "Divisão Pré-Crime" prenda o culpado e salve a vítima antes do crime. O resultado seria uma sociedade segura, mas sob vigilância e controle absolutos.

No desenvolvimento de software, nossos usuários também cometem seus "crimes capitais".

Não estou falando de um erro de validação em um formulário ou um clique errado num botão. Estou falando de ações destrutivas e muitas vezes irreversíveis: a exclusão acidental de um perfil de usuário importante, o cancelamento indevido de uma apólice ou a corrupção de integridade de dados financeiros.

O desafio da engenharia de software moderna é criar uma "Divisão Pré-Crime" eficiente, que intercepte essas catástrofes, mas que não se torne tão agressiva a ponto de prender o usuário "inocente" — aquele que tem uma necessidade genuína e, por vezes, complexa de uso — em um emaranhado de bloqueios.

O "Crime Capital" e o Domain-Driven Design (DDD)

Nem todo erro de usuário merece a intervenção da polícia de choque. Para aplicar a filosofia Minority Report corretamente, primeiro precisamos definir o que é, de fato, um crime.

Aqui entra o Domain-Driven Design (DDD). No DDD, devemos identificar quais são as Invariants (Invariantes) — regras de negócio que nunca podem ser violadas, uma regra de negócio ou lógica que deve ser sempre verdadeira.

• O Pequeno Delito: O usuário digitou uma data num formato errado. Isso não é um crime; é um tropeço. O sistema deve apenas corrigir ou orientar.
• O Crime Capital: Um usuário tenta excluir um registro raiz que possui milhares de registros dependentes. Se isso acontecer, o sistema quebra e/ou dados são perdidos.

A nossa "previsão do futuro" deve focar obsessivamente nestes casos. Se o sistema permite que um erro desse nível aconteça para depois tentar consertar (rollback), já é tarde demais. O crime já aconteceu.

TDD: As Visões dos "Pre-Cogs"

No filme, os videntes (Pre-Cogs) geram as visões do futuro. No nosso mundo, nossa bola de cristal é o TDD (Test-Driven Development).

Praticar TDD é, efetivamente, escrever a história do futuro antes que ela aconteça. Ao criar um teste que diz: "Deve falhar ao tentar excluir usuário com faturas pendentes", estamos criando uma barreira temporal.

Diferente de testes manuais que ocorrem após o desenvolvimento, o TDD garante que a funcionalidade já nasça com a "consciência", o entendimento, de que aquele crime específico não pode ser cometido. É a prevenção codificada na raiz.

O Perigo do "Falso Positivo"

O conflito central do filme acontece quando o sistema gera um "falso positivo". Ele acredita que o protagonista vai cometer um erro, mas a realidade é outra.

Sistemas excessivamente rígidos sofrem do mesmo mal. Eles tentam tanto proteger o usuário de si mesmo que impedem usos legítimos. Se o seu software trata um Administrador Sênior tentando fazer uma limpeza de banco da mesma forma que trata um estagiário desatento, você não está criando ineficiência.

A solução não é remover a segurança, mas mudar a abordagem: Fricção em vez de Bloqueio.

• Confirmação Contextual: Em ações críticas, em vez de um simples "Sim/Não", peça para o usuário digitar o que está fazendo (ex: digite "DELETAR-PROJETO") ou confirmar o nome do registro. Isso garante intencionalidade sem bloquear quem sabe o que está fazendo.
• Soft Deletes: Em vez da morte súbita dos dados, marque como excluído mas mantenha o registro recuperável por 30 dias. É o equivalente a dar a chance de "provar inocência" e recuperar o dado.
• Monitoramento: Utilize métricas para monitorar se as travas estão funcionando. Se os usuários estão constantemente batendo em uma parede de erro (falsos positivos), o time deve usar rituais ágeis (como a Retrospectiva do Scrum) para ajustar a sensibilidade dos "Pre-cogs".

Para resumir como equilibrar os conceitos, montei este guia rápido de estratégias:

✅ DDD (Domain-Driven Design)

• Papel: O Legislador.
• Ação: Define a diferença entre um "tropeço" de interface e um "crime capital" de negócio (Invariantes).
• Resultado: O sistema só bloqueia o que realmente ameaça a empresa.

✅ TDD (Test-Driven Development)

• Papel: Os Pre-Cogs (Videntes).
• Ação: Simula o desastre futuro através de testes de falha antes mesmo de escrever o código.
• Resultado: Segurança invisível e robustez desde o dia zero.

✅ Kanban / Scrum (Ágil)

• Papel: A Corregedoria.
• Ação: Usa Retrospectivas para analisar se as travas estão atrapalhando usuários legítimos.
• Resultado: O sistema evolui e as regras são ajustadas para não engessar a operação.

Conclusão

Desenvolver sistemas seguros exige a mentalidade dos Pre-Cogs: precisamos antecipar os cenários catastróficos. Mas a verdadeira sabedoria não está em impedir tudo, e sim em distinguir a imperícia da intenção.

O software ideal protege o usuário distraído de um acidente fatal, mas sai da frente quando o especialista precisa agir. Não queremos um futuro determinista onde é impossível errar (e consequentemente, impossível inovar). Queremos um sistema onde o erro fatal seja impossível, mas a usabilidade seja garantida.