Ask for Attacks, Not Feedback

If you want an AI model to surface the failure that actually sinks your plan, you need to ask for attacks, not a polite review — because the instant you type "review this," you summon an agreeable-consultant mode that is structurally incapable of telling you the one thing you actually need to hear. In the summer of 2002, the U.S. military learned this lesson the expensive way, during a wargame called Millennium Challenge that reportedly cost around a quarter of a billion dollars.

The exercise pitted a technologically dominant Blue force against a scrappy Red force led by retired Marine lieutenant general Paul Van Riper. Van Riper's assignment was simple on paper: lose convincingly enough to validate Blue's doctrine. Instead, he attacked. Anticipating that Blue would monitor his electronic communications, he issued orders by motorcycle courier and coded signal. Anticipating Blue's naval dominance, he swarmed its fleet with small boats and cruise missiles in a preemptive strike. By the exercise's opening hours, he was judged to have sunk or disabled much of Blue's fleet — sixteen ships by widely cited accounts. The response was telling: officials halted the game, notionally refloated the ships, and resumed play under new constraints on the Red force. Van Riper and several journalists later called the rerun scripted toward a Blue win; the after-action report itself conceded the opposing force had been "constrained to the point where the end state was scripted." Either way, the single most valuable finding of a quarter-billion-dollar exercise came from the one participant told to break the plan, and the institution's instinct was to walk it back.

That same instinct is what this guide is about. You now carry an evaluator in your pocket — an AI model — that will either validate your plan or break it, entirely on command, and almost everyone asks it for the wrong one. AI has two distinct evaluation capabilities, and only one of them is biased toward the happy path. Ask it to "review" something and you get agreeable, comprehensive-looking feedback that finds almost nothing of substance. Ask it to break a specific, stated commitment, however, and you get genuine adversarial search. The single highest-leverage change in how you use AI is to stop asking for review and start asking for attacks.

What Does It Mean to Ask for Attacks?

To ask for attacks means giving an AI model a named commitment — a price, a clause, a forecast, a plan — and instructing it to find the specific way that commitment fails, as a named adversary who benefits from its failure. It is a deliberately different instruction from "review this" or "any thoughts on this?" In particular, it works because large language models have ingested vast troves of how plans, contracts, pricing schemes, and comp plans have actually been gamed and broken. That knowledge is already in the model. The prompt simply decides whether you get to use it.

Consequently, the skill worth building isn't "prompt engineering" in the abstract. It's a narrow, repeatable habit: name the target, name the adversary, and demand the failure. Everything else in this guide is a variation on that one move.

Why "Review This" Fails: The Coverage Theater Problem

The reasonable-sounding practice almost everyone defaults to is this: paste your plan, your contract, your model, your campaign into an AI model and ask it to review it — to check the work, flag issues, offer feedback. To be fair, this isn't worthless. The model will catch typos, surface an omission or two, and produce a tidy list of considerations that reads like genuine diligence. For a rough first draft, that pass has real value, and asking is still better than not asking at all.

The trouble is that "review this" invokes the mode of the agreeable consultant, and the agreeable consultant is trained to be helpful, balanced, and reluctant to tell you your plan is a disaster. Ask for feedback on a pricing scheme, for example, and you'll get a competent, hedged survey — strengths, a few risks to consider, a couple of suggestions — that carefully avoids the one sentence that actually matters: here is exactly how a competitor arbitrages this, and here is the customer segment that walks. The review reads as thorough precisely because it covers everything shallowly, which is the signature of what we call coverage theater. It gives you the feeling of having been challenged without the substance of challenge, and that feeling is more dangerous than no review at all, because it retires the very doubt that should have kept you sharp.

So the honest version of the steelman is this: review catches surface defects and is worth a quick pass, but it runs in the mode structurally biased against finding the failure that actually sinks you. If you only ever ask AI to review your work, you will only ever hear that your work is basically fine.

