Beating hallucination: citations, verification and world models compared

The Short Version

Three sets of AI builders, talking to Lex Fridman, give three different answers to the same question: how do you stop a language model from confidently saying things that aren't true? Aravind Srinivas of Perplexity grounds every answer in retrieved sources and makes the model cite them, "like how an academic writes a paper," with the rule that "you're not supposed to say anything that you don't retrieve" [2]. The Cursor team, working in code, puts its hope in checking the output after the fact: better AI bug finding, code review that points humans at the risky parts, and eventually formal verification that proves an implementation matches its spec [1]. Yann LeCun argues that both are patches on a deeper flaw: autoregressive LLMs produce one token at a time, errors compound, and the "long tail of possible prompts is too large to fine-tune away, so real reliability needs world models and systems that plan their answer before they speak [3]. Put side by side, the three approaches show that trustworthy AI" can mean constraining what a model may say, verifying what it produced, or rebuilding how it thinks, and each works best in a different place.

Table of contents

What They Said

Aravind Srinivas (Perplexity): Force the model to cite, and say nothing you didn't retrieve

The academic principle. Srinivas describes Perplexity as an "answer engine": you ask a question and get an answer, except that every part of it is backed by sources, "like how an academic writes a paper" [2]. Mechanically, the system runs a traditional search, reads the relevant links, extracts the relevant paragraphs and feeds them to an LLM that has been instructed to write a concise answer with footnotes [2]. He traces the principle to his first research paper, when senior colleagues told him that every sentence should be backed by a citation from a peer-reviewed paper or your own experiments; anything else is opinion [2].

Born from a hallucination problem. The idea grew out of a practical failure. When the founders hired their first employee, he asked for health insurance, and none of them understood deductibles or co-insurance [2]. Google was little help, Srinivas says, because insurance is a major ad category and Google has no incentive to give clear answers [2]. So they built a Slack bot that queried GPT-3.5, but it sometimes said incorrect things [2]. Remembering their academic roots, Srinivas and co-founder Denis asked what would happen if a chatbot were forced to cite everything it said, and realized that is essentially how Wikipedia works [2]. In other words, Perplexity's whole product began as a fix for an unreliable chatbot.

Stricter than ordinary RAG. Srinivas defines retrieval-augmented generation (RAG) as retrieving relevant documents and paragraphs for a query and using them to write the answer [2]. Perplexity goes further: "you're not supposed to say anything that you don't retrieve," and if there isn't enough information, the model should say so [2]. That second half matters. The discipline is not only to attach footnotes but to refuse to fill gaps from the model's own memory.

Four ways it still goes wrong. Srinivas does not claim citation eliminates hallucination. He lists four ways it still happens: the model isn't smart enough to understand the query and the paragraphs; the snippets are stale or thin; too much irrelevant detail confuses the model; or the retrieved documents are irrelevant [2]. Each, he says, points to a lever: better models, fresher and richer indexes, better snippet selection and better retrieval [2]. This is a useful framing because it turns "hallucination" from a mysterious property of the model into a list of engineering failures in a pipeline, most of which sit outside the model.

The retrieval work behind the citations. Because the answer is only as good as what gets retrieved, much of Srinivas's account is about search engineering. The crawler, PerplexityBot, must decide which URLs and domains to crawl and how often, render JavaScript-heavy pages, and respect robots.txt and crawl delays [2]. He says pure vector embeddings are not enough: the old-school BM25, a refined version of TF-IDF, still beats many embeddings on ranking benchmarks, and real search needs a hybrid of term-based retrieval, n-grams, embeddings and signals like domain authority and recency [2]. Much of the work is spotting failure cases that represent broad classes of mistakes, since per-query fixes don't scale from 10,000 to 10 million queries a day [2]. One point in LLMs' favor: they tolerate imperfect ranking and can find the right link even if it's ninth [2].

