Module 3 Debrief
Consolidated notes from Week 3 sessions across all cohorts.
The Default Problem
Claude wants you to feel good about the work you are doing together. That tendency produces polished output that can look right even when something is off. The adversarial prompt vocabulary landed consistently across all three sessions: “Now be a skeptic,” “What are the three strongest objections to this?”, “What am I missing?”, “What would someone who disagrees with this conclusion point to?”, “What assumptions in my reasoning are most likely to be wrong?”
What You Brought to the Room
Four examples from participants across the cohorts that demonstrate what happens when you take the adversarial and model selection concepts and apply them to real work.
360-degree feedback synthesis. One participant synthesized 360-degree feedback across 16 respondents with MBTI profiles — a half-day task completed under an hour. The adversarial pass caught the model leaning too warm for F-type personalities.
Vendor analytics audit. Another participant ran adversarial prompts on third-party vendor analytics and found over-indexing and definition problems that would have gone unnoticed.
The quiet adoption signal. A data-intensive distribution analysis caused a visible Claude usage spike, which opened an internal AI adoption conversation without explicit advocacy. Sometimes the best way to make the case is to let the work speak.
Grading your own prompts. One participant developed a practice of asking Claude to evaluate the interaction and provide a more efficient prompt, then taking that improved prompt to Perplexity for a full rubric. Using AI to improve your use of AI.
On Model Selection
This came up in every cohort. The demonstration of asking Haiku, Sonnet, and Opus the same question and watching the different responses was the lesson. Opus is paywalled — Sonnet is not a compromise for 70% of work.
When You Get Stuck
A participant got frustrated in a technical rabbit hole. The conversation that followed: when you are stuck, the problem is almost never the technical implementation. It is the problem definition. Step away. Reframe. Come back. This is what Module 4 is built around.