← Courses
Better Brainstorming with AI · Module 3: Red Teaming Your Own Ideas
DEBATE
← Module 2
Module 3 of 8
Module 4 →
Module 3 of 8

Red Teaming Your Own Ideas

5 min read

The most dangerous moment in any creative process is the transition from generation to belief. An idea that survives the first 30 seconds of internal evaluation feels substantially more real than one that doesn't — and by the time you've shared it with anyone, you've usually convinced yourself it's better than it is. Red teaming is the discipline of adversarially challenging your own thinking before someone else does. This module teaches you to use AI as your adversary — not to kill ideas, but to stress-test them until the ones worth keeping are clearly distinguishable from the ones held together by enthusiasm.

Most idea evaluation happens in friendly territory. You share with people who want you to succeed, which means they give you feedback on your expression rather than your underlying reasoning. The pitch gets sharper. The assumption underneath it goes untouched. This is how ideas survive long enough to fail publicly — they were never tested in the conditions where they actually break.

Red teaming with AI changes the dynamic because AI has no investment in your success. It will argue against you with the same fluency it uses to argue for you — if you ask it to. That instruction is the only thing standing between AI as a polish tool and AI as a genuine intellectual adversary. This module teaches you exactly how to give it.

  • Construct a structured adversarial challenge for your own idea using AI as the opposing voice
  • Identify the load-bearing assumptions underneath any proposed solution
  • Distinguish between an idea that's weak and an idea that's weak under a specific condition
  • Use steel-manning to evaluate the strongest version of an opposing position
  • Explain why pre-mortems produce more useful information than post-mortems
Portfolio Artifact Debate Lab — Red Team Session A completed red team session — your idea, AI's adversarial challenge, your defense, and a final assessment of which assumptions are genuinely load-bearing vs. incidental.
Scenario

The Pitch That Hadn't Been Tested

4 min read

A startup founder has developed a go-to-market idea she's convinced is differentiated. She's presented it to her co-founders twice; both times it was received enthusiastically. She's preparing to pitch it to investors. She uses AI to help polish the pitch deck — structure, language, narrative flow. The AI helps her make the pitch cleaner and more confident. Three weeks later, the first investor meeting surfaces an objection she'd never considered: her differentiation claim depends on a market condition that's been changing for 18 months. She didn't know because no one in her circle had challenged the assumption directly. The AI she used to polish the pitch had never been asked to challenge it.

The co-founders were enthusiastic because they were invested in the outcome. The AI was helpful because it was responding to the task it was given — improve the pitch. Neither the human supporters nor the AI adversary identified the flaw, because neither was asked to look for it. The polish got better every iteration. The underlying assumption went untested every iteration.

By the time the investor asked the direct question, the founder's belief in her own differentiation claim was strong enough that the challenge felt like an attack rather than a test. She defended the claim instead of examining it. The meeting ended without a second meeting.

Why friendly audiences are dangerous

Ideas feel more real each time they go unchallenged. This is not wishful thinking — it's a well-documented pattern in how belief is formed. Repetition without contradiction creates confidence. The founder's pitch sounded better every time she gave it. Her confidence increased proportionally. The underlying assumption that her differentiation depended on a stable market condition was never surfaced — not because it was hidden, but because everyone she spoke with was evaluating the expression of the idea, not the validity of its foundations.

Friendly audiences provide feedback on whether the idea is communicated well. They do not provide feedback on whether the idea is correct. A rigorous red team does the opposite: it ignores polish entirely and goes directly for the conditions under which the idea fails. That is what would have caught the assumption before the investor room did.

Lesson

How to Fight Your Own Thinking

5 min read

Red teaming is not criticism — it's adversarial hypothesis testing. Criticism looks for flaws. Red teaming looks for the conditions under which the idea fails, which is a more precise and useful question. A flaw is a judgment. A failure condition is a testable claim. When you know the specific conditions under which your idea breaks, you can either address those conditions or decide that they're unlikely enough to proceed anyway. That's a real decision. "This idea has weaknesses" is not.

The distinction matters because it changes how you respond. Criticism invites defense. Failure-condition analysis invites inquiry. When AI tells you your pitch has weaknesses, you argue. When AI tells you your pitch fails if the market condition you're assuming is no longer true, you investigate whether that condition is still true. The red team produces action rather than resistance.

