Adversarial Prompting Against Your Own Biases
You are biased. I am biased. Everyone you know is biased. This is not an insult; it is a description of how human cognition works. Our brains are prediction machines that take shortcuts, and those shortcuts — heuristics, in the polite terminology — work remarkably well most of the time. They also fail in systematic, predictable, and occasionally catastrophic ways. We call these failure modes cognitive biases, and there are enough of them catalogued to fill a book considerably longer than this one.
The standard advice for dealing with cognitive biases is to learn about them and then try to notice when you are falling prey to them. This advice is largely useless. Knowing about confirmation bias does not prevent you from seeking confirming evidence for your beliefs. Knowing about the anchoring effect does not prevent the first number you see from influencing your estimate. Knowing about the Dunning-Kruger effect does not tell you whether you are currently in the valley of overconfidence or the plateau of competence. Self-awareness of biases is valuable as background knowledge, but it is inadequate as an intervention.
LLMs offer something different. Not a cure for bias — there is no such thing — but a practical tool for stress-testing your thinking before you commit to a conclusion. The concept is simple: before you form an opinion, make a decision, or take a position, you use adversarial prompts to systematically attack your own reasoning. Not to prove yourself wrong (though that happens sometimes), but to find the weak points so you can address them before they become problems.
This is not a substitute for critical thinking. It is a force multiplier for critical thinking. And unlike purely mental exercises in self-examination, it produces external output that you can look at with some objectivity, which is exactly what you cannot do with thoughts that are still inside your own head.
The Core Technique
Adversarial prompting works like this:
- You have a belief, conclusion, or decision you are leaning toward
- You articulate it to the LLM
- You use specific prompts designed to challenge, stress-test, and find weaknesses in that belief
- You evaluate the LLM’s challenges honestly
- You update your belief, strengthen your argument, or identify areas for further investigation
The critical word in step 4 is “honestly.” If you dismiss every challenge the LLM raises (“well, that does not apply in my case” / “that is not really relevant”), you are performing theater, not analysis. The point is to take the challenges seriously even when — especially when — they make you uncomfortable.
Let me walk through the specific techniques, each with example prompts and sample conversations showing how they work in practice.
Technique 1: The Full-Force Counterargument
The most straightforward adversarial technique. You state your position and ask the LLM to argue against it as strongly as possible.
Prompt:
I believe [your position]. Argue against this position as strongly and
persuasively as possible. Don't give me a balanced view — give me the
single best case against my position, as it would be made by a smart,
well-informed person who genuinely disagrees.
Specifically:
- What evidence or arguments would they find most compelling?
- Where are the weaknesses or assumptions in my reasoning?
- What real-world examples would they point to?
- What would they say I am overlooking or underweighting?
Example conversation:
Me: I believe that remote work is generally better for software
engineering teams than in-office work. Argue against this as
strongly as possible.
LLM: The strongest case against remote-first engineering goes
beyond the usual "collaboration suffers" talking points. Here's
the steel-manned argument:
The most critical knowledge in engineering organizations is tacit —
it's absorbed through proximity, not transmitted through
documentation. Junior engineers in remote environments show
measurably slower skill development because they lack the ambient
learning that happens when you overhear a senior engineer debugging,
watch how they approach a code review, or pick up team norms through
osmosis rather than explicit instruction. Microsoft Research's 2021
study of their own workforce found that remote work increased
siloing between teams and reduced cross-group collaboration, which
is where most genuine innovation happens — at the boundaries
between groups, not within them.
The productivity data that remote work advocates cite is largely
self-reported and measures output quantity, not quality. Developers
write more code remotely, but the studies do not account for rework
rates, architectural coherence, or the long-term maintainability of
code written in isolation. Meanwhile, the attrition data tells a
different story: companies that went fully remote saw lower
voluntary turnover initially (selection effect — people who stayed
wanted remote), but higher involuntary turnover and lower
performance ratings for employees hired into remote positions
compared to those who transitioned into them.
There's also the equity problem remote advocates rarely address:
remote work disproportionately benefits senior, established,
well-housed employees with dedicated home offices and existing
professional networks. It disadvantages new graduates, people in
shared housing, and anyone who relies on the workplace for
professional network building. The "flexibility" narrative
primarily serves a demographic that already has the most options.
Finally, the argument assumes that current collaboration tools
are adequate substitutes for co-presence. They are not. Every
significant study of distributed collaboration finds that even
the best tools create friction that accumulates over time. The
teams that report high satisfaction with remote work are typically
those that meet in person periodically — which suggests that the
actual optimal model is hybrid, not remote-first, and that remote
work's apparent success is partly subsidized by the in-person
interactions it relies on.
Me: That's a stronger argument than I expected. Let me push back
on the tacit knowledge point — how much of that is about remote
work being genuinely worse, versus existing mentorship practices
being designed for in-person environments and not yet adapted?
LLM: That's a legitimate distinction, and it highlights one of
the methodological problems with the current evidence...
Notice what happened here. I did not just accept the counterargument wholesale, and I did not dismiss it. I engaged with it, pushed back on the most interesting point, and got a more nuanced discussion as a result. That is the productive pattern.
Technique 2: The Evidence Threshold Test
Instead of arguing against your position, this technique asks what evidence would change your mind. This is borrowed from the rationalist practice of making beliefs “pay rent” — forcing yourself to identify what would make them wrong.
Prompt:
I currently believe [your position]. What specific evidence or
observations would — and should — cause me to change my mind?
For each piece of evidence:
- Describe it concretely (not "if things got worse" but what
specifically would need to happen)
- Explain why it would constitute genuine counterevidence
- Assess how likely it is that this evidence already exists and
I haven't seen it
Example conversation:
Me: I believe that our company should invest heavily in building
an internal AI platform rather than relying on third-party APIs.
What evidence should cause me to change my mind?
LLM: Here are five specific pieces of evidence that should
genuinely shift your position:
1. COST TRAJECTORY: If third-party API costs drop below $X per
million tokens within 18 months (specific to your usage volume),
the cost advantage of internal infrastructure disappears. Currently,
the trend line suggests this is possible but not certain. Check
your volume projections against the pricing trajectories of the
top 3 API providers.
2. CAPABILITY VELOCITY: If the capability gap between the best
commercially available models and what you could train internally
is widening rather than narrowing. If open-source models are not
closing the gap with commercial ones in your specific use cases,
internal investment gives you access to yesterday's capabilities
at today's prices.
3. TALENT REALITY: If you cannot hire or retain 3-5 senior ML
engineers within 6 months at a compensation package your budget
supports, the internal platform will be built by people who are
not experienced enough to build it well. The talent market for
this skill set is specifically worth investigating before
committing.
4. REGULATORY DIRECTION: If upcoming regulation is moving toward
requiring third-party audit of AI systems, building internally
might create compliance burdens that managed APIs handle for you.
Check the trajectory of the EU AI Act enforcement guidelines
and any industry-specific regulation.
5. USAGE PATTERN: If your actual usage patterns show high
variability (10x spikes, seasonal patterns, unpredictable demand),
the elastic scaling of API-based approaches may be more cost-
effective than provisioning internal infrastructure for peak load.
Review your last 12 months of usage data.
The evidence most likely to already exist and be underweighted
in your analysis: #3 (talent reality) and #5 (usage patterns).
Companies consistently overestimate their ability to hire
specialized talent and underestimate their usage variability.
This technique is powerful because it forces you to define your exit criteria before you are emotionally committed to a course of action. If you know in advance what would change your mind, you are more likely to notice that evidence when it appears.
Technique 3: The Perspective Shift
Your background, training, and experience give you a specific lens on any problem. That lens is valuable — it is literally your expertise. But it is also a bias, because it highlights certain features while hiding others.
Prompt:
I'm thinking about [topic/decision] from my perspective as a
[your role/background]. How would each of the following people
think about this differently?
1. Someone from [a different discipline or field]
2. Someone from [a different cultural or geographic context]
3. Someone who has [a different professional incentive]
4. Someone who will be affected by this but isn't in the room
5. Someone who tried this ten years ago
For each perspective, give me not just their opinion but WHY they
would see it differently — what different information or experience
would make their view feel as obviously correct to them as mine
feels to me?
Example conversation:
Me: I'm a startup CTO thinking about whether to adopt a
microservices architecture for our new platform. How would
these people think about it differently?
1. An experienced SRE (operations engineer)
2. A CTO at a company in Southeast Asia with different
infrastructure economics
3. A venture capitalist evaluating our technical choices
4. A junior developer who will join the team in 6 months
5. Someone who built a microservices architecture at a
similar-stage startup in 2016
LLM: 1. THE SRE: "You're buying complexity at a stage where
you can least afford it. Every service boundary is a failure
mode. Every network call is a latency source. Every
inter-service dependency is something that breaks at 3 AM.
You don't have the observability tooling, the deployment
automation, or the on-call team to support this. A monolith
with clean module boundaries gives you 90% of the architectural
benefit with 10% of the operational cost. You can extract
services later when you actually have the traffic patterns
that justify them."
They see it differently because they will be the ones woken
up when it fails, and they know from experience that
distributed systems fail in ways that are qualitatively harder
to diagnose than monolithic ones.
2. THE SOUTHEAST ASIAN CTO: "Your assumption that cloud
infrastructure is cheap and infinitely elastic reflects US-centric
pricing and availability. In my market, bandwidth costs are 3-5x
higher, data center options are fewer, and we pay meaningful
egress costs for inter-service communication that your napkin
math probably ignores. Also, our developer talent pool is
strong but more familiar with monolithic frameworks. The hiring
cost of 'must have microservices experience' narrows our
candidates by 60%."
They see it differently because infrastructure economics and
talent markets vary dramatically by geography, and most
architecture discourse is written from a Silicon Valley
perspective...
[continues with remaining perspectives]
The value here is not that any single perspective is “right.” It is that seeing the same decision through five different lenses reveals dimensions you would never surface on your own. The SRE’s operational concern, the geographic economic difference, the junior developer’s experience — these are all real considerations that a CTO might easily overlook.
Technique 4: The Pre-Mortem
I introduced this briefly in Chapter 10, but it deserves a fuller treatment here because it is one of the most practically valuable adversarial techniques.
A pre-mortem inverts the normal planning process. Instead of asking “how will this succeed?”, you assume it has already failed and work backward to figure out why.
Prompt:
I'm about to [decision/action]. Assume it's now 12 months later
and this decision has turned out to be clearly wrong. Write a
postmortem that explains:
1. What went wrong (the most likely failure mode, not the
most dramatic)
2. What warning signs were visible in advance but overlooked
3. What assumption proved to be incorrect
4. What external change happened that we didn't anticipate
5. What we should have done differently
Be realistic, not catastrophic. I'm looking for the most
probable failure, not the worst-case scenario.
Example conversation:
Me: We're about to hire three senior engineers and double our
team size over the next quarter. Assume this turns out badly.
Write the postmortem.
LLM: POSTMORTEM: Q3 Team Scaling Initiative
WHAT HAPPENED: We hired three senior engineers in Q1 as planned.
All three were technically strong. By Q3, one had left, team
velocity had decreased rather than increased, and the remaining
team reported lower satisfaction than before the hires.
ROOT CAUSE: We optimized for technical ability and underinvested
in onboarding and integration. The three new hires arrived within
a four-week window. Each required significant context transfer
from existing team members, who spent 30-40% of their time in
the first two months on onboarding rather than feature work. This
created a productivity dip that was deeper and longer than
anticipated.
Simultaneously, the team's communication patterns did not scale
smoothly. What worked for a team of 4 (informal, synchronous,
everyone in the same context) broke at a team of 7. Decisions
that previously happened in a quick conversation now required
meetings, and the new hires did not always have context on
implicit decisions and conventions that the original team took
for granted.
The engineer who left cited "not what I expected" — specifically,
the gap between the technical challenges described in the
interview and the reality of working in a codebase with
significant technical debt that was not mentioned during hiring.
WARNING SIGNS WE MISSED:
- We had no structured onboarding process documented before
hiring
- We did not stagger the start dates
- We did not explicitly discuss how team communication patterns
would need to change
- Our job descriptions emphasized the aspirational technical
work, not the current codebase reality
WHAT WE SHOULD HAVE DONE:
- Staggered hires across 8-12 weeks instead of 4
- Built an onboarding program before posting the job listings
- Budgeted for a 2-month productivity dip and communicated
this to stakeholders
- Been more transparent in interviews about the current state
of the codebase
Pre-mortems work because they leverage the storytelling capability of LLMs in a productive direction. The model is very good at constructing plausible narratives, and when you point that capability at failure scenarios, you get realistic cautionary tales that highlight exactly the kinds of risks that optimistic planning tends to miss.
Technique 5: The Anchoring Audit
Anchoring is the cognitive bias where the first piece of information you encounter on a topic disproportionately influences your subsequent thinking. It is one of the most robust findings in cognitive psychology and one of the hardest to self-correct for, because you often do not know what you are anchored on.
Prompt:
I'm thinking about [topic/decision] and I want to check for
anchoring effects. Based on what I've told you so far, what
might I be anchored on? Consider:
- The first number, estimate, or data point I was exposed to
- The framing of the question (how the decision was initially
presented to me)
- A prominent example or case study that might be
unrepresentative
- A default option or status quo that I might be treating as
the baseline without justification
- An analogy or comparison that might be subtly misleading
For each potential anchor, explain how it might be distorting
my thinking and suggest a way to re-frame or re-estimate
independently.
Example conversation:
Me: We're negotiating a contract with a new vendor. Their
initial proposal was $500K/year. We think the fair price is
around $350K based on our research. I want to check for
anchoring effects.
LLM: Several potential anchors in this situation:
1. THE $500K OPENING BID: This is the most obvious anchor.
Even though you "know" it's high, it has established the
numerical range for the negotiation. Your $350K counter may
itself be anchored — $350K feels like a significant discount
from $500K (a 30% reduction), but is it actually the right
price independent of their opening bid? If the vendor had
opened at $300K, would your research still have led you to
$350K? Try this: estimate what you would pay if you were
designing this contract from scratch, without having seen
their proposal. If that number is meaningfully different
from $350K, you may be anchored.
2. THE "COMPARABLE" CONTRACTS: When you say "our research,"
what comparisons did you use? If you benchmarked against
similar contracts, those contracts reflect their own
negotiation dynamics and market conditions, which may or
may not apply to yours. The "market rate" is itself an anchor
if the market is significantly different from your specific
situation (different scale, different requirements, different
alternatives).
3. THE STATUS QUO: If you're currently using a different
vendor or solution, your current cost is an anchor. "We're
currently paying $X, so anything more than that feels
expensive" is a common pattern even when the new vendor
provides materially different value.
4. THE FRAMING AS "NEGOTIATION": Once the interaction is
framed as a negotiation, you're implicitly anchored on
compromise — meeting somewhere between their number and
yours. But the right price is the right price, regardless
of where either party starts. Consider whether $350K is
your actual valuation or your negotiating position.
REFRAMING EXERCISE: Set aside all the numbers you've
discussed. Answer this: what is the maximum you would pay
for this service if you were buying it at a fixed price with
no negotiation? That number, derived independently, is your
actual valuation.
This technique is especially useful in situations involving numbers — budgets, timelines, pricing, estimates — where anchoring effects are strongest and most consequential.
Technique 6: The Survivorship Bias Check
We tend to draw conclusions from visible successes while ignoring invisible failures. The company that succeeded with a risky strategy gets a case study; the fifty companies that used the same strategy and failed do not.
Prompt:
I'm drawing a conclusion from [examples/evidence]. Help me check
for survivorship bias:
1. What is the "graveyard" here — who tried something similar
and failed, and why might I not be hearing about them?
2. Am I looking at a representative sample, or a selected one?
3. What would the data look like if I included the failures?
4. Is there a structural reason why successes in this area are
more visible than failures?
Technique 7: The Sunk Cost Audit
When you have invested time, money, or emotional energy in a direction, you are biased toward continuing in that direction regardless of whether it is still the best path.
Prompt:
I've been [investing in / working on / committed to] [X] for
[time period]. I want to evaluate whether I should continue,
setting aside what I've already invested.
Imagine I had not yet started. Knowing everything I know now
about the results so far, the remaining effort required, and
the alternatives available, would I start this project today?
Evaluate honestly:
- What have the actual returns been vs. what was projected?
- What would I do with the resources (time/money/attention)
if I stopped?
- What is the opportunity cost of continuing?
- Am I continuing because it's the best use of my resources,
or because I've already invested and don't want to "waste"
the investment?
Technique 8: The Consensus Check
When everyone around you agrees, that can mean you are right — or it can mean you are in an echo chamber. This technique helps distinguish between genuine consensus and social conformity.
Prompt:
In my professional/social environment, there is a strong
consensus that [the consensus view]. I want to stress-test
whether this consensus reflects genuine evidence or group
dynamics.
1. What are the incentives for people in my environment to
hold this view? Are there social or professional costs to
disagreeing?
2. Where would I find informed dissent? Who disagrees with
this consensus and what is their strongest argument?
3. Is this consensus based on evidence that the group has
evaluated, or on authority/reputation/convention?
4. Has this consensus been tested against real-world outcomes,
or is it primarily a shared belief?
5. If this consensus is wrong, what would be the first
observable sign?
Technique 9: The Scope Sensitivity Test
We often fail to scale our emotional or cognitive response appropriately to the magnitude of a problem. Saving 10 lives and saving 10,000 lives feel similarly important in our gut, even though one is 1,000 times more significant.
Prompt:
I'm evaluating [situation/problem]. Help me check whether my
assessment is properly calibrated to the actual scale:
1. How big is this really? Put it in context with relevant
comparisons.
2. Am I over-reacting because the problem is vivid or
emotionally salient?
3. Am I under-reacting because the numbers are abstract or
the effects are distributed?
4. If I'm allocating resources to this, is the amount
proportional to the magnitude of the problem compared to
other problems competing for the same resources?
Technique 10: The Narrative Bias Detector
Humans are storytelling animals. We find narratives compelling and satisfying in ways that statistical evidence is not. This makes us vulnerable to accepting plausible stories over less compelling but more reliable data.
Prompt:
I've been persuaded by [an argument / a case study / an
anecdote / a narrative]. Help me check whether I'm being
persuaded by the quality of the story rather than the quality
of the evidence:
1. Is this argument compelling because of the evidence or
because it tells a good story?
2. If the same conclusion were supported by dry statistical
data instead of a narrative, would I find it equally
convincing?
3. Could the opposite conclusion be supported by an equally
compelling narrative?
4. What is the actual base rate for the phenomenon described
in this story?
5. Is this example representative, or is it an outlier that
makes for a better story precisely because it is unusual?
Example conversation:
Me: I've been persuaded by a case study of a company that
radically simplified its product line and saw revenue grow
by 200% in two years. I'm now thinking we should do
something similar. Check my narrative bias.
LLM: Let's examine this:
1. STORY VS. EVIDENCE: The case study is compelling because
it has a clear protagonist (the company), a bold decision
(radical simplification), and a dramatic outcome (200%
revenue growth). This is a classic hero narrative. But a
single case study, no matter how dramatic, is an anecdote,
not evidence. N=1.
2. THE DRY DATA VERSION: If I told you that "in a study of
200 companies that simplified their product lines, the
median revenue change was -3% with a standard deviation of
45%, though 8% of them saw revenue increases above 100%,"
would you make the same decision? That hypothetical data
suggests simplification is a high-variance strategy that
fails more often than it succeeds, but occasionally produces
dramatic results — which is exactly the kind of outcome that
generates case studies.
3. THE OPPOSITE NARRATIVE: I could equally construct a
compelling narrative about a company that expanded its
product line and saw dramatic growth. In fact, Amazon's
entire history is this narrative. "From books to everything"
is as good a story as "from everything to simplicity." The
question is which approach applies to YOUR situation, and a
narrative does not answer that.
4. SURVIVORSHIP: The case study exists because the outcome
was dramatic. Companies that simplified and saw flat or
declining revenue do not get case studies written about them.
The fact that you have heard this story tells you almost
nothing about the probability of the same outcome for you.
5. YOUR SITUATION: Before drawing any conclusion from this
case study, you need to identify: what specific conditions
made simplification work for that company? Do those
conditions exist in your situation? If you cannot answer
those questions specifically, you are not learning from
their experience — you are borrowing their narrative.
When Adversarial Prompting Is Most Valuable
Not every decision warrants a full adversarial analysis. If you spend 30 minutes running pre-mortems on where to eat lunch, you have missed the point. Here is when to deploy these techniques:
High-stakes decisions: When the consequences of being wrong are significant — financial commitments, strategic direction changes, hiring decisions, major purchases. The time invested in adversarial prompting is proportional to the cost of being wrong.
Strong convictions: When you feel very certain about something, that is precisely when adversarial prompting is most valuable. Certainty and accuracy are not the same thing, and the feeling of certainty can prevent you from noticing evidence that your position is weaker than you think.
Group consensus: When your team or organization has converged on a view and no one is raising objections, use adversarial prompting to generate the objections that social dynamics might be suppressing.
Novel situations: When you are in unfamiliar territory — a new market, a new technology, a new role — your intuitions are least reliable. Adversarial prompting can surface considerations that your inexperience would otherwise cause you to miss.
Before public commitments: Before publishing an article, giving a presentation, or making a public statement, run your key claims through adversarial prompting. It is much better to discover a weakness in your argument before your audience does.
When Adversarial Prompting Is Overthinking
Low-stakes decisions: Routine choices where the cost of being wrong is low and easily reversible. Not everything needs stress-testing.
Time-critical situations: When you need to act now and the cost of delay exceeds the cost of a suboptimal decision. Adversarial analysis takes time, and sometimes time is the scarcest resource.
Decisions already made: There is a point where adversarial analysis becomes rumination. If you have made a decision, committed resources, and begun execution, continuing to stress-test the decision is usually counterproductive. Run the pre-mortem before you commit, not after.
Personal preferences: “Should I learn Spanish or Japanese?” is a preference, not a position that needs adversarial stress-testing. Not everything is an argument.
Building Adversarial Prompting Into Your Workflow
The techniques above are most effective when they are habitual rather than occasional. Here is how to build them into your regular practice:
The Decision Journal
When you face a significant decision, document it:
- The decision: What are you deciding?
- Your initial position: What do you think you should do, and why?
- Adversarial analysis: Run 2-3 of the techniques above
- Updated position: Did anything change? What risks did you identify?
- What to watch for: Based on the pre-mortem and evidence threshold analysis, what signals would indicate you were wrong?
Review your decision journal quarterly. How often were your initial positions correct? How often did adversarial analysis surface important considerations? Were there patterns in the biases that showed up most frequently? This meta-analysis makes your adversarial practice better over time.
The Weekly Devil’s Advocate
Once a week, pick one belief or assumption you hold and run it through the full-force counterargument technique. Not a big strategic decision — just a working assumption in your professional life. “We should be using [this technology].” “Our biggest competitor is [X].” “Our users primarily care about [Y].”
You will be surprised how often your working assumptions have not been examined since you first adopted them, and how many of them have weak foundations. This practice takes 15-20 minutes and consistently surfaces actionable insights.
The Pre-Decision Checklist
Before any significant decision, run through this checklist:
- Have I stated my position clearly enough to challenge it?
- Have I run at least one adversarial technique (counterargument, pre-mortem, or perspective shift)?
- Have I identified what would change my mind (evidence threshold test)?
- Have I checked for the most common biases (anchoring, sunk cost, survivorship, narrative)?
- Have I considered who is not in the room and how they would see this differently?
- Am I making this decision because of the evidence, or because of a compelling story?
Not every item on this checklist requires a full LLM session. Some can be addressed in a few minutes of reflection. But having the checklist ensures that you at least ask the questions, which is more than most people do.
The Meta-Bias: Being Biased About Which Biases You Test For
There is one more trap that is worth discussing, because it is subtle and common enough to deserve its own section.
When you use adversarial prompting regularly, you develop preferences for which techniques you use. Maybe you love pre-mortems but rarely do perspective shifts. Maybe you always check for confirmation bias but never think about anchoring. Maybe you challenge your professional assumptions but never your personal ones.
These preferences are themselves a bias. You are testing for the biases you are comfortable finding and ignoring the ones that would be more uncomfortable to discover. The confirmation bias check becomes its own form of confirmation bias: “I checked for bias, so I must be unbiased” — while the specific biases you did not check for continue to operate unchallenged.
The antidote is rotation. Do not always use the same adversarial technique. Vary them deliberately. Keep a list of all ten techniques and track which ones you have used recently. If you notice you are avoiding a particular technique, that is probably the one you need most.
You can also meta-prompt:
Given the decision I'm facing — [decision] — which cognitive
biases am I most likely to be affected by that I might not
think to test for? Consider biases that specifically apply to
someone in my position (a [your role] with [your background]
making a decision about [decision domain]).
This is recursion that is actually useful: using the LLM to identify the biases you are biased about testing for. It does not solve the problem completely — you are always at least one level of meta-bias deep — but it adds a valuable layer of self-examination.
What This Looks Like in Practice
Let me close with a realistic scenario of adversarial prompting applied to an actual decision, showing how multiple techniques combine.
Situation: You are a product lead considering whether to add an AI-powered feature to your product. Your initial assessment is positive — the technology is ready, competitors are moving in this direction, and customers have expressed interest.
Step 1 — State your position: “We should add an AI-powered recommendation feature to our product in Q3. The technology is mature enough, three competitors have launched similar features this year, and 40% of surveyed customers said they would find it valuable.”
Step 2 — Full-force counterargument: The LLM surfaces: the “40% interested” stat is from a survey where interest is cheap and does not predict actual usage; competitors launched but none have published usage data, which might mean adoption is low; the technology being “mature enough” hides significant quality and reliability questions.
Step 3 — Pre-mortem: The LLM constructs a failure scenario where the feature launches, initial adoption is reasonable, but accuracy problems lead to user complaints, customer support load increases, and the feature becomes a liability rather than an asset. The key warning sign: no investment in an accuracy monitoring system before launch.
Step 4 — Evidence threshold test: You identify that you would change your mind if: (a) you could get actual usage data from competitors’ similar features showing less than 20% monthly active usage, (b) user testing with a prototype showed less than 30% completion rate, or (c) accuracy benchmarking on your real data showed error rates above 15%.
Step 5 — Updated position: Your position is still positive, but with important modifications: you need to run a prototype user test before committing to Q3, you need accuracy benchmarks on real data, and you need to build monitoring infrastructure alongside the feature. The decision has not changed, but the plan has improved significantly.
Total time: 30-40 minutes. The decision is better, the risks are identified, and the plan includes safeguards that the original assessment did not. This is what adversarial prompting looks like when it is working — not paralysis, not constant self-doubt, but systematic improvement of decisions through deliberate stress-testing.
You will not always change your mind. Most of the time, your initial position will survive the adversarial process, and that is fine. The value is not in changing your mind — it is in knowing why you should not change it, and in finding the specific areas where your thinking needed strengthening. Adversarial prompting against your own biases is not about being wrong. It is about being less wrong, more carefully, more often.