In the science fiction film Minority Report, the premise is seductive: an infallible system that predicts murders before they happen, letting the "PreCrime Division" arrest the culprit and save the victim before the crime. The result would be a safe society, but one under absolute surveillance and control.

In software development, our users also commit their "capital crimes".

I am not talking about a validation error in a form or a wrong click on a button. I am talking about destructive and often irreversible actions: accidentally deleting an important user profile, wrongly cancelling a policy, or corrupting the integrity of financial data.

The challenge of modern software engineering is to build an efficient "PreCrime Division" that intercepts these catastrophes without becoming so aggressive that it locks up the "innocent" user — the one with a genuine and sometimes complex need — in a tangle of blocks.

The "Capital Crime" and Domain-Driven Design (DDD)

Not every user error deserves the intervention of a riot squad. To apply the Minority Report philosophy correctly, we first need to define what actually counts as a crime.

This is where Domain-Driven Design (DDD) comes in. In DDD, we must identify the Invariants — business rules that can never be violated, a piece of business logic that must always hold true.

• The Minor Offense: The user typed a date in the wrong format. That is not a crime; it is a stumble. The system should simply correct or guide.
• The Capital Crime: A user tries to delete a root record that has thousands of dependent records. If that goes through, the system breaks and/or data is lost.

Our "prediction of the future" must obsess over these cases. If the system allows an error of that magnitude to happen and only then tries to fix it (rollback), it is already too late. The crime has been committed.

TDD: The Visions of the "Pre-Cogs"

In the film, the psychics (Pre-Cogs) generate the visions of the future. In our world, our crystal ball is TDD (Test-Driven Development).

Practicing TDD is, effectively, writing the story of the future before it happens. By creating a test that says "It must fail when deleting a user with outstanding invoices", we are building a barrier in time.

Unlike manual testing that happens after development, TDD ensures the feature is born already aware — already understanding — that this particular crime cannot be committed. It is prevention encoded at the root.

The Danger of the "False Positive"

The central conflict of the film happens when the system produces a "false positive". It believes the protagonist is going to make a mistake, but reality says otherwise.

Overly rigid systems suffer from the same affliction. They try so hard to protect users from themselves that they prevent legitimate use. If your software treats a Senior Administrator running a database cleanup the same way it treats a careless intern, you are creating inefficiency.

The answer is not to remove the safeguards, but to change the approach: Friction instead of Blocking.

• Contextual Confirmation: On critical actions, instead of a simple "Yes/No", ask the user to type out what they are doing (e.g., type "DELETE-PROJECT") or to confirm the name of the record. This guarantees intent without blocking those who know what they are doing.
• Soft Deletes: Instead of sudden death for the data, mark it as deleted but keep the record recoverable for 30 days. It is the equivalent of granting the chance to "prove innocence" and get the data back.
• Monitoring: Use metrics to monitor whether the guardrails are working. If users are constantly hitting a wall of errors (false positives), the team should use agile rituals (such as the Scrum Retrospective) to tune the sensitivity of the "Pre-Cogs".

To sum up how to balance these concepts, here is a quick guide to the strategies:

✅ DDD (Domain-Driven Design)

• Role: The Legislator.
• Action: Defines the difference between an interface "stumble" and a business "capital crime" (Invariants).
• Result: The system only blocks what genuinely threatens the company.

✅ TDD (Test-Driven Development)

• Role: The Pre-Cogs (the psychics).
• Action: Simulates the future disaster through failing tests, before a single line of code is written.
• Result: Invisible safety and robustness from day zero.

✅ Kanban / Scrum (Agile)

• Role: Internal Affairs.
• Action: Uses Retrospectives to analyze whether the guardrails are getting in the way of legitimate users.
• Result: The system evolves and the rules are tuned so they do not straitjacket the operation.

Conclusion

Building safe systems demands the mindset of the Pre-Cogs: we need to anticipate the catastrophic scenarios. But the real wisdom is not in preventing everything — it is in distinguishing carelessness from intent.

The ideal software protects the distracted user from a fatal accident, but gets out of the way when the expert needs to act. We do not want a deterministic future where it is impossible to err (and consequently impossible to innovate). We want a system where the fatal error is impossible, but usability is guaranteed.

📌 This article was originally published on LinkedIn, in Portuguese. Read it and leave a comment there too!