# Tricks for Using AI Well > Source: > Published: 2026-07-12 13:38:23+00:00 *Operational flow of the **Chain-of-Verification (CoVe) method**. A structured four-step prompting strategy to mitigate hallucinations in LLMs by generating control questions and cross-verifying them in isolation.* The model discovers inconsistencies that it would overlook in the integrated version. **The separation between generating and verifying is what makes it work**: if you ask for everything at once in a single prompt, the model “looks at” its own response and confirms what it already said, perpetuating the same error. Step 3 is the critical one: the verification questions are answered without seeing the original response. Does the CoVe method not resemble Spec-Driven Development (where the API is designed, defined, and validated in a specification before a single line of code is written; seeGoodbye Agile, Hello Specification-Drivenin saga 2)? They do resemble each other: in both cases the idea is to define the correctness criteria before executing, rather than generating and accepting at the same time. But CoVe is a prompting technique to reduce hallucinations in any factual text; Spec-Driven is a process methodology for software. Same principle, different scope. Using AI well calls for a four-phase cycle, not a single prompt: The typical mistake is jumping directly from step 1 to step 4 while skipping step 3, or iterating between 1 and 2 without any genuine refinement. The patterns below improve specific points in this cycle. [A Harvard Business School study](https://pubsonline.informs.org/doi/10.1287/orsc.2025.21838) with 758 Boston Consulting Group consultants (Dell’Acqua et al., published in *Organization Science* in 2026) introduced the concept of the **jagged technological frontier**. The idea: AI is not uniformly good or bad. There are tasks in which it outperforms the average human, and tasks in which it produces results worse than those of an unassisted human. What makes the frontier “jagged” is that those two categories do not separate by difficulty or task type in any predictable way — they can sit side by side in the same workflow. For tasks **inside the frontier**: consultants with AI completed **12% more tasks**, **25% faster**, at **40% higher quality** than the group without AI. For the task designed specifically to fall **outside the frontier**: humans without AI solved it correctly **84% of the time**; consultants with AI dropped to **60–70%**, because they tended to accept the model’s answer even when it was plausibly wrong. The most uncomfortable finding was not the performance gap: it was the **persuasion problem**. When participants spotted the error and pressed the model to correct it, the model did not back down. It apologized, adjusted surface details, and returned to defending the same wrong position with new, more elaborate arguments. More apparent confidence — same underlying error. *Conceptual diagram. The frontier is “jagged” because apparently similar tasks can fall into different quadrants. This does not represent data from the BCG study: it illustrates the concept from Dell’Acqua et al. (2026).* The practical lesson: **before optimizing the prompt, ask yourself whether the task is the type in which AI has a good chance of succeeding.** Signals that you may be outside the frontier: the problem requires very specific or local data unlikely to be in the training corpus, the correct answer depends on context the model does not have, or the result looks plausible but you cannot validate it easily. In those cases, AI helps more as a verifier of your own solution than as the author of the answer. The first mistake almost everyone makes is starting with the question. *“Write me an article about X.” “Give me a report on Y.”* The model does its best without context, which is to generate an average response for that type of request. The result is generic, bland, and interchangeable. The difference comes from **giving the model all the relevant context before asking for anything**: the audience, the tone you use, the objective, what background information already exists, and what to avoid. This might take ten lines before your question — or it might be so concise that you have practically written the answer yourself. The Wharton research (2025) confirmed that **structure and prompt format are the most consistently beneficial variable** among everything they tested. Politeness (“please,” threats, flattery) had dramatic effects on individual questions but balanced out at scale; structure did not: it helped consistently. A before-and-after example: Before:“Write me an email introducing our services to a new client.” After:“You are my writing assistant. I am drafting an email to the head of innovation at a mid-sized pharmaceutical company, whom I met at a conference a week ago. He is interested in clinical data analytics but has expressed skepticism about consulting firms that promise magical AI. I want to present our services without sounding like a sales pitch, and I am offering a first conversation for free. My usual tone is direct, brief, and jargon-free. Avoid superlatives and phrases like ‘innovative solutions.’ Here is the first draft I wrote — tell me what you would improve and propose a final version: [draft]” The rule of thumb: **if what you are sending the model fits in a single tweet, it almost certainly lacks context.** And if your prompt — combining context, instructions, and background material — is longer than the response you expect, you are on the right track: you have done the work of defining the frame. One technical detail worth knowing: models perform worse on information placed in the **middle** of the context than at the beginning or the end. The phenomenon is called *“lost in the middle”* ([Liu et al., 2023, published in TACL 2024 and replicated in 2025 across 18 different models](https://arxiv.org/abs/2307.03172)). The drop in performance when you bury relevant information in the middle of a long prompt can exceed 20%. Practical consequence: if the context you provide is long, put the main instructions and the most critical information at the **beginning** or **end** — not buried in the middle. *Approximate U-shaped curve based on Liu et al. (TACL 2024). Exact values vary by model and task; the degradation pattern at the middle is the consistent finding.* Current models process a request more effectively when they know exactly what format is expected in the response. Three concrete tools: **XML tags for large blocks.** When you pass the model a long piece of text (an article to review, a transcript, code), wrap it in a clear tag: … . The model treats what is inside as “material to process”; everything outside is the instruction. It sounds bureaucratic, and it works. It is in the official [Anthropic documentation](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#structure-prompts-with-xml-tags) because the effect is real and replicable. **Few-shot examples for output format.** If you want a specific type of output (a table with that number of columns, a particular executive-summary style, a specific level of detail), paste one or two examples of the result you want before asking for the real one. Modern models are competitive at accuracy with zero-shot, but examples remain the most effective way to communicate the desired format. If format matters, provide examples. **Prefilling, or the started response.** A lesser-known technique: you can indicate the first words of the response you expect, and the model continues from there. *“Begin your response with: The main problem is…”* — this eliminates preambles (“Sure! Of course I’ll help you…”) and sets the tone from the first token. Especially useful for technical reports or executive summaries where the opening paragraph determines the tone of everything that follows. For years, the standard recommendation was *“add ‘think step by step’ to your prompt.”* [In 2022, that advice drew on real chain-of-thought (CoT) techniques](https://gail.wharton.upenn.edu/research-and-insights/tech-report-chain-of-thought/) that significantly improved performance on mathematical and logical reasoning. The problem is that the field has changed. [In 2025, Wharton published “The Decreasing Value of Chain of Thought in Prompting.”](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5285532) The conclusion: **with modern reasoning models** (the reasoning series from OpenAI, Gemini Flash 2.5, [Claude with extended thinking](https://www.anthropic.com/news/visible-extended-thinking)), adding explicit CoT instructions does not improve results and can even degrade them, because the model already reasons internally by design. With more basic models or on non-analytical tasks, explicit CoT still helps somewhat (5–13% improvements depending on the model). With reasoning models, it adds latency with no benefit. *Data from **Wharton, The Decreasing Value of Chain of Thought in Prompting**. The first three are standard models; o3/o4-mini and Gemini Flash 2.5 are extended-reasoning models. The improvements for GPT-4o-mini and o3/o4-mini are not statistically significant.* In other words: telling a model that already reasons extensively to “think step by step before answering” is redundant at best and a distraction at worst. **What does have solid backing for any model** is the “step back” instruction, known as **step-back prompting** ([Zheng, Mishra, Chen et al., Google DeepMind, arXiv:2310.06117](https://arxiv.org/abs/2310.06117)): before attacking the specific problem, ask the model to articulate the general principles or conceptual framework that apply. The flow is: Note for those coming from the AI development world: Does this not resemble the Planning phase (where the LLM breaks the request into tasks) and Execution (where the agent or agents carry them out)? It is not the same thing. Step-back prompting asks the model to pause and find the underlying principle or theory — it orders the model to study and understand the subject before performing the task. Verified improvements of 7 to 34 percentage points depending on task type (STEM, knowledge QA, multi-step reasoning). The technique works because it first activates the relevant general context before entering the specific case. **Chain-of-Verification (CoVe) for factual answers** ([Dhuliawala et al., Meta, arXiv:2309.11495; ACL 2024](https://arxiv.org/abs/2309.11495)). To reduce hallucinations in factual responses, the flow has four steps: *Operational flow of the **Chain-of-Verification (CoVe) method**. A structured four-step prompting strategy to mitigate hallucinations in LLMs by generating control questions and cross-verifying them in isolation.* The model discovers inconsistencies that it would overlook in the integrated version. **The separation between generating and verifying is what makes it work**: if you ask for everything at once in a single prompt, the model “looks at” its own response and confirms what it already said, perpetuating the same error. Step 3 is the critical one: the verification questions are answered without seeing the original response. Does the CoVe method not resemble Spec-Driven Development (where the API is designed, defined, and validated in a specification before a single line of code is written; seeGoodbye Agile, Hello Specification-Drivenin saga 2)? They do resemble each other: in both cases the idea is to define the correctness criteria before executing, rather than generating and accepting at the same time. But CoVe is a prompting technique to reduce hallucinations in any factual text; Spec-Driven is a process methodology for software. Same principle, different scope. The lazy user’s trap: accepting the first response. The anxious user’s trap: blindly regenerating by saying “again.” What works lies between them: **read the output, identify the two or three things that do not quite work, and return specific instructions**. Refinement patterns that save time: This last one is especially useful. It is the same model, so it is not external review — but in the second critical pass it detects things it overlooked in the first generation. A useful reliability signal: **if something matters, ask the same question in two or three different ways and compare the responses.** If they converge, there is a basis for confidence. If they diverge significantly, the model is operating in genuinely uncertain territory. This is the principle behind [ self-consistency (Wang et al., 2023)](https://arxiv.org/abs/2203.11171): sample multiple responses and keep the one with the most agreement among them. Variance between responses is a signal of reliability, not creativity. Is “self-consistency” not similar to “LLM-as-a-Judge”? No: in self-consistency, a human guides the model to self-correct; LLM-as-a-Judge in a professional setting is an automated process where a judge AI issues a final verdict or score to measure a system’s performance — not to chat. The next pattern is a manual LLM-as-a-Judge (the professional version is automated). If you have access to two different models (ChatGPT and Claude, Gemini and Claude, etc.), **use one to critique what the other produces**. Pass model A’s draft to model B with instructions to critique it rigorously. Take the critiques, filter them, and go back to A with specific improvement instructions. The reason it works: each model has different training biases. What model A considers good — because it fits its preferred patterns — model B may detect as weak. In software development, this architecture is formally called *LLM-as-a-judge* ( [Zheng, L. et al., NeurIPS 2023, arXiv:2306.05685](https://arxiv.org/abs/2306.05685)). In general use, you are simply running anything important through two pairs of synthetic eyes before one. *Cross-validation architecture (LLM-as-a-judge). Inserting a second model with different training biases during the critique phase breaks the original model’s self-satisfaction and ensures a more rigorous evaluation before final refinement.* For the technical use of this pattern in code, there is a specific article in saga 2: [Double agent and LLM-as-judge](https://jarroba.com/en/tricks-for-using-ai-well/URL_PENDING_ENGLISH). This is the version for any trade. Once you have something that looks good, **before sending it to its final destination**, do a manual pass with this checklist: Five minutes catch most of the problems that can damage your reputation if they slip through to the destination. One important detail from the jagged frontier study: **the model scales up its confidence when challenged.** If you detect an error and point it out, the model may not say “you are right, I was mistaken” — instead, it may adjust surface details and return to defending the same position with more arguments and more detail. That looks like greater competence; it is not. The model’s apparent confidence does not correlate with its accuracy. If something does not ring true, the solution is not to ask the same model again: it is to go to the source. A widely spread recommendation is to open your prompt with “act as an expert in X” or “you are a senior consultant on Y.” The intuition is that the model will adopt the expert’s mental framework and produce more precise answers in that domain. The research Wharton published under [“Playing Pretend: Expert Personas Don’t Improve Factual Accuracy”](https://arxiv.org/abs/2512.05858) (Basil et al., arXiv:2512.05858) says otherwise. They tested six models with graduate-level questions (GPQA Diamond, MMLU-Pro) under different personas: domain experts, laypeople (ignorant of the subject), and young children. Examples: Result: **no expert persona consistently improved factual accuracy.** Some non-domain personas **worsened** it. Low-knowledge personas (layperson, child) reduced it significantly. What does work with role prompting is **tone and communication style**. If you ask the model to adopt the voice of someone who writes directly and without jargon, the output changes usefully. If you ask it to be a ruthless editor, the output becomes more critical. Those instructions work because they concern form, not factual knowledge. The practical distinction: for **how it communicates**, roles help; for **the accuracy of what it says**, they change nothing relevant. The effective instruction is not “you are an expert quantum physicist.” It is “explain the mechanism in technical language for a physicist, without simplifications, without an introduction, focused on the formalism.” Comparative example: It is like asking an actor to portray different professionals — a doctor, a historian, an architect, or a psychologist. The actor holds exactly the same information in their mind regardless of whom they portray; the role only changes the façade and the surface vocabulary without providing knowledge they do not have. By contrast, if you ask the actor to adopt a more serious, direct, or cheerful attitude, that fully transforms how they communicate (if cheerful, they might decide it is a good day to help others; if sad, they might decide to cry in their room instead). In long working sessions, accumulated context can work against you. Two concrete problems: **Contaminated context.** If in the opening messages of the session you gave wrong instructions or started from an incorrect framing, the model will carry those forward throughout the conversation. Sometimes the most efficient solution is to open a new session with a clean summary of what has worked, rather than continuing to iterate on a poorly constructed context. **Diluted signal.** As the conversation grows, the most recent instruction competes with everything that came before. The degradation is real: the “lost in the middle” phenomenon applies to long conversations too, not just to individual prompts. If the model seems to be ignoring recent instructions, they may be competing with too much noise from accumulated context. The solution: summarize the current state explicitly at the start of your next message, before the new request. **The clean-context rule:** [Anthropic’s documentation puts it well — the goal is “the minimum set of high-signal tokens that maximizes the probability of the desired outcome”](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). More context is not always more useful. Well-chosen context is. The eight mistakes that are hardest to fix once they have become habits: **1. Accepting the first output without reading it.** AI produces both true and invented content with equal confidence. Accept output after reading it, not before. **2. Copying viral prompts from the internet without understanding them.** The Wharton study (2025) documents this empirically: the effect of prompt variations is inconsistent and contingent. The prompt that worked for someone else, with a different model, on a different question, may not work in your case — or may actively hurt it. **3. Treating AI as a data search engine.** *“Find me X”* is not what it does best. *“Give me different perspectives on X and the three strongest arguments for each”* is. If you want verifiable data, use primary sources; if you want to think better with assistance, use AI. **4. Not declaring the type of output you want.** If you want a five-paragraph email, say so. If you want a table, say so. If you want a cold, professional tone, say so. The AI improvises the format if you do not specify it — and by pure probability, it almost always improvises wrong for your context. (If you ask a stranger to write you a letter, the first thing they will ask is: “About what, and for whom?” To improvise by picking at random from all existing professions and an infinite number of possible motives is nearly impossible to get right.) **5. Not keeping intermediate versions.** If you suddenly realize that version 2 was better than version 4, you want to have it saved. Chats get lost; versioned documents do not. **6. Assuming the model remembers yesterday’s session without checking.** Tools like Claude with Projects, ChatGPT with Memory, or GitHub Copilot Workspace do retain context when configured to do so. In a new conversation without that feature active, the model starts from zero. Verify which mode you are using before assuming anything is already known. **7. Trusting the model more when it sounds more confident.** Model confidence does not correlate with accuracy. After the model defends an incorrect position with more arguments and more detail, the answer is still incorrect ( [Argumentum ad verecundiam, or appeal to authority](https://en.wikipedia.org/wiki/Appeal_to_authority)). Apparent confidence is a training artifact, not a signal of truthfulness. **8. Adding “act as an expert in X” expecting it to improve accuracy.** Research (Wharton, 2025) shows that expert personas do not improve factual accuracy and can worsen it if they do not match the exact domain of the question. For accuracy, provide specific context about what you want; save the role for tone and style. Almost all AI content on the internet is the same article rewritten. For those who want verified information, these are the sources worth knowing: **Research with formal review:** **Labs (their own blogs and documentation):** **Quality empirical reports:** **Red flags for filtering the noise:** Using AI well is not about magic prompts. The Wharton data are clear: there are no universal formulas, and effects vary by model, question, and context. What there are is patterns that work consistently: rich context before the question, explicit format specification, reasoning asked for only when the model needs it, specific iterations instead of blind regeneration, real verification before any handoff, and judgment about when AI helps and when it produces results worse than the unassisted human. The biggest obstacle is rarely technical. It is **the tendency to accept the plausible as the true** when the model states it with confidence and detail. That habit is more costly than any badly constructed prompt. One note on the practical implications: technical interviews have already started to change. [Canva](https://www.canva.dev/blog/engineering/yes-you-can-use-ai-in-our-interviews/), [Meta](https://www.metacareers.com/hiring-process/), and a growing number of companies have reformed their process to evaluate how a candidate works *with* AI in real time, not whether they know theory about it. In 2026, most tech job postings mention AI tools. The patterns in this article are not just productivity practices: they are the foundation of what will soon be observed and valued in an interview. No model is good enough that it does not need review. And no prompt is well-built enough to guarantee the correct answer. What there is, is practice with judgment. [ ← Previous article: How to avoid being replaced without selling out to AI](https://jarroba.com/en/how-to-avoid-being-replaced-without-selling-out-to-ai/) · [Tricks for Using AI Well](https://pub.towardsai.net/tricks-for-using-ai-well-jarroba-4857e82ccbda) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.