Adversarial Review

Adversarial review is a process where, before putting a product out into the world, the people who made it deliberately try to use it with bad intentions to find its flaws.

Think of a lock company calling in a professional lockpick to try to break into their new lock themselves. A normal check asks "does this feature work correctly?" but an adversarial review asks the team to try a different task: "use this feature to create the most convincing lie you can" or "what's the worst way someone could misuse this feature?" It flips the order of discovery, so that the maker finds the problem first — not a user or a journalist.

This becomes especially necessary for services like maps or medical information, where users tend to take whatever appears on screen as fact. A normal check that only filters out "things that shouldn't be said" isn't enough here. Cases where something false is stated convincingly as if it were true won't surface unless someone deliberately tries to create them — which is exactly why adversarial review is needed as a separate step.

The article points to the case of a generative map feature that was pulled within a day of launch, and holds up "building in adversarial review before launch" as the lesson for product teams to take away. A common misunderstanding is thinking this means a security check against outside hackers — in reality, it's closer to an internal team's own verification process, where they construct the worst-case scenarios themselves.

If you have a feature that's newly built or under review, put these questions directly to your team:

1. What is the most convincing piece of false information someone could create using this feature?
2. How likely is it that a user would mistake that false information for fact?
3. What happens if that wrong answer doesn't disappear from the screen, but instead persists in a cache or search results?

If the answers come too easily, actually reproduce that scenario and fix it before launch.