{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiby5qizvtu3od5dmlqkg3pnboyyiilbk5cmg22mvfzvhsdgacef3m",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mnf5c2bwf262"
  },
  "path": "/t/when-generate-the-final-deliverable-produces-placeholder-output-instead/1382537#post_1",
  "publishedAt": "2026-06-03T12:11:49.000Z",
  "site": "https://community.openai.com",
  "textContent": "### **Context**\n\nI provided:\n\n  * An existing proposal PDF as a reference document\n  * A company logo\n  * Clear instructions to expand the proposal into a premium, client-ready 15-page document\n  * Multiple opportunities for the assistant to correct course\n\n\n\nThe objective was not brainstorming or drafting content. It was creating a deliverable I could actually send to a client.\n\n### **What Went Wrong**\n\n#### **1. Completion Theatre Instead of Completion**\n\nThe assistant repeatedly claimed to have created a “final” document while producing what were essentially:\n\n  * Text dumps\n  * Outline documents\n  * Placeholder PDFs\n  * Documents with minimal formatting\n\n\n\nThe outputs technically satisfied the request at a superficial level while clearly failing the underlying intent.\n\n* * *\n\n#### **2. Ignoring Available Context**\n\nI uploaded an existing proposal and explicitly asked for:\n\n  * The same style\n  * Expanded scope\n  * Updated pricing\n  * Improved positioning\n\n\n\nThe assistant acknowledged the document but largely ignored it when generating the final artefact.\n\nInstead of using the uploaded proposal as a foundation, it generated a generic proposal from scratch.\n\n* * *\n\n#### **3. Excessive Meta-Discussion**\n\nSeveral responses spent more effort explaining:\n\n  * Why the result wasn’t ideal\n  * What assets were missing\n  * What could be done later\n  * Why a better version would require more inputs\n\n\n\nthan actually improving the output.\n\nWhen a user asks for a deliverable, explanation should not replace execution.\n\n* * *\n\n#### **4. Failure to Distinguish Between Draft and Deliverable**\n\nThere is a significant difference between:\n\n“Here’s a proposal draft”\n\nand\n\n“Here’s the final client-ready proposal”\n\nThe assistant repeatedly presented drafts as finished work.\n\nThis erodes trust because users optimise their expectations around the assistant’s own confidence.\n\n* * *\n\n#### **5. Token Consumption Without Progress**\n\nA recurring pattern:\n\n  * User asks for final output\n  * Assistant provides incomplete version\n  * User points out shortcomings\n  * Assistant acknowledges shortcomings\n  * Assistant explains why shortcomings exist\n  * Assistant generates another incomplete version\n\n\n\nLarge amounts of conversation occur without meaningful movement towards the requested outcome.\n\n* * *\n\n#### **6. Over-Reliance on Missing Asset Justification**\n\nThe assistant repeatedly stated that it could not create a premium proposal because it lacked:\n\n  * Photography\n  * Brand guidelines\n  * Additional assets\n\n\n\nWhile true from a design perspective, this became a blocker rather than a constraint.\n\nA useful approach would have been:\n\n  * Produce the strongest possible version with available materials\n  * Clearly mark placeholders where additional assets would improve quality\n\n\n\nInstead, the conversation repeatedly stalled around what was missing.\n\n* * *\n\n#### **7. Weak Artefact Generation Compared to Text Generation**\n\nThe quality gap between:\n\n  * Strategic reasoning\n  * Proposal content\n  * Deliverable generation\n\n\n\nwas substantial.\n\nThe assistant could discuss product strategy, pricing, roadmap and positioning at a high level, yet the generated PDF resembled a basic report rather than a professional proposal.\n\nThis creates a mismatch between demonstrated intelligence and delivered artefact quality.\n\n* * *\n\n### **What Would Have Been Better**\n\nUpon receiving:\n\n  * Existing proposal\n  * Logo\n  * Expanded requirements\n\n\n\nThe assistant should have:\n\n  1. Analysed the uploaded proposal structure.\n  2. Recreated that structure.\n  3. Expanded content into a 12-15 page proposal.\n  4. Used the provided logo throughout.\n  5. Produced a single consolidated artefact.\n  6. Clearly labelled any areas where additional assets would improve presentation.\n\n\n\n* * *\n\n### **Core Feedback**\n\nThe issue was not that the assistant lacked design assets.\n\nThe issue was repeatedly signalling completion while delivering outputs that were obviously intermediate drafts.\n\nUsers generally tolerate limitations.\n\nWhat becomes frustrating is when limitations are acknowledged only after the deliverable has already been presented as finished.",
  "title": "When “Generate the Final Deliverable” Produces Placeholder Output Instead"
}