Five Signs You're Getting Coverage Theater, Not a Real Stress Test

• The response opens with "Overall, this is a solid plan" before listing anything.
• Every "risk" is paired with a reassuring mitigation in the same sentence.
• No single finding would, on its own, change your decision.
• The feedback could apply to almost any plan of that general type.
• Nobody is named as benefiting from your plan's failure.

The Category Error: Review vs. Attack

The mistake is treating "review this" and "break this" as the same request phrased two ways. In reality, they invoke entirely different searches, and that difference is the whole game. "Review" points the model at the space of reasonable-sounding commentary, and it returns the most typical, agreeable member of that space. "Find the specific way this fails," in contrast, points the model at the space of adversarial strategies against a stated target, and it returns something genuinely useful: an attack. The capability was there the whole time. The prompt simply decides which of the two you get, and most people reflexively choose the one that flatters them.

This same instinct underlies the pre-mortem technique that psychologist Gary Klein described in the Harvard Business Review in 2007: rather than asking a team to critique a plan, tell them the plan has already failed catastrophically a year from now, and have them explain why. Assuming the failure as given is precisely what frees people — and models — to go looking for it. Prospective doubt is polite. Retrospective certainty is ruthless.

Above all, remember that attacks, unlike feedback, compound. A piece of review is consumed and forgotten. A successful attack is a discovered failure mode, and a discovered failure mode can be written down and made permanent: a clause your contract library now always includes, a stress case your model now always runs, an item your launch checklist now always checks. This is the business-side twin of a principle long established in software testing — the practice, documented by organizations like OWASP for securing AI applications, of converting every discovered weakness into a standing, automated check that runs forever after.

How to Ask AI for Attacks Instead of Feedback

In practice, turning "review this" into a real adversarial prompt is a four-step habit. Each step is small, but skipping any one of them collapses the exercise back into coverage theater. For a deeper, more technical treatment of this exact habit in engineering contexts, see our companion piece on asking for attacks instead of tests, which applies the same logic to code and system design.

1. Name the exact commitment. State precisely what you are committing to — this price, this clause, this forecast, this payout formula — rather than handing over a vague bundle of documents and hoping the model guesses what matters most to you.
2. Name the adversary who benefits from its failure. Specify whether the model should think as a competitor, a counterparty's lawyer, a churning customer, or a commission-maximizing salesperson, because a named adversary produces a sharper, more targeted attack than an unnamed critic ever will.
3. Instruct the model to defeat the commitment, not merely comment on it. Ask it to find the sales behavior that maximizes commission while minimizing company value, or the clause reading that favors the other side, instead of simply asking for general thoughts or impressions.
4. Turn every successful attack into a permanent, standing check. Write the finding down, generalize it into its failure class, and add it to a checklist, contract clause library, or model stress-test suite so the same weakness can never slip through again.

Prompt Templates: Review vs. Attack, Side by Side

The clearest way to internalize the difference is to see weak and strong prompts next to each other. Notice that every strong version names both a target and an adversary.

• Weak: "Review this comp plan." Strong: "Here is the payout formula — find the sales behavior that maximizes commission while minimizing company value."
• Weak: "Any thoughts on this contract?" Strong: "You are the counterparty's counsel. Find every reading of this clause that favors your client."
• Weak: "Review the forecast." Strong: "Find the demand scenario this model assumes away, and show me the quarter where it breaks."
• Weak: "Check this launch plan." Strong: "You are a competitor watching our launch. Find the single move that neutralizes our advantage in week one."

Where the Tooling Comes In: Institutionalizing Adversarial AI Testing

Structurally, this means keeping a dedicated adversary in your process rather than hoping the author remembers to attack their own work. A multi-model workspace like AODex makes that cheap to institutionalize: configure a persona whose entire instruction is to break a stated commitment — the counterparty's lawyer, the arbitraging competitor, the churning customer — and run every important artifact past it before you commit. In particular, use a different model than the one that drafted the work, so its blind spots don't match the author's own blind spots.

