Here is a failure mode that ships more often than it should. The model that writes an output is also the model that checks it. You send the result back with "review this and flag anything weak," and the review skews toward approval, because a model reviewing its own work shares its own blind spots. This is a documented limitation, not a hypothesis. It is not universal. Plenty of teams already run multi-step pipelines, separate critic models, and output validators. But self-review as the only quality gate is still common, and for enterprise-grade output, where a confident wrong answer is a liability, it is worth solving properly. This post is how we approached it, where the design is genuinely sound, and where it is not. I want this community to review both. Why self-review is weak Two things work against a single model checking itself. The first is autoregressive momentum. A model picks each word partly from the words it already wrote, so the opening of an output conditions everything after it. A model that has generated thousands of reports has a strong format prior: summary, background, analysis, recommendation. Your spec might say to lead with the competitive threat and drop the background. That instruction competes with the prior, and a few sentences in, the prior often wins. The output looks like a report. It is not your report. The second is that evaluation has a prior too. In training data, reviews of polished work skew positive, so a model asked to "evaluate this" leans toward approval. A reviewer that is the same model, or the same model family, shares the writer's biases. Here is the honest version of the claim, and it is less dramatic than how this is usually sold. Prompting is not powerless, it is unreliable as your only quality control. Self-critique does catch real errors. It just catches fewer than an independent reviewer would, and you cannot tell from the output which case you got. So you do not throw prompting away. You add structure around it.

💰 $500 CASH 💰 Win this and you've covered a year of Premium with $175 left over. 📋 THE CHALLENGE Build a folder-based AI coach for a specific domain. You pick the domain. This week's deliverable is one coach folder that someone could drop into a Claude project and use as their personal coach for whatever you've built it for. 🎯 PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 🎤 Public speaking coach for new managers giving their first big presentations - 💼 Salary negotiation coach for tech workers at Series A startups - 📞 Cold call coach for first-year SDRs in B2B software - 🎯 Interview prep coach for product manager roles - ✍️ Writing coach for one specific genre (sci-fi short stories, college essays, op-eds) - 🏋️ Fitness form coach for one movement (squat, deadlift, golf swing) - 🌍 Language learning coach for one use case (medical Spanish, business Mandarin) - ♟️ Chess coach for one specific opening or endgame pattern - ⚽ Youth athletics coach for one sport and age group The more specific, the better. "Life coach" is too broad. "Salary negotiation coach for tech workers at Series A startups" is right. 🗂️ THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning the foundation of interpretable context methodology. Folders as architecture. Each file does one job well. Your coach is a folder with five things: - 📄 identity.md (who the coach is) - 📐 rules.md (how they coach) - 💬 examples.md (what good looks like) - 📚 reference/ (frameworks, drills, source material) - 📖 README.md (how to use it) Drop the folder into a Claude project. Claude becomes the coach. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A coach is NOT a knowledge base. A coach gives feedback. Pushes back. Asks better questions. Holds people accountable.