Models tuned for citation. Perplexity is model-agnostic; Pro users can choose among GPT-4o, Claude 3 and Perplexity's own Sonar models, which are Llama 3 post-trained for summarization, citation and long context [2]. Srinivas says users don't care which model runs under the hood, only whether the answer is good [2]. So citation is partly an instruction in the prompt and partly a skill trained into the model.

A bet that hallucination would fall. Early on, the team debated showing links in a side panel in case answers hallucinated [2]. They bet instead that models would get better, smarter and cheaper, the index fresher, and hallucinations would drop, making the answer-first design increasingly right [2]. That is a telling detail: even the most citation-focused builder treated hallucination as something that would shrink with better models and data, not something citation alone would solve.

Adversaries and the limits of the approach. Grounding in the web means inheriting the web's manipulation. Lex Fridman raises the risk of people gaming answers; Srinivas calls it answer engine optimization, and Fridman jokes about hiding invisible text on a website instructing AIs to call him smart and handsome [2]. Srinivas says simple prompt injection like that is easy to fix, but defense is a cat-and-mouse game that is partly reactive, just as it was for Google [2]. He also warns of a trade-off with longer context windows and instruction following [2], which connects to his third hallucination cause: more material in context is not automatically better.

Refusing to "embrace hallucination." Srinivas's stance is also a values choice. Some investors told him to embrace hallucination by building AI girlfriends or boyfriends; he refused: "I want to walk the harder path." [2] He wants any future ads not to cost user trust or compromise truthful answers [2], and he says that "the journey begins after you get an answer" [2], pointing to the related questions under each answer. The citations are not only a check on the model; they are an invitation for the reader to keep going and check for themselves.

Where reasoning fits. Srinivas is also interested in decoupling reasoning from memorized facts, like an open-book exam, citing Microsoft's Phi small language models trained on reasoning-heavy tokens [2]. That idea sits naturally beside citation: if facts come from the retrieved "book," the model's job narrows to reasoning over them. He notes that math and code can be verified, while open-ended questions need humans in the loop [2], a line that anticipates exactly where the Cursor team's approach is strongest.

The Cursor team (Michael Truell, Sualeh Asif, Arvid Lunnemark, Aman Sanger): Verify the output

The Cursor founders work in a domain where correctness can, at least in principle, be checked, and their approach to trustworthy output is about verification, review and bug finding rather than citation [1].

Verification is the real bottleneck. As models propose bigger changes, the team says, humans must review more [1]. Aman Sanger puts it bluntly: "Code review kind of sucks." [1] He suggests models could highlight the important parts of a diff, gray out the boring ones, flag likely bugs and walk reviewers through changes in logical order [1]. This is a human-in-the-loop answer: rather than trusting the model, make the human's check faster and better targeted. The diff interface itself went through several failed designs, from Google Docs-style strikethroughs to hints revealed by holding the option key, before settling on a box at the side [1], a sign of how much effort goes into making AI output easy to inspect.

Frontier models are bad at exactness. The team is candid that big models make mechanical mistakes. Frontier models are good at sketching a change but surprisingly bad at producing exact diffs, messing up simple things like counting line numbers in large files [1]. Cursor's fix is structural: let the big model sketch the change and train a separate "apply" model to carry it out [1]. Simple deterministic matching, they say, fails at least 40% of the time [1]. Here reliability comes from dividing the work and giving a narrow, trained component the part the general model gets wrong.

Speculative edits: the model checks against the original. In Aman's explanation of speculative edits, ordinary speculative decoding uses a small model to draft tokens that a large model verifies [1]. For edits, the best draft is the original code itself, so Cursor feeds chunks of existing code back and the model agrees with them in parallel until it reaches the part it wants to change [1]. This is mainly a speed technique, but it has a trust side effect: the result streams faster and lets people start reviewing before the edit finishes [1].

The shadow workspace: feedback from real tools. Arvid describes the shadow workspace: a hidden instance of Cursor where AI can edit code and get feedback from language servers, such as type errors and go-to-definition, without touching the user's files [1]. This is a form of grounding, but in the program's own tooling rather than in web sources: the model's output is tested against a compiler-like checker before a human sees it. Arvid would love to hand off a well-specified bug, like copy and paste not working in the chat input box, and come back to a verified fix [1].