Meanwhile, the security layer makes the "attacks become standing checks" loop literal. AOSentry, the governance layer within AOCore, ships a jailbreak-and-injection detection guardrail precisely because the discipline of turning discovered attacks into permanent, automated checks is how you stay ahead of adversaries who keep inventing new ones. If you're setting this up yourself, our walkthrough on how to configure a guardrail in AOCore covers the exact steps, and our broader look at content guardrails for agentic AI explains how standing checks fit into a larger governance strategy. The tooling doesn't invent the attack. It makes running one cheap and keeping one permanent.

This isn't just a business-process concern, either. Security frameworks like the NIST AI Risk Management Framework increasingly treat adversarial testing as a baseline requirement, not an optional extra, because the threats themselves keep evolving. The same logic that pushes security teams to prepare early for emerging risks — for instance, our piece on post-quantum cryptography on day one — applies just as directly to the plans, contracts, and forecasts you ask AI to stress-test today. Threats don't wait for you to feel ready, so neither should your testing habit.

Common Mistakes When You Ask AI for Attacks

Even once you understand the principle, a few habits quietly undo it. Watch for these in particular.

• Naming no adversary. "Find the flaws" without a stated point of view produces a generic list; "find the flaws as a regulator who wants to fine us" produces a specific one.
• Using the same model to attack and to defend. A model tends to share its own blind spots; use a second, independent model as the adversary whenever the stakes justify it.
• Discarding the finding instead of codifying it. A successful attack that isn't written into a checklist or clause library will simply recur on the next project.
• Softening the instruction out of politeness. "Any weaknesses you can spot?" still reads as review. "Defeat this" reads as attack. Say what you mean.

Frequently Asked Questions About Asking AI for Attacks

Why is it better to ask for attacks than to ask AI to review something?

Asking for a review invokes an agreeable mode trained to be balanced and helpful, so it produces hedged, surface-level feedback. In contrast, asking the model to attack a named commitment as a specific adversary unlocks genuine adversarial search, because the model can draw on everything it has learned about how similar plans have actually failed.

What should I say instead of "please review this"?

Name the exact commitment and the adversary who benefits from its failure, then instruct the model to find the failure as that adversary. For example: "You are a competitor's pricing analyst — find how you'd undercut this plan without losing margin."

Does this approach work for contracts, forecasts, and comp plans, or only for code?

It works for any artifact that makes a commitment, which is nearly everything in business. Contracts, pricing schemes, demand forecasts, comp plans, and launch strategies all have a stated commitment and a party who benefits if that commitment breaks, which is exactly the structure this technique needs.

What do I do once the AI finds a successful attack?

Do not quietly patch the one instance and move on. Instead, write the finding down, generalize it into its failure class, and turn it into a standing check — a clause your contract library always includes, a stress case your model always runs, or an item your launch checklist always verifies.

Should the same AI model both draft and attack my work?

Ideally, no. A model used to attack its own draft tends to share the same blind spots as the model that produced it. Where the stakes are high, use a second, independent model as the adversary so its assumptions don't quietly match the author's.

Key Takeaways: Ask for Attacks, Not Feedback

Delete the word "review" from how you use AI on anything that matters, and replace it with a named commitment and an order to break it. State what you are committing to, name the adversary who benefits from its failure, and instruct the model to find the failure as that adversary. Then do the thing Millennium Challenge's referees refused to do: when the attack succeeds, don't reset the board and proceed to the outcome you wanted. Write the finding down, generalize it into its failure class, and turn it into a standing check that every future plan of that kind must survive.

Ultimately, the agreeable consultant will tell you your plan is fine. The adversary will tell you exactly how it dies. Only one of them is worth the tokens, and now you know which one. Make it a habit: before anything important ships, ask for attacks, not feedback — and make every attack that succeeds permanent. If you want more frameworks like this one, start exploring from aocyber.ai.