1. Steel-manning. Before criticizing, construct the strongest possible version of the opposing position. If you can't articulate a compelling case against your own idea, you haven't really challenged it — you've only challenged the weakest version of the objection, which is easy to defeat and tells you nothing. Ask AI to build the strongest case against your position, not the most obvious one. Then engage with that version.

2. Pre-mortem. Ask AI to imagine the idea has failed 12 months from now and describe the most likely cause. This reframe is powerful because it treats failure as a scenario to investigate rather than a judgment to resist. "The idea failed because..." produces specific, examinable claims. "Here's why this might not work..." produces vague caution. The pre-mortem anchors the challenge to a concrete future state, which makes the conditions discussable rather than threatening.

3. Load-bearing assumptions. Every idea rests on conditions it requires to be true. Most of those conditions are never made explicit — they're the water the idea swims in. Red teaming identifies which conditions are verified versus assumed, and which, if wrong, would cause the entire structure to collapse. An idea can survive many false assumptions. It cannot survive a false load-bearing assumption. The goal is to identify which category each one falls into before you've committed resources to the outcome.

Governance Standards — The Regulatory Layer
O*NET — Complex Problem Solving (2.B.3.g) Complex problem solving requires identifying the real constraints in a situation, not just the visible ones. Red teaming is the applied practice of this competency — finding the hidden conditions your solution requires before committing resources to it.
EU AI Act — Art.14 Human Oversight Human oversight of AI requires active critical evaluation, not passive acceptance. When AI polishes your pitch without challenging it, you've added speed but removed an oversight function. Red teaming restores that function deliberately.
O*NET — Critical Thinking (4.A.4.a) Critical thinking means evaluating evidence for and against a conclusion. Steel-manning requires you to find the best evidence against your own conclusion — the most demanding form of this O*NET competency.
Context

Three Moves for Red Teaming with AI

4 min read

Red teaming with AI requires something most people never do: explicitly instruct the AI to work against you. The default AI posture is helpful, affirming, and collaborative. That default is exactly what you need to override.

Move 1 — Give AI permission to disagree

The default AI posture is helpful and affirming. To red team effectively, you have to explicitly instruct AI to challenge, not support. "Your job is to find every reason this fails" produces different output than "what do you think of this idea?" The second prompt invites a balanced assessment. The first locks AI into an adversarial role that forces it to surface objections it would otherwise soften or omit. The instruction is the whole difference. Most people never give it.

Move 2 — Name your assumptions before the red team starts

Before asking AI to challenge anything, write down the three conditions your idea requires to be true. This gives the red team something specific to test rather than generating generic objections that feel like criticism rather than useful challenge. "I'm assuming the market condition X is stable," "I'm assuming our target customer behaves like Y," "I'm assuming our differentiation claim survives Z competitive response." Named assumptions can be tested. Unnamed ones hide until they fail.

Move 3 — A good red team produces better ideas, not fewer

The goal is not to reduce your confidence. It's to sharpen what you keep. After a rigorous challenge, the ideas that survive are more defensible. The ones that don't survive were going to fail anyway — you've just moved that discovery earlier. Moving failure discovery earlier is one of the highest-value activities in any decision-making process. A founder who discovers the flaw before the investor room does is in a fundamentally different position than one who discovers it during the meeting.

You'll apply all three moves in the lab — the AI will argue the opposing position while you defend your reasoning, and you'll decide together which assumptions are load-bearing.

DEBATE
Red Teaming Your Own Ideas
⏱ 20–30 minutes
Your Role
Defender You bring an idea or proposal and defend it against AI's structured adversarial challenge. Your goal is not to win — it's to identify which parts of your idea are genuinely strong and which are held together by assumption.
AI Role
Devil's Advocate Takes the opposing position and maintains it rigorously. Uses steel-manning (arguing the strongest version of the opposing case), pre-mortem (imagining failure and reasoning backward), and load-bearing assumption testing. Does not let the learner off the hook with vague defenses.
Framework Reminders
Steel-man before you criticizeConstruct the strongest possible opposing position — not the easiest one to defeat.
Name your assumptions firstWrite down the three conditions your idea requires to be true before the challenge starts.
Survive the challenge, don't just rebut itA rebuttal answers the objection. Surviving means the underlying assumption has been tested.
Completion
Complete a full red team session — initial idea, adversarial challenge, defense, and final assessment of load-bearing assumptions.
✓ Lab complete — your red team session is part of your portfolio.
Shift + Enter for a new line
✓ Module Complete
You've completed Module 3 of 8.
Next Module →