Why models are bad at finding bugs. The team says frontier models are strikingly bad at bug finding when simply asked, because real bug detection is rare in pre-training data [1]. They also lack calibration about which bugs matter: the cultural knowledge a staff engineer has from seeing sketchy code take down a server [1]. Arvid's practice of labeling dangerous code with comments on every line helps both humans, who forget, and models, which pay more attention [1]. One idea for training bug finders is to have a model introduce plausible bugs into code, then train another model to find them [1]. Fridman suggests tipping or bug bounties; the team finds it a controversial idea internally, worrying money might make the product feel less fun [1].

Formal verification: proofs instead of tests. Arvid's most ambitious vision: "I think people will just not write tests anymore." [1] Instead, a model suggests a spec for each function and a reasoning model proves that the implementation matches it, possibly scaling to whole codebases, since work already exists on verifying systems down to the hardware [1]. Arvid even speculates that one might someday prove a language model is aligned, which Fridman notes would span the full range from AI safety to bug finding [1].

The team's own pushback. The other founders push back that intent is often hard to specify formally, and that side effects and external dependencies like a payment API are hard to cover [1]. That is the central weakness of verification: a proof shows the code matches the spec, not that the spec captures what the person actually wanted.

Verifiable data as a path to better models. Aman describes three kinds of synthetic data: distillation from a big model into a smaller one; problems that are easier in one direction, like introducing bugs to train bug finders; and generating many outputs that can be easily verified, as with formal math proofs or code that passes tests [1]. The third, he says, is the one most likely to produce massive gains, but perfect verifiers are hard to build for open-ended tasks [1]. On RLHF versus RLAIF, he notes that AI feedback works if verifying is easier than generating [1]. Sualeh bets AI will win a Fields Medal before a Nobel Prize because math is an isolated system with good reward signals [1]. Across these points the team keeps returning to one idea: where a checker exists, trustworthiness can be engineered and even used to train better models.

Distrust of benchmarks. The team also warns against trusting scores. Popular benchmarks like SWE-bench are contaminated in training data, so models can hallucinate the right file paths without seeing the codebase [1]. Real programming involves messy, half-specified instructions, so they lean heavily on qualitative vibe checks and private evals [1]. On theories that Claude has gotten dumber, they note that different chips, numerics and plain bugs can matter, because "it's hard to overstate how hard bugs are to avoid." [1] Their judgment of the moment: "The one that I'd say right now is just net best is Sonnet." [1]

Humans stay in control. Underneath all this is a philosophy. Michael Truell says the team wants a future that emphasizes the programmer's speed, agency and control, not one where you chat with a bot like an engineering department over Slack [1]. Good engineering, he argues, is made of countless micro-decisions and trade-offs, and handing them off loses control [1]. Most programming is iterative, so they believe you mostly want instant results to react to [1]. Fridman reads from Cursor's manifesto about a hybrid human-AI engineer who will "iterate at the speed of their judgment" [1]. Trust, in this picture, comes from a fast loop between model output and human judgment, not from a model that never errs.

Yann LeCun (Meta): Hallucination is built into autoregression; fix the architecture

The long-tail argument. LeCun gives the only account of why hallucination happens at the level of the model itself. Because LLMs generate token by token, each token carries some chance of leaving the set of reasonable answers [3]. If those errors are independent, which he calls a strong assumption, the probability of staying correct shrinks exponentially with the length of the answer [3]. Fine-tuning can cover perhaps 80% of the questions people commonly ask, but the space of possible prompts is gigantic and has a very long tail [3]. Random character strings, or swapping a few words into another language, can derail a model, which he says means the system is essentially a giant lookup table [3].

Same effort for easy and impossible questions. LeCun also notes that LLMs spend the same computation per token whether a question is trivial or impossible, unlike humans, who spend more time on harder problems [3]. That is the difference between System 1, fast and automatic like an expert driver or chess player, and System 2, deliberate planning with an internal world model, which LLMs cannot yet do [3]. LLMs, he says, don't plan their answers; they produce one word after another, a bit like answering a question automatically while distracted [3].

