I Spent 200 Hours Teaching AI Writing—Here Are 6 Principles Everyone Gets WRONG (+ Demo Prompt)

AI-assisted business writing is getting cheaper, but the quality problem isn’t a lack of writing ability—it’s a lack of organizational clarity about what “good” looks like. The real bottleneck isn’t AI capability. It’s whether a company can translate tacit, “I know it when I see it” standards into explicit, testable requirements that can be encoded into prompts. Without that structure, AI doesn’t reduce ambiguity; it amplifies it—often by adding plausible-sounding detail that makes vague documents even harder to evaluate.

That shift forces a new workflow: treat writing like product requirements, not like an art exercise. Successful organizations can’t rely on templates alone. Templates fill in boxes; they don’t provide the business logic, decision interface, or intent that a document is meant to support. If a prompt only supplies a format, the model will dutifully populate the format while missing the underlying goal—leading to the familiar failure mode where outputs look “filled in” but still useless. The fix is to specify the document’s purpose in terms of goals and decisions (what person X needs to decide), define the structure as logic, and make evaluation scalable.

Evaluation is a second major constraint. Knowledge work produces too many artifacts to manually review everything, so businesses need to scale assessment rather than just generation. The approach described is to move AI onto the evaluation side as well—using AI to run quality checks against clear criteria. That requires “failure tests”: concrete examples of what goes wrong in a given document type. Instead of only describing desired traits, teams should provide 5–7 examples of common quality problems (e.g., overspecifying architecture that doesn’t match reality, writing press releases that overhype capabilities, or producing executive summaries that are too vague). These examples help the system distinguish between acceptable and unacceptable outputs.

The guidance also highlights information architecture issues that AI exposes. Documents often fail because they aren’t written for decisions or because their structure doesn’t reflect the business logic needed to act. AI makes those information asymmetries harder to hide; it forces organizations to critique more directly, which the guidance frames as a healthy correction. Another subtle dynamic is “default voice” convergence: AI tends to produce diplomatically hedged, bland prose that can’t carry conviction across both certainty and uncertainty. If teams don’t override that default, they risk losing the specificity needed for real decision-making.

Finally, the transcript argues that iteration diagnosis matters: teams often try to “make it better” without knowing how to iterate, because intent isn’t specified clearly enough to guide revision. A practical demonstration follows with a high-bar prompt for meeting notes. It requires specific fields (contacts, date, attendees, purpose, transcript input), a decision/action-oriented structure (decisions, action items with named owners, open questions, key discussion points), strict constraints (no pleasantries, no inference or guessing), and validation checks that block output if any decision lacks a decision maker or any action item is vague. The contrast is stark: generic summaries may read cleanly but fail to support execution, while intent-driven notes become actionable business intelligence.

The takeaway is blunt: humans still have to define intent and quality standards for AI. But doing so can replace inconsistent “best human writer” benchmarks with a consistent, measurable bar—reducing AI slop and making writing outputs reliably useful. The alternative, the transcript warns, is an endless flood of low-signal documents because AI generation is easy and adoption won’t slow on its own.