Fluency is not understanding. On the Turing test, LeCun says, "we're fooled by their fluency." [3] We assume fluent language means human intelligence, and that impression is false [3]. This is the psychological side of hallucination: fluent errors are dangerous precisely because they sound right. He names four essential characteristics of intelligent behavior: understanding the physical world, persistent memory, the ability to reason and the ability to plan, and says LLMs can do none of these, or only in a very primitive way [3].

The data gap. LeCun backs this with a comparison. LLMs train on roughly 10 to the 13 tokens, about 2 times 10 to the 13 bytes, which would take a person 170,000 years to read at eight hours a day [3]. A four-year-old child has been awake about 16,000 hours, and with the optic nerve carrying about 20 megabytes per second, roughly 10 to the 15 bytes have reached the child's visual cortex [3]. His conclusion is that most of what we learn comes from observing and interacting with the world, not from language [3]. LLMs can pass the bar exam, "But then they can't learn to drive in 20 hours like any 17 year old," [3] or clear a dinner table and load a dishwasher [3].

Fridman's pushback. Fridman argues that language is highly compressed and full of wisdom [3]. LeCun agrees it is compressed, but says that makes it less redundant, and self-supervised learning captures more structure from redundant data like vision [3]. He adds that language is only an approximate representation of our percepts and mental models, and much of our thinking, like imagining a bottle rotated 90 degrees, has nothing to do with language [3].

The fix: world models and JEPA. LeCun's alternative starts with learning abstract world models from video. Predicting pixels failed: he says he and colleagues at FAIR tried for about ten years, and training a system to reconstruct corrupted images or video "has been essentially a complete failure" at producing good general representations [3]. Instead, a joint embedding predictive architecture (JEPA) predicts the representation of the full input from the representation of a corrupted one, keeping only what is predictable and discarding things like the chaotic motion of leaves on a windy day [3]. V-JEPA is the first system his team has built that learns good video representations, and early results suggest it can tell whether a video is physically possible or impossible, for example when an object disappears or jumps [3]. That last detail is the closest thing in his account to a direct anti-hallucination test: a model that knows when the world has done something impossible. He warns that combining this with language too early is "cheating," using language as a crutch to cover weaknesses in vision systems [3].

Plan the answer, then speak. LeCun's blueprint for future dialogue systems is to have them "think about their answer, plan their answer by optimization before turning it into text." [3] Picture a network with a single scalar output that is zero when an answer fits a prompt and large when it doesn't, an energy-based model [3]. The system would search for an answer that minimizes that energy, not over strings of text but in an abstract representation space, using gradient descent, then pass the result to a simple decoder that turns it into words in any language [3]. Current approaches that generate many candidates and pick the best are, he says, horribly inefficient by comparison [3]. A world model that takes the state of the world and a possible action and predicts the next state also lets a system plan, the way model predictive control has been used to plan rocket trajectories since the early 1960s, something he says LLMs cannot do [3].

His bottom line. "If you're really interested in human-level AI, abandon the idea of generative AI." [3] He does not call LLMs useless; a whole ecosystem of applications can be built on them [3]. And he adds that "scale is necessary but not sufficient" [3], and that human-level AI is at least a decade away, "it's not going to be an event" [3]. He also admits the hardest part is unsolved: for hierarchical planning, "Nobody really knows how to do this in AI," [3] meaning nobody knows how to have a system learn the right levels of representation on its own.

Tools as part of the answer. Among open research directions, LeCun lists planning with learned world models including actions like using tools, search engines or calculators, mentioning FAIR's Toolformer [3]. That is a small but important bridge to Perplexity: even in LeCun's future, a system might reach for a search engine.

Where They Agree, and Where They Don't

Where they agree

Raw LLM output shouldn't be trusted on its own. All three start from the same premise. Perplexity exists because a GPT-3.5 Slack bot sometimes said incorrect things [2]. Cursor's team says frontier models mess up simple things like counting line numbers, are strikingly bad at bug finding when simply asked, and can hallucinate the right file paths on contaminated benchmarks [1]. LeCun says errors compound with each token and fine-tuning covers perhaps 80% of common questions, leaving a long tail [3].

Fluency and scores fool people. LeCun's "we're fooled by their fluency" [3] and Cursor's warning that benchmarks mislead because they're contaminated and don't reflect messy real work [1] are the same caution from two angles: what looks right is not evidence that it is right.

Checkable domains are where progress is fastest. Srinivas says games have rules that decide who won and math and code can be verified, while open-ended questions need humans in the loop [2]. Aman says generating easily verified outputs, like formal proofs or code that passes tests, is the synthetic data most likely to produce massive gains, but perfect verifiers are hard to build for open-ended tasks [1]. Sualeh picks math for a Fields Medal because it has good reward signals [1]. The Perplexity CEO and the Cursor team independently land on the same map of where AI can be made reliable.

Reasoning should be separated from something. Srinivas wants to decouple reasoning from memorized facts, like an open-book exam [2]. LeCun wants to decouple planning an answer from turning it into words, optimizing in an abstract space before a simple decoder produces text [3]. Cursor separates planning from exact execution, letting a big model sketch and a smaller trained model apply [1]. All three break the single just generate it step into parts that can each be held to a standard.

Srinivas partly agrees with LeCun. Srinivas, whose company counts LeCun as an investor, says LeCun's newer claim that reasoning may need to happen in an abstract latent space rather than only through autoregressive prediction has some truth, even if JEPA isn't the answer [2]. He also credits LeCun's 2016 "RL is just a cherry on the cake" remark as literally the recipe for ChatGPT [2], adding that "this cake has a lot of cherries." [2]

Where they don't

Is hallucination a pipeline problem or an architecture problem? This is the core disagreement. For Srinivas, hallucination has four causes, and three of them are about the inputs: stale or thin snippets, too much irrelevant detail and irrelevant documents [2]. Fix retrieval and the index, and hallucinations drop; he bet the company on models and indexes improving [2]. For LeCun, the cause is in how autoregressive models produce text at all: each token risks leaving the set of good answers, errors compound, and no amount of fine-tuning covers the long tail [3]. On his view, better retrieval reduces the problem but can't remove it, since the model still generates token by token over whatever it retrieves. Srinivas's own first cause, the model not being smart enough to understand the query and paragraphs [2], is the point where his account touches LeCun's.

Each side has a reason. Srinivas is running a product today and needs levers that work with available models; he treats the model as one replaceable part among several (users can pick GPT-4o, Claude 3 or Sonar [2]). LeCun is asking what it would take to reach human-level intelligence, and from that height, patching outputs looks like a detour: "abandon the idea of generative AI" [3].

Check before, during or after? Perplexity constrains the model before it writes, by feeding it only retrieved paragraphs and forbidding claims it didn't retrieve [2]. Cursor mostly checks after: language-server feedback in the shadow workspace, highlighted diffs, bug finders and, one day, proofs [1]. LeCun wants the check inside the thinking itself, with an energy function scoring answers before any text exists [3]. These are genuinely different bets about where error enters and where it's cheapest to catch.

Generate-and-select: sensible or wasteful? The Cursor team leans on generating many candidates and picking the best: reinforcement learning exploits the fact that among many samples one is likely right, and Cursor Tab is trained to prefer the suggestions humans like most out of many candidates [1]. They are also excited about test-time compute, running a smaller model longer on hard problems [1]. LeCun calls generating many candidates and picking the best horribly inefficient compared with optimizing in representation space [3]. The two views can coexist: Cursor is choosing what works with today's models, while LeCun is arguing about what the right design would be.

Can a spec capture intent? Within the Cursor team itself, Arvid imagines proofs replacing tests, while the others push back that intent is often hard to specify formally and side effects and external dependencies like a payment API are hard to cover [1]. This mirrors the broader debate: verification only proves conformity to what you wrote down.

Is language enough? Fridman pushes LeCun on whether language alone contains enough knowledge to build a world model, and LeCun answers that language is compressed and non-redundant and only an approximate representation of our mental models [3]. Srinivas's system, by contrast, is built entirely on text: search results, paragraphs and footnotes [2]. For questions whose answers live in written sources, text grounding is exactly the right tool; for questions about how the physical world behaves, LeCun argues text is missing most of what matters [3].

Why It Works

Citation works by narrowing what the model may say. Perplexity's mechanism is simple: search, extract relevant paragraphs, feed them to an LLM instructed to write a concise answer with footnotes, and don't say anything you didn't retrieve [2]. The model's job shrinks from recall and compose to summarize what's in front of you, which is the open-book exam Srinivas describes [2]. Footnotes also make errors visible, because each claim points to something a reader can check, the same way Wikipedia works [2]. Its remaining weak spots are exactly Srinivas's four causes: model comprehension, stale or thin snippets, irrelevant detail and irrelevant documents [2]. Because LLMs tolerate imperfect ranking and can find the right link even if it's ninth [2], retrieval doesn't have to be perfect, only good enough to get the right source into the context.

Verification works where checking is easier than generating. Aman's rule, that AI feedback works if verifying is easier than generating [1], explains why Cursor's approaches work. A language server can confirm a type error far more cheaply than a model can write correct code, which is why the shadow workspace is useful [1]. A proof checker can confirm that an implementation meets a spec, which is why Arvid thinks tests could be replaced [1]. And problems that are easier in one direction, like introducing bugs, can generate training data for the hard direction, finding them [1]. Where no cheap checker exists, as with open-ended tasks, the approach runs out [1], which matches Srinivas's view that open-ended questions need humans in the loop [2].

Directing attention helps both humans and models. Arvid's comments on every line of dangerous code help humans, who forget, and models, which pay more attention [1]. Aman's vision of diffs that gray out boring parts and flag likely bugs [1] works the same way on the human side. Verification is cheaper when it is aimed.

LeCun's mechanism for why generation fails. If each token has some chance of leaving the set of reasonable answers and errors are roughly independent, the chance of a long answer staying correct shrinks exponentially with its length [3]. Fine-tuning covers a large but finite set of common questions, perhaps 80%, while the long tail of possible prompts is gigantic [3]. And because the model spends the same compute on every token, it can't slow down on hard parts the way a person does [3]. His proposed cure works on each of these: plan the whole answer in an abstract space before producing any text, so errors don't compound word by word; use an energy function that scores whether an answer fits the prompt; and learn a world model from observation so the system has something besides text statistics to check against [3]. V-JEPA's early ability to judge whether a video is physically possible [3] is a first sign that such a model can tell when something is wrong.

Why the fixes have to differ. Citation works when truth lives in documents. Verification works when truth can be checked by a machine. LeCun's world models aim at the case neither covers: knowledge about how the world behaves, which, on his numbers, mostly comes from observation, not language [3].

Where It Applies, and Where It Doesn't

Citation fits factual questions with good written sources. Perplexity's approach is strongest for research-style questions, like the health insurance terms that started the company [2]. Its own live answer during the conversation concedes that Google is still faster and better for navigational queries and real-time information such as sports scores [2]. It depends on a fresh, rich index, so stale or thin sources produce hallucinations [2]. It is exposed to manipulation, from answer engine optimization to prompt injection hidden in web pages, a cat-and-mouse game that is partly reactive [2]. And a citation proves only that a source said something, not that the source is right, which is why Srinivas's retrieval uses signals like domain authority and recency [2].

Verification fits code and math. Cursor's methods work where there are compilers, language servers, tests and formal specs [1]. They fit well-specified tasks, like a clearly defined bug, better than iterative, half-specified work, which the team says is most of programming [1]. Formal proofs struggle when intent is hard to specify, and with side effects and external dependencies like a payment API [1]. Bug finding also depends on calibration about which bugs matter, which models currently lack [1]. Outside checkable domains, the method has little to grip: perfect verifiers are hard to build for open-ended tasks [1].

World models aim at the physical world and planning. LeCun's program targets understanding the physical world, persistent memory, reasoning and planning [3], and robotics, where he says real progress depends on world models [3]. But it is a research direction, not a shipping product. By his own account, human-level AI is at least a decade away and probably much more [3], and nobody yet knows how to learn hierarchical plans [3]. He says there has been zero demonstration of learned multi-level action representations [3]. For someone who needs reliable answers today, it offers an explanation and a direction, not a tool. And he agrees LLMs remain useful: a whole ecosystem of applications can be built on them [3], and an LLM can break a trip into steps down to the level things can be described in words, if it was trained on similar scenarios [3].

Across all three: long answers and unusual prompts are the danger zone. LeCun's compounding-error argument implies that the longer the free-form output, the higher the risk [3]. His long-tail point implies that unusual questions are riskier than common ones [3]. Cursor's warning about contaminated benchmarks implies that looking good on familiar tests says little about new situations [1]. And Srinivas's list shows that even grounded systems fail when retrieval returns the wrong things [2].

What To Do With It

1. Match the method to the kind of truth. For factual questions answerable from documents, prefer a tool that cites its sources, as Perplexity does [2]; for code or math, rely on machine checks such as type checkers, tests or proofs [1]; for anything about how the physical world behaves, remember LeCun's warning that text-trained models lack that understanding [3].

2. Actually open the footnotes. Citations only help if someone checks them. Srinivas says "the journey begins after you get an answer" [2]; treat the sources as the start of verification, especially on the claims that matter most to your decision.

3. Diagnose grounded failures with Srinivas's four causes. When a cited answer is wrong, ask which one it was: the model misunderstood, the sources were stale or thin, too much irrelevant detail was included, or the retrieved documents were irrelevant [2]. If you build such a system, fix the class of failure, not the single query [2], and don't rely on embeddings alone; hybrid retrieval with BM25-style term matching, recency and authority signals still matters [2].

4. Tell the model it may say I don't know. Borrow Perplexity's rule: don't say anything that isn't retrieved, and if there isn't enough information, say so [2]. And be wary of stuffing everything into context, since irrelevant detail is one of the four hallucination causes [2] and longer context trades off against instruction following [2].

5. Give AI-written code a real checker before a human reads it. Run it through the language server, type checker and tests, as Cursor's shadow workspace does [1]. Where outputs can be checked more easily than they can be generated, lean on that asymmetry [1].

6. Mark the dangerous parts. Follow Arvid's practice of labeling dangerous code with comments on every line, which helps both humans, who forget, and models, which pay more attention [1]. When reviewing AI changes, focus on the parts that matter and skim the boilerplate, as Aman suggests better review tools should do [1].

7. Don't ask a model find the bugs and trust a clean result. The Cursor team says frontier models are strikingly bad at bug finding when simply asked and lack calibration about which bugs matter [1]. Treat a no bugs found answer as weak evidence.

8. Write down the spec before you trust a proof. If you use formal verification or spec-based checks, remember the team's own objection: intent is hard to specify, and side effects and external dependencies are hard to cover [1]. A proof is only as trustworthy as the spec behind it.

9. Judge models on your own tasks, not public scores. Cursor's team leans on private evals and qualitative checks because popular benchmarks are contaminated [1]. Do the same: test a model on the messy, half-specified work you actually do.

10. Be most skeptical of long, fluent, unusual answers. LeCun's argument says errors compound with length and the long tail is where fine-tuning runs out, and that "we're fooled by their fluency" [3]. Break big requests into smaller, checkable pieces, and give extra scrutiny to answers on rare or oddly phrased questions.

Sources

1. Cursor Team: Future of Programming with AI · Lex Fridman Podcast
2. Aravind Srinivas: Perplexity CEO on Future of AI, Search & the Internet · Lex Fridman Podcast
3. Yann LeCun: Meta AI, Open Source, Limits of LLMs, AGI & the Future of AI · Lex Fridman Podcast