Part 11

Leveraging AI

11.1 What models can and cannot do for you

Everything in this course so far has been about markets. This part is about a tool, and it needs a warning first: the specifics of AI change faster than any course can track. Model names, context window sizes, pricing, and which product is best at what will all be different a year after you read this. So these five lessons teach the working principles, the things that follow from how the technology is built and will still be true when the product names have changed. For current specifics, go to the official documentation from the vendors: Anthropic's docs for Claude, OpenAI's for ChatGPT and their API, Cursor's for their editor. Those pages are updated when the products change. This lesson is not.

A language model is now the cheapest research assistant and coding partner you'll ever hire. Used well, it compresses hours of work into minutes. Used naively, it will hand you a confidently worded backtest result that was never computed, a contract multiplier that is wrong, and a summary of a filing that includes a sentence the filing never said. The difference between those two outcomes is entirely about whether you understand what the machine is actually doing. So that's where we start.

11.1.1 The machine underneath

A large language model is a next-token predictor. It was trained on an enormous amount of text, and the core thing it learned is: given everything written so far, what token comes next? A token is a chunk of text, usually a word or piece of a word, roughly three quarters of an English word on average. When you send a prompt, the model predicts one token, appends it, predicts the next one given the new sequence, and repeats until it decides to stop. That loop is the entire mechanism. There's no database lookup behind it, and no fact checker in the loop by default. The fluent, structured, apparently thoughtful answer you get back is the output of that prediction loop and nothing else.

This sounds like it should produce gibberish, and the surprising empirical fact of the last several years is that it doesn't. Predicting text well, at sufficient scale, turns out to require internalizing an enormous amount of structure: grammar, logic, the relationships between concepts, the conventions of code, the shape of a good argument. The models are genuinely capable. But the mechanism matters because it defines the failure modes, and the failure modes are what will cost you money.

Two refinements to the basic picture, because you will hear about both. After the initial training, models go through additional tuning where humans (and increasingly other models) rate outputs, and the model is adjusted toward the highly rated ones. That's why models are helpful and polite rather than raw text-completion engines, and it has side effects that matter for traders, sycophancy chief among them. We deal with that properly in the next lesson. The other refinement: newer models can spend tokens "thinking" before answering: they generate intermediate reasoning text, then produce the final answer conditioned on it. This measurably improves performance on math and multi-step problems. It doesn't change the underlying mechanism. The thinking is also next-token prediction, just pointed at scratch work before the answer.

The core picture is a system that produces the most plausible continuation of the text so far. Plausible is not the same as true, and everything else in this lesson follows from that distinction.

11.1.2 The context window

The model's working memory is called the context window: the total amount of text it can consider at once, covering your prompt, any documents you paste in, the conversation so far, and its own output. It's measured in tokens, and for current frontier models it's large, on the order of hundreds of thousands of tokens, with some models advertising more. That's enough to hold several annual reports or a whole codebase's worth of files. Check current numbers in the vendor docs; they grow every year.

Anything outside the window doesn't exist for the model. In a long conversation, older messages eventually fall out or get compressed, and the model will contradict things it said an hour ago without any awareness of doing so. If a detail matters, restate it. A big window also isn't the same as perfect attention across it. Models are empirically better at using information near the start and end of a long context than material buried in the middle, and accuracy on needle-in-a-haystack retrieval degrades as you stuff the window fuller. Pasting 200 pages and asking one question usually works. Pasting 200 pages and expecting the model to weigh every paragraph equally does not. The window is also why "just paste the document in" beats "the model probably knows this" for anything specific. Text inside the window is something the model can actually read. Facts it half-absorbed during training are something it reconstructs, and reconstruction is where errors live.

11.1.3 The training cutoff

A model's knowledge comes from its training data, and that data ends on a date, typically some months before the model was released. This is the training cutoff. The model knows nothing after it. Not yesterday's CPI print, not the current price of anything, not this quarter's earnings, not a rule change the exchange announced last week.

This would be merely inconvenient if models said "I don't know, that's after my cutoff" reliably. They often do, when the question obviously concerns recent events. The dangerous case is the question that doesn't look time-sensitive but is. Ask about a contract's margin requirement, a token's circulating supply, an ETF's expense ratio, or which strikes an exchange lists, and the model will answer from training data that may be years stale, with no timestamp attached and no hesitation. Market structure details rot quietly. Tick sizes change, contracts get delisted, funding interval conventions differ by venue and era. The model has a photograph of the world as of its cutoff, and it will describe the photograph in the present tense.

Many products now attach tools to the model: web search, code execution, database access. A model with search can pull live data, and when it does, the cutoff problem shrinks to a citation-checking problem. Be precise about what's happening. The tool fetches text, the text lands in the context window, and the model reads it there. The model itself is still frozen. If the tool didn't run, or fetched a stale page, or the product you're using has no tools attached, you're back to the photograph. A chat model without tools doesn't have "no access to live prices" in some fixable, temporary sense. It has no live anything, structurally, and it will still produce a fluent answer if you ask.

11.1.4 Why models hallucinate

Hallucination is the industry's word for the model stating something false with the same fluency it states true things: an invented statistic, a paper that doesn't exist, a function in an API that was never there, a plausible-sounding rule of a futures contract that's simply wrong.

The reason this happens tells you it's not going away. The model produces plausible continuations. Most of the time, the most plausible continuation of a factual question is the true answer, because the training data mostly contains true statements about well-documented things. But when the true answer is rare in the training data, or absent, or the question is subtly off, the most plausible continuation is whatever sounds like the kind of thing that would be true. The model fills the gap with statistically typical material. A citation with a real journal name, a real-sounding author, and a fabricated title is not the model lying. It is the model doing exactly what it does everywhere else: generating text with the right shape.

Vendors have driven hallucination rates down substantially, and tool use helps more, because a model that can search or run code can check itself. But no amount of training makes a plausibility engine into a truth engine, because truth isn't a property of text statistics. The error rate falls; the error mode remains. Treat hallucination the way you treat slippage: a permanent cost of the mechanism that you manage, not a defect you wait for someone to fix.

The gap-filling behavior follows a pattern. Models hallucinate most on specifics: exact numbers, dates, names, citations, minor entities, and the fine print of niche domains. They hallucinate least on broad, heavily documented concepts. Ask what gamma is and the answer will be fine, because ten thousand explanations of gamma were in the training data. Ask for the exact contract specs of a back-month agricultural future and you're rolling dice. The course has already given you the habit that saves you here: back in the backtest lessons, the rule was to never trust a result you haven't verified against a known answer. The same rule, applied to model output, is the entire discipline of this part.

11.1.5 Ignore the confident tone

The most expensive misunderstanding a trader can bring to these tools is reading the model's tone as information about reliability.

Humans calibrate on tone constantly, and mostly it works. A person who answers instantly and precisely usually knows; a person who hedges usually doesn't. Models break this heuristic completely. The confident register is a writing style the model learned because confident text is common and highly rated, and it applies that style almost uniformly. A fabricated number arrives in the same crisp declarative sentence as a correct one. The model does have internal uncertainty in a technical sense (probabilities over tokens), but that uncertainty doesn't surface as hedged prose in any dependable way. You can't read calibration off the page.

So the tone of an answer carries approximately zero information about its correctness, and you should consciously discard it. That's harder than it sounds, because the writing is genuinely good, and good writing has bought credibility for your entire reading life. The practical rule: sort claims by how much it costs you if they're wrong, and verify from the top. A wrong nuance in an explanation of vanna costs you nothing today. A wrong multiplier in a position size calculation costs you real money at the next fill. You already size risk by consequence everywhere else in your trading. Do it here too.

Anything numerical gets verified, full stop. Numbers are where plausible and true diverge most often and most expensively, partly because of how models process them (more on arithmetic below) and partly because a number is exactly the kind of specific detail the gap-filling failure mode targets. A model-quoted contract spec gets checked against the exchange. A model-computed expectancy gets recomputed by hand or by code you have read. A model-summarized statistic gets traced to its source document. If you can't verify a number, you don't use the number. That rule sounds heavy and in practice takes minutes, because verification is usually a lookup, and the model already did the slow part of finding the shape of the answer.

11.1.6 Where models are already strong

None of the above is a case against using these tools. It's a case for using them where the mechanism works in your favor. Four areas stand out, and they share one property: either the source material is in the context window where the model can actually read it, or the output is checkable at a glance.

Synthesis is the flagship. Give a model three earnings call transcripts, a filing, and a research note, and ask what the common thread is, what changed since last quarter, where the documents disagree. This is the task the architecture is built for: the material is all in the window, and the job is compression and comparison rather than recall. A competent read of documents that would take you two hours takes the model seconds, and the failure mode (a claim not actually supported by the documents) is checkable because you have the documents. The workflows that make this safe come in the research lesson later in this part.

Explanation is where I expect you to use models the most. Every concept in the preceding ten parts is heavily documented territory, exactly where hallucination is rarest. Stuck on why a calendar spread is long forward vol? Ask, then ask for the same explanation with different numbers, then ask what breaks if vol rises in the front month instead. A model is an infinitely patient tutor that never judges the question. It will occasionally garble a subtlety, so anchor on the course text and the standard references for anything load-bearing, but for the loop of "explain, re-explain, test me," it's the best learning tool that has ever existed. The research lesson later in this part turns that loop into concrete study workflows.

Extraction is unglamorous and dependable. Pull every strike and expiry mentioned in this transcript into a table. Turn this broker statement into a CSV. Find every mention of inventory in this 10-K and quote the sentence. Structured extraction from messy text used to be either manual labor or a custom script; now it's a prompt. Errors happen, so spot-check a sample, but the hit rate on extraction from in-context documents is high because nothing is being recalled, only reorganized.

Code is the area with the highest ceiling for a trader, high enough that it gets its own lesson later in this part. Models write working analysis scripts, backtest scaffolding, and data-cleaning glue from plain-language descriptions, and code has a property no prose has: you can run it. Wrong code fails visibly more often than wrong prose does, and test cases with known answers catch most of the rest. The trader who could never quite justify learning to program now has a way to get 80 percent of the benefit by directing the work and verifying the output instead of writing every line.

11.1.7 Where models fail

Arithmetic at scale is the one that surprises people most. A machine that explains stochastic calculus fluently will multiply two six-digit numbers wrong. The reason is that the model doesn't compute; it predicts the tokens of the answer, digit patterns learned from text, and numbers get split into tokens in ways that make carrying and precision unreliable. Small arithmetic is usually fine. Long chains of it, compounding calculations, anything where one digit error propagates, are not. The fix isn't a better prompt; the fix is making the model write code and run it, because code executes exactly, or doing the arithmetic yourself. When a model with a code execution tool answers a math question, trust the number that came out of the code, not the one that came out of the prose. That's why every P&L, sizing, or expectancy calculation you route through a model should route through code you can see.

Prediction is a category error. Do not ask a model where the market is going. The model has no live data, no edge, and no account of the adversarial nature of markets; you spent the statistics lessons learning that even genuine edges are thin, hard-won, and decay when crowded. A text predictor trained on years of commentary can produce a beautifully argued market outlook because the training data is full of beautifully argued market outlooks, most of which were wrong in the way commentary is always wrong: unfalsifiable, hedged, and written after the moves it explains. Everything this course taught about where returns actually come from (premia, positioning, flows) should tell you that "sounds convincing" was never the test. Asking a language model for a price target gives you confident prose with no predictive value.

Anything the model cannot verify inherits the hallucination problem in full. Specific historical market data recalled from training, the fine print of margin rules, whether some API endpoint exists, what a regulation actually says: if the source isn't in the context window and no tool fetched it, the answer is a reconstruction, and reconstructions of specifics fail at exactly the rate that matters. The dividing question for every task is: is the model working from material it can see, toward an output I can check? Both halves yes, proceed with light verification. Either half no, treat the output as a draft of a guess.

A subtler failure worth naming: models are weakest exactly where you are, on the frontier of your own understanding. When you know a domain, errors jump out. When you are learning, an error and an insight look identical, and the model's fluency actively works against you. This isn't a reason to avoid using models to learn. It's a reason to keep a verification loop in the process even when, especially when, the answer feels clarifying. The research lesson later in this part builds that loop out properly.

11.1.8 The frame to carry forward

Everything in this lesson compresses into a working stance: treat the model as a brilliant and tireless junior analyst who has read nearly everything, remembers it imperfectly, has been out of contact with the world since the cutoff date, cannot do long division, and will never, under any circumstances, tell you they're unsure in a way you can trust. You'd happily employ that analyst. You'd be insane to trade their numbers unchecked.

That stance makes the division of labor obvious. The model does volume: reading, drafting, structuring, explaining, writing code. You do judgment: choosing what to work on, verifying what comes back, and owning every decision that touches risk. The model's job is to make you faster. Your job description doesn't change.

Getting good output from that junior analyst is a skill of its own, and the biggest obstacle is a personality quirk the training process bakes in: the model wants to agree with you. The next lesson covers prompting mechanics and, more importantly for a trader, how to stop the model from telling you your trade idea is great.

11.2 Prompting that gets honest answers

The last lesson established what a language model is: a next-token predictor with no live data, no ability to know when it's wrong, and a tone that stays confident either way. This lesson is about the other half of the problem, which is you. The quality of what comes back depends heavily on what you send in, and most people send in prompts that guarantee a useless answer. Worse, the model is trained in a way that makes it want to agree with you, and a trader who is already leaning into a position is the ideal victim for that failure mode.

So this lesson does two jobs: the mechanics of what a prompt that produces real work actually contains, and the harder part, which is how to stop the model from telling you what you want to hear, because by default it will.

11.2.1 The four parts of a working prompt

A prompt that gets useful output has four components: context, task, constraints, and output format. You won't always need all four written out explicitly, but when an answer disappoints you, the fix is almost always in one of these slots.

Context is everything the model can't know on its own. Remember from the last lesson: the model has no live prices, no access to your platform, no idea what date it is unless told, and a training cutoff somewhere in the past. If your question depends on current numbers, paste the numbers. If it depends on your situation, describe the situation. A prompt like "is selling this straddle a good idea" with no numbers forces the model to answer in generic textbook terms, and generic textbook terms are what you get. Compare that to a prompt that includes the ticker's 30-day implied vol, the 20-day realized vol, the days to earnings, the implied move, and the historical average earnings move. Now the model can do arithmetic and comparison on real inputs instead of vibes. The biggest upgrade most people can make to their prompting is simple: paste more of what you're looking at.

Task is the specific action you want, stated with a verb that has a checkable result. "Analyze this position" is weak because anything counts as analysis. "List the three scenarios where this position loses more than twice its expected profit, with the rough price and vol moves each requires" is strong because the output either contains that or it doesn't. Vague verbs (analyze, discuss, consider, review) invite essays. Specific verbs (list, calculate, compare, rank, identify) invite work. When you catch yourself writing "thoughts on this?", stop and ask what you'd actually do with a good answer, then request that thing directly.

Constraints tell the model what to exclude and what to assume. Length limits ("no more than 200 words"), scope limits ("ignore tax considerations"), assumption declarations ("assume I already understand how funding rates work, skip the explainer"), and honesty instructions ("if any input needed for this is missing, say so instead of estimating it"). That last one matters more than it looks. A model asked to compute something with a missing input will often invent the input silently. Telling it explicitly that "I don't have enough information" is an acceptable answer measurably changes behavior, because you've made the honest response an allowed completion instead of an apparent failure.

Output format is where you specify the shape of the answer: a table, a numbered list, a specific set of headings, a rating with justification. Format requests do more than make answers easier to read. They force completeness. If you ask for a table with a row per scenario and columns for probability, P&L impact, and early warning sign, the model has to fill every cell, including the ones it would have skated past in prose. An essay can sound balanced while committing to nothing. A table cannot.

Here's the difference in practice. The lazy version:

Thoughts on selling the earnings straddle on this stock?

The working version:

Context: Stock at 142.30, reports earnings tomorrow after close.
Front expiry straddle costs 9.80, implying about a 6.9% move.
Average absolute earnings move over the last 12 quarters: 4.8%,
largest 11.2%. 30-day IV is 58, 20-day realized is 31.
Stock has no pending corporate actions I know of.

Task: Evaluate short straddle vs short strangle vs no trade.
For each, list the conditions under which it loses badly.

Constraints: Do not explain what a straddle is. If you need
information I have not given you, ask instead of assuming.

Format: One short paragraph per option, then a table comparing
max realistic loss scenario, what has to be true to profit,
and what would make you skip the trade entirely.

The second prompt is longer to write and dramatically cheaper overall, because you skip the three rounds of "no, I meant..." follow-ups. It doesn't include your opinion. That's deliberate, and it's the subject of the rest of this lesson.

One more mechanical tool before moving on: examples. If you want output in a specific style or structure, showing one worked example of the input-output pair you want beats paragraphs of description. Few techniques transfer as reliably across models and vendors as this one. If you want your journal entries summarized a particular way, paste one entry and the summary you'd have written yourself, then the next entry with "same treatment." The model pattern-matches on the example far more faithfully than it follows abstract instructions.

11.2.2 Why the model flatters you

Modern chat models go through a training stage where human raters score candidate responses and the model is tuned toward the responses people preferred. Raters, being people, systematically prefer answers that are agreeable and confident. They rate down answers that feel contrarian, that hedge, or that criticize the question itself. Tune a model on millions of those judgments and you get a system with a built-in tilt toward telling the user they are right. This is called sycophancy, and it's a property of the training process, so you should expect some version of it in every chat model you use regardless of vendor, this year and next year.

The practical consequence: any preference that leaks into your prompt gets reflected back at you, amplified and well-argued. Run the experiment yourself. Ask "I'm bullish on gold here because real yields are rolling over and positioning is light. What do you think?" and you'll get a thoughtful elaboration of your own thesis with maybe a token caveat at the end. Open a fresh chat and ask "I'm bearish on gold here" with equally plausible reasoning and you'll get a thoughtful elaboration of that. Same model, same market, opposite conclusions, both delivered fluently. The model wasn't evaluating gold in either chat. It was completing your framing.

For a trader this is close to the worst possible failure mode, because you rarely come to the model neutral. You come with a position on, or a position you want to put on, and what you want (whether you admit it or not) is permission. Back in the crowd psychology lessons we covered confirmation bias: the tendency to seek and overweight evidence that supports what you already believe. A sycophantic model is a confirmation bias machine with infinite patience and excellent prose. It will build you a beautiful case for whatever you walked in believing, and it will feel like independent validation because it came from outside your head. It is not validation; it is your own view reflected back.

A better model doesn't fix this, because the tilt comes from how all of them are trained. What fixes it is prompting patterns that structurally prevent your preference from reaching the model, or that force the model to work against it. There are four that matter.

11.2.3 Pattern one: blind the analyst

Never reveal which side of the trade you are on before asking for analysis. This costs nothing and removes most of the problem on its own.

Instead of "I'm long crude from 71.50, should I hold through the inventory report?", write "Evaluate the case for being long crude here and the case for being flat, given the inventory report tomorrow. Here is the current data: [paste]." The model now has no side to flatter. You get the analysis first and apply it to your position yourself.

When you can't phrase the question without a directional setup being obvious, attribute it to someone else. "A trader I follow proposes shorting this stock into earnings based on the following reasoning: [reasoning]. Assess the argument." Models critique a third party's reasoning far more freely than they critique yours, because there's no user to please on the other side of the argument. The same reasoning presented as "my plan" gets handled with kid gloves; presented as "this person's plan" it gets handled honestly. That asymmetry is absurd, and it's also completely exploitable.

A stricter variant: ask for both cases before revealing anything, and ask for them at equal length. "Give me the strongest bull case and the strongest bear case for this setup, roughly equal effort on each, then state which one the data provided supports better and why." Requiring equal effort matters. Without it, the model will often write four paragraphs for the side your phrasing hinted at and one dutiful paragraph for the other.

11.2.4 Pattern two: ask for the case against

Once you do hold a view, the highest-value question isn't "am I right?" but "what is the strongest argument that I am wrong?" Ask for it directly and set the stakes: "Argue against this trade as if you were paid to talk me out of it. Do not soften the argument. I want the best version of the opposing case, not a balanced summary."

This works because it reframes the task. The sycophantic pull is toward agreeing with you, but you've now defined "agreeing with you" as producing a strong counterargument, so the model's eagerness to please works in your favor.

Base rates belong in the same family. Before asking about your specific setup, ask about the general category. "Historically, how often do breakouts from multi-month ranges follow through versus fail?" or "What typically happens to implied vol in the week after earnings?" Get the base rate first, then ask how your setup differs from the average case. This ordering matters. If you present your specific trade first, everything after gets colored by it. If you establish the base rate first, your trade has to argue against the anchor instead of the anchor bending around your trade. One warning that carries over from the last lesson: models will happily produce a precise-sounding base rate ("62% of breakouts fail within 10 days") that's fabricated. Ask for the qualitative direction and rough magnitude, treat any specific figure as unverified, and check numbers that will actually change your decision. The next lesson covers verification workflows in detail.

So does disconfirming evidence: "What evidence, if I found it, would most weaken this thesis?" This is a pre-mortem in question form. It converts the model from advocate to test designer, and the tests it proposes are often things you can actually go check on the platform: positioning that contradicts the story, term structure that disagrees, breadth that does not confirm. A thesis that survives a genuine attempt to list its disconfirmers is worth more than a thesis that has only ever been argued for.

11.2.5 Pattern three: force structure and stated confidence

Free-form prose lets a model hedge invisibly. Every claim arrives wrapped in the same confident register, and qualifiers get buried mid-sentence where you skim past them. Structured output strips that cover away.

The basic move is to demand a table or a fixed set of fields for anything decision-relevant. If you ask for scenario analysis, require one row per scenario with explicit columns. If you ask for an assessment, require a stated conclusion field so the model can't end on "ultimately it depends on your risk tolerance," which is the model's way of concluding nothing.

The stronger move is to require explicit confidence on each claim. "For every factual claim in your answer, label it high, medium, or low confidence, where low means you could not verify it from the information I gave you." These labels aren't calibrated probabilities and you shouldn't treat a "high" as 90%. What the labeling actually does is force a separation: claims the model is pattern-matching confidently versus claims it's generating to fill space. You'll find the low-confidence labels cluster on the specific numbers, dates, and named facts, which is where hallucination lives. The labels tell you where to point your verification effort.

The third move in this family is the question "what would change your mind?" Append it to any recommendation: "You have concluded X. List the specific observations that would flip your conclusion to not-X." A real analysis has flip conditions. If the model can't produce concrete ones, or produces conditions so extreme they would never occur, the original conclusion was weaker than it sounded. This question is also useful applied to yourself, but that's a Part 10 topic and you've already read it.

11.2.6 Pattern four: separate generation from critique

A model asked to produce an analysis and then, in the same conversation, asked to critique that analysis will go easy on itself. This is partly the consistency pull of the context window: everything already said in the chat is context the model treats as established, so the critique gets anchored to the generation. Asking "now critique your answer" in the same thread usually produces cosmetic criticism, a few softened quibbles that leave the conclusion standing.

The fix is to split the roles across conversations. Generate the analysis in one chat. Open a fresh chat, paste the analysis in with no history attached, and frame the new chat as pure critique: "The following analysis was produced by another analyst. Find its weakest points: unstated assumptions, missing scenarios, claims presented without support, and any place where the reasoning would break if a stated input were slightly wrong." The fresh chat has no investment in the conclusion and no earlier turns to stay consistent with. The difference in critique quality isn't subtle.

A full workflow for a trade thesis looks like three passes. First chat: neutral framing, both sides argued at equal length, structured output (pattern one and three). Second chat: paste the output, request the adversarial critique (pattern four). Third pass: you, not a model, reading both documents against the actual data on the platform and making the call. The synthesis stays human because the models on both sides of the argument share the same blind spots, and because sizing and risk are never the model's decision. That boundary gets its full treatment in the last lesson of this part.

You can run the critic on a different vendor's model if you want, and there's a mild argument for it (different training, somewhat different blind spots), but the fresh-context split is doing most of the work. Same model, fresh chat, adversarial framing captures the bulk of the benefit.

11.2.7 Maintaining prompts over time

Everything above describes single exchanges. The last idea in this lesson is what you do across weeks: treat your prompts as a system you maintain rather than conversations you improvise.

The distinction shows up in what you do when an answer is bad. The conversational instinct is to reply "no, that's not what I meant, try again" and steer the chat until the output is acceptable. That works once, and then the fix evaporates when the chat ends. The systematic move is different: figure out which of the four components failed (usually missing context or a vague task), rewrite the prompt itself, and rerun it clean. Now the fix is permanent, because the improved prompt is what you'll use next time.

This implies you should keep your recurring prompts somewhere: a text file, a note, wherever. Any question you ask more than twice a month deserves a written prompt template with slots for the parts that change. A weekly review prompt into which you paste the week's journal entries. A pre-event prompt into which you paste the current term structure and positioning data. An adversarial-critique prompt you reuse verbatim in fresh chats. Over a few months these templates accumulate your fixes the way a codebase accumulates bug patches, and your worst prompting mistakes stop recurring.

Templates also make testing possible, and testing is what separates a prompt you trust from a prompt you hope works. The method is the same one you already know from the backtesting lessons: evaluate on cases where you know the answer. Before trusting a journal-review prompt, run it on a past month you've already reviewed by hand and check whether it surfaces the patterns you know are in there (say, you already know you consistently oversized after winning streaks that month; does the prompt find it?). Before trusting an analysis template, run it on a trade whose outcome you already know and see whether the risks it lists include the one that actually materialized. A prompt that fails on known cases will fail on unknown ones; you just won't notice.

When you refine a template, change one thing at a time and rerun the same test input. Change the format requirement and the context together and you can't tell which change helped. This is slower than rewriting the whole prompt on instinct and it's the only way you learn what actually moves output quality, which is knowledge that transfers to every prompt you write afterward.

The vendors publish their own prompting guides (Anthropic and OpenAI both maintain them, and they are updated as models change), and it's worth skimming them once or twice a year. Their consistent advice matches what this lesson has argued from the trading side: define what a good answer looks like before prompting, test against real cases, iterate on the prompt rather than the conversation. The specific model tips in those guides will date quickly. The workflow will not.

The patterns in this lesson assume the raw material is your own thinking: a trade idea, a position, a thesis. The next lesson turns to the case where the raw material is a document, a 200-page filing, an earnings transcript, a dense paper, and the failure mode shifts from flattery to fabrication. The mechanics you learned here still apply, but they get a new layer: forcing the model to quote its sources and prove every claim against the text.

11.3 AI for research and learning

Language models earn their keep for a trader in research, not signal generation: compressing a 200-page filing into the eight facts you care about, pulling every forward-looking statement out of an earnings call, or explaining a concept from this course five different ways until one sticks. The previous two lessons covered why models fabricate and how to prompt around your own bias. This one covers the workflows that let you use a model on real documents and real learning without quietly absorbing its mistakes.

The core problem is straightforward. A model summarizing a document produces two kinds of sentences that look identical: sentences grounded in the document and sentences it generated because they were statistically plausible. A summary that says "management guided Q3 revenue to $2.1 billion" reads exactly the same whether the transcript says $2.1 billion, $2.4 billion, or nothing at all. Your eye can't tell them apart. The craft of AI-assisted research is building workflows where fabrications become cheap to catch, and everything in this lesson is a variation on that move.

11.3.1 Give it the document

Start with the mistake that causes most hallucinated research: asking a model about a document it doesn't have. "What did company X say about margins on their last earnings call" is a request to reconstruct a transcript from training data. Back in the first lesson of this part you saw why that fails: the model's training has a cutoff, the call may have happened after it, and even for older calls the model holds a lossy statistical impression, not a record. It will answer anyway, fluently, and some of the numbers will be wrong.

The fix is mechanical: paste the document into the conversation, or attach the file, and ask questions about what is in front of the model. Modern context windows take this from theory to practice. A full 10-K runs somewhere in the range of 50,000 to 150,000 words depending on the company, an earnings call transcript maybe 8,000 to 12,000 words, and current frontier models accept context windows that hold either comfortably, often several documents at once. With the source in context, the model is doing extraction and compression rather than recall. That is the read-versus-reconstruct distinction from the first lesson of this part working in your favor.

This single habit, source in context before any question gets asked, removes the largest class of research hallucinations before you've typed a prompt. It doesn't remove them all. A model can misread a table, drop a "million" versus "billion" distinction, attribute the CFO's hedge to the CEO, or blend two adjacent numbers into one that appears nowhere. Those are the errors the rest of the workflow exists to catch.

11.3.2 The quote-and-verify workflow

This workflow makes document summaries safe to act on. It has three steps, and the second one does the real work.

First, provide the document and ask for the summary you actually want, but with a constraint: every material claim must be supported by an exact verbatim quote from the source, with its location. A prompt that works:

Here is the Q2 earnings call transcript for [company]. Summarize: guidance changes, margin commentary, anything about demand weakening or strengthening, and any question management dodged. For every claim in your summary, include the exact verbatim quote from the transcript that supports it, and note whether it came from prepared remarks or the Q&A. If you cannot find a supporting quote for something, say "no direct support in transcript" instead of paraphrasing.

Second, spot-check the quotes. This is a text search, not a reading job. Take three or four of the quotes that matter most to your view, search the source document for them, and confirm they exist word for word and mean in context what the summary says they mean. Thirty seconds per quote.

Third, apply a simple rule: if any checked quote fails, the whole summary is suspect. Don't patch the one bad claim and trust the rest. A fabricated quote means the model was operating in plausible-generation mode rather than extraction mode for at least part of the task, and you can't know which part. Re-run with a sharper prompt or a fresh conversation.

Why quotes specifically? Because a fabricated paraphrase is expensive to catch and a fabricated quote is nearly free to catch. If the model writes "management sounded cautious on Europe," verifying that means reading the Europe sections yourself and forming a judgment, which is the work you were trying to compress. If the model writes that the CFO said "we are seeing elongated sales cycles in EMEA," verification is a search that either finds the string or doesn't. You've converted a fuzzy judgment problem into a binary lookup. Models also fabricate verbatim quotes less often than they fabricate paraphrases, because a quote is a harder pattern to generate than a gist. The value is not that quotes are more reliable, though; it is that they are checkable in seconds.

For numbers, tighten the workflow further. Ask for a table: every figure the summary relies on, one row each, with the exact quote and location it came from.

Numbers deserve this because numeric errors in summaries follow a known pattern. Watch for unit slips (million read as billion), sign errors on changes (a 3 percent decline reported as growth), period confusion (quarter-over-quarter presented as year-over-year), and blended figures, where the model averages or merges two adjacent numbers from a table into one that appears nowhere in the document. Blended figures are the nastiest because they're usually close to plausible. A summary that says gross margin was 41.5 percent when the filing says 41.2 isn't going to jump out at you, which is exactly why the number needs a quote behind it.

Not every claim needs verification. Calibrate to consequence. A qualitative read on tone can stay unverified because you'd never size a position off it alone. A guidance number that feeds directly into your view of the implied move for the next earnings cycle gets checked every time. The question to ask is: if this specific claim is wrong, does my action change? If yes, verify. If no, let it ride.

11.3.3 Cross-checking with a second pass

Quote checking catches fabricated support. It doesn't catch a subtler failure: claims that are individually quote-supported but collectively misleading, or claims that slipped through without support because the summary buried them in connective tissue. For documents that matter, add a second pass built on the generation-and-critique split from the prompting lesson.

Open a fresh conversation. Provide the same source document and the summary you got from the first pass, and ask the inverted question:

Here is a document and a summary of it. Audit the summary. List every claim in the summary that is not directly supported by the document, every number that does not match the document exactly, and anything in the document that contradicts the summary. Be pedantic. An empty list is an acceptable answer only if the summary is genuinely clean.

The fresh conversation matters. A model asked to critique its own summary in the same thread tends to defend it, for the sycophancy reasons covered last lesson, and it also inherits whatever misreading produced the error in the first place. A clean context has neither problem. Running the audit on a different model than the one that wrote the summary is even better, since two models are unlikely to make the identical misreading, though the same model in a fresh thread catches most of what matters.

You can also invert direction: instead of asking what the summary got wrong, ask what it left out. "What in this document would a short seller emphasize that this summary does not mention" is a useful pass on any filing summary, and it doubles as an anti-sycophancy device, since it forces the model to build the opposing read.

Two passes plus spot-checked quotes sounds heavy. For an earnings transcript, the whole workflow runs maybe ten minutes against the forty-five it takes to read the call properly, and the ten-minute version is more reliable than a tired skim. The compression is real. It just isn't free.

11.3.4 Different documents fail in different places

Where you point your suspicion depends on the document type.

Filings reward the model most and punish it least. A 10-K is long, heavily boilerplated, and structured, all of which favor extraction. The highest-value filing prompt is not "summarize this" but "diff these": provide this year's risk factors section and last year's and ask what was added, removed, or reworded. Companies edit boilerplate reluctantly, so language changes in risk factors, legal proceedings, or liquidity discussion are often the only genuinely new information in the document, and a model finds textual diffs far faster than you can. Verification is still quotes and search, and it's easy because the source text is stable and formal.

Transcripts are messier. The model does well at pulling guidance and Q&A evasions, but transcripts introduce a failure mode filings don't have: speaker attribution. Models regularly assign a quote to the wrong executive or blur an analyst's framing of a question into management's answer. Whether the cautious line came from the CEO or from an analyst asking about caution changes what it means. When attribution matters to your read, check the speaker along with the quote. Tone reads ("did management sound defensive on pricing") are legitimately useful but treat them as a prompt for your own listen of that section, not a conclusion.

Research papers are the danger zone. A model summarizing an academic paper reliably reports the headline claim and reliably softens or drops the qualifications: the sample period, the universe restrictions, whether returns survive transaction costs, what the authors themselves flag as fragile. You read in the backtesting lessons why those qualifications are usually where the real information is. So for papers, don't ask for a summary. Ask a fixed battery: what exactly was tested, on what data and over what period, what was the effect size, what happens after costs, what do the authors list as limitations, and does the abstract claim more than the results section supports. That last question is worth asking explicitly, because abstracts oversell and models summarize from abstracts when allowed to. The battery format forces the model into the tables and sensitivity checks that summaries skip.

Contract specifications and exchange documentation get their own rule: never act on a model's answer alone. You saw in the futures lessons what a multiplier means for position sizing. A model that misstates a tick value or a contract multiplier produces a position that is wrong by an integer factor, and this is precisely the kind of dry numeric fact that models fumble across similar contracts (confusing the mini and micro versions of an index future is a classic). Specs live on exchange websites, they're short, and they're authoritative. Use the model to explain a spec, never to be the source of one.

11.3.5 Using a model to learn this course

Everything so far treats the model as a research assistant. It's at least as valuable as a tutor, and the failure modes are milder because when you're learning, you're usually checking its output against material you have (this course, the platform) rather than trusting it blind. Three patterns cover most of the value.

Socratic prompting inverts the usual direction. Instead of asking the model to explain a concept, tell it what you just studied and ask it to question you:

I just finished studying volatility risk premium: implied vol systematically exceeding subsequent realized vol, the insurance framing, when the premium inverts. Quiz me. One question at a time, starting basic and escalating. Do not give me the answer until I have attempted it. When I get something wrong, do not just correct me: ask a follow-up that exposes why my answer fails.

This works because retrieval is what builds retention. Reading an explanation feels like learning; being forced to produce the explanation is learning. The model is a patient examiner with unlimited time, and the one-question-at-a-time constraint stops it from dumping a quiz you will skim. The known weakness is that models drift easy and drift generous: they ask softball questions and grade kindly, the same sycophancy from last lesson, now in a tutor's role. Counter it in the prompt. "Escalate until I fail" and "grade like an examiner who needs to justify a fail, not a friend" both change behavior noticeably.

Worked examples with different numbers attack a specific gap: a course can show you one worked calculation, but competence comes from doing twenty. After the lesson on implied moves, ask:

Generate five practice problems on backing the implied move out of a straddle price. Vary the stock price, straddle price, and days to expiry. Give me only the problems. I will answer, then you show your solutions.

Then the necessary caution, which follows directly from what you learned about model arithmetic in the first lesson of this part: the model's problem setups are almost always sound, and its arithmetic is the least reliable part of the exchange. So do the arithmetic yourself with a calculator, and when your answer disagrees with the model's solution, don't assume you're the one who is wrong. Recompute both. Treat the model as the source of problem structure and variety, and treat a calculator as the source of numbers. Used that way, disagreements stop being a hazard and become free extra practice, because diagnosing whether the error is yours or the model's forces you through the calculation a second time with more attention than either pass alone would get.

The explain-then-test loop is the strongest of the three and the simplest. Write your own explanation of a concept from memory, paste it in, and ask the model to attack it:

Here is my from-memory explanation of why dealers being short gamma amplifies moves in the underlying. Find every error, every imprecise statement, and every gap. Then ask me two questions that test whether I actually understand the mechanism or just memorized the story.

Explaining a thing from memory is the fastest way to find the holes in your understanding, and the model makes the loop tight: you get the critique in seconds instead of waiting to be embarrassed by the market. The instruction to attack matters, because a bare "check this" gets you compliments plus one minor correction. The instruction to follow up with test questions matters more, because it catches the case where your words were right but your model of the mechanism wasn't.

One boundary on all three patterns. When the model says something about options mechanics or market structure that surprises you, that surprise is a signal to check the course material or the platform's actual behavior, not to update your beliefs on the spot. Models are strong on mainstream, well-documented concepts, which most of this course is, and they get shaky exactly at the corner cases: early exercise edge cases, settlement conventions, greek behavior at extremes. Surprise plus a corner case equals verify. The model is a tutor, not an oracle, and a tutor you can fact-check against primary material is worth ten you can't.

11.3.6 Deep research modes and their failure pattern

Every major model vendor now ships some version of a deep research mode: the model plans a research task, runs dozens of web searches, reads what it finds, and assembles a long cited report over several minutes. For a trader these are useful on breadth problems. Mapping an unfamiliar market before you trade it, understanding who the participants in a commodity are and what reports they watch, or building a first picture of a sector before an earnings season: these are tasks where you want fifty sources triaged, and the machine triages faster than you do.

Mapping the published research is one of the strongest uses of all, and worth calling out because traders underuse it. Point a search or deep-research tool at a topic, the momentum factor, the volatility risk premium, post-earnings drift, and ask it to find the key papers, who established what, and how the findings held up or got challenged over the years. It assembles in minutes a reading list that would take you weeks to build by hand, and the output is checkable because each paper either exists or it does not. Use it to find what to read, never as a substitute for reading it: the model is good at locating the literature and unreliable at preserving the parts that decide whether an effect is real, the sample period, the net-of-cost result, the out-of-sample record, the limitations the authors flag. Find the papers with the tool, then read those parts yourself.

The characteristic failure is confident synthesis over thin sources. The report format is the problem. A deep research output has the same structure and the same fluent, tidily cited authority whether it was built from primary documents and exchange data or from two blog posts and a press release repeated across twelve content-farm sites. The prose carries no signal about the foundation. And the citation counts flatter thin research, because the modern web is full of circular sourcing: one original claim, syndicated and rewritten across dozens of domains, gets cited as if it were dozens of independent confirmations. The model counts sources. It's bad at noticing that the sources are one source repeated twelve times.

Financial topics make this worse than average, because the ratio of derivative content to primary content in finance is terrible. For any question about a strategy, an indicator, or a market anomaly, the web offers a thin layer of primary material (filings, exchange documents, actual data) under a thick layer of recycled commentary, and deep research modes sample the thick layer because that's what search surfaces.

The discipline that makes deep research useful anyway is to change what you take from it. Don't consume the report as an answer. Consume it as an annotated bibliography with a draft narrative stapled on. Read the citation list before the prose. Click through every citation that supports a claim you might act on, and ask two questions of each: is this a primary source or commentary, and do the supposedly independent citations trace back to the same origin. A report where the load-bearing claims sit on primary sources is a genuine head start. A report where they sit on recycled commentary told you what the popular narrative is, which has some value, but a different value than truth.

The use cases sort cleanly by verifiability. "Map the reports and data releases that move the natural gas market and when each comes out" is a good deep research task: the output is a list of checkable facts, and being 90 percent right on the first pass saves you hours. "Is selling the earnings implied move still profitable in 2026" is a bad one: the model will synthesize a confident answer out of exactly the recycled commentary you shouldn't trust, and the actual answer requires the kind of testing discipline you built in the backtesting lessons, run on data, not on articles about data. Deep research finds sources and structures a field. It doesn't settle empirical questions, and the fluency of its reports is a constant temptation to pretend otherwise.

The verify-what-you-act-on habit carries directly into the next lesson with higher stakes. There the model isn't summarizing documents but writing code: your backtests, your data pipelines, your analysis scripts. A hallucinated quote costs you a wrong impression until you check it; a silently wrong backtest can cost you a strategy you fund with real money, and the checking habits have to scale to match.

11.4 AI for coding and data

Back in the backtesting lessons, the message was blunt: if you haven't tested an idea, you don't have an idea; you have a mood. For years the honest objection to that was "I can't code." That objection is gone. A model that writes working Python from a plain-English description has removed the barrier between a trader who wants to test something and the test actually running. You describe the rule, the model writes the script, the script runs, and twenty minutes later you've got an equity curve instead of a hunch.

What hasn't gone away is the failure mode that replaced it. The old failure was not testing at all. The new one is running code you don't understand, getting a number, and believing it. AI-written code fails in ways that look exactly like success: the script runs, produces a plausible chart, throws no errors, and is quietly wrong in a way that costs you money three months later. This lesson covers both halves: the stack that lets a non-engineer build backtests, data pipelines, and analysis scripts, and the verification discipline that makes the output trustworthy. The second half is the one that matters.

11.4.1 Why you should be writing code at all

Everything quantitative in this course becomes concrete the moment you can compute it yourself. Realized vol from the vol lessons, the COT index from the positioning lessons, expectancy and drawdown math from Part 10, the sizing chain: each of these is a few dozen lines of Python against a price series. Reading about vol targeting is one kind of understanding. Watching your own script scale positions up and down as realized vol moves is a different and better kind.

Spreadsheets carry you a surprising distance and then stop abruptly. The stopping points are predictable: anything with a rolling window over thousands of rows, anything that needs data pulled fresh from an API every day, anything you want to run across 50 symbols instead of one, and any backtest with path-dependent logic like trailing stops. Python handles all of these, and it's the language every model writes best, because the training data is full of it. Unless you've got a strong existing reason to use something else, use Python with the pandas library for tabular data. Every example in this lesson assumes that.

The good news about trading code specifically: you're not doing software engineering. There's no deployment, no users, no uptime, no security surface beyond your own API keys. You're writing scripts that run on your machine, for you, usually once a day or once per idea. That cuts away most of what makes professional software hard and leaves the part AI is genuinely good at: turning a clear description of a calculation into working code.

11.4.2 The stack: three tiers of tool

The tools in this space get renamed and replaced constantly, so hold the structure rather than the product names. There are three tiers, and they differ in how much of the loop the AI runs on its own.

The first tier is a chat window: ChatGPT, Claude, or any equivalent. You describe what you want, it writes code, you copy the code into a file and run it, then paste any error back into the chat. It's the right tool for one-off scripts and for learning. Slow for anything iterative, because you're the clipboard between the model and your machine, but that friction has an upside: you see every line before it runs.

The second tier is an AI-integrated editor, of which Cursor is the best-known example. It's a code editor with the model wired in: autocomplete that suggests whole blocks as you type, inline edits where you highlight code and describe a change, and an agent mode that can modify multiple files in your project. The editor sees your files as context, so you stop pasting code back and forth. This tier fits once you've got a small project rather than single scripts: a folder with a data-fetching script, a backtest, and some shared helper functions.

The third tier is a terminal agent, of which Claude Code is the canonical example. You give it a task in plain English and it works autonomously in a loop: reads your files, writes code, runs it, reads the error, fixes the code, runs it again, and comes back when it's done or stuck. This is the most powerful tier and the one where the verification discipline below stops being advice and becomes survival. An agent that runs its own code can also convince itself that wrong code works, because "the script ran without errors" and "the script computed the right thing" are different claims, and only a human who knows what the right answer looks like can check the second one.

Start at tier one. Move to tier two when copy-pasting becomes the bottleneck. Use tier three when you're comfortable reading diffs, meaning the before-and-after view of what changed in your files. For current capabilities and setup, go straight to the official documentation of whichever tool you pick; anything more specific written here would be stale within months, and the vendors keep their docs current because their business depends on it.

11.4.3 Asking for code that comes back right

The prompting fundamentals from two lessons ago apply directly, with one addition specific to code: the model needs to know the shape of your data, and it'll guess wrong if you don't show it.

Before asking for any script that processes a file, paste the first five rows of the file into the prompt. Column names, date formats, whether there's a header row, how missing values are represented. The most common first-attempt failure in data code is the model assuming a column is named "Close" when yours is named "close_price", or assuming dates look like 2024-03-15 when yours look like 15/03/2024. Thirty seconds of pasting a sample eliminates the whole category.

Specify behavior at the edges, because edges are where trading calculations break. What should happen on the first 20 rows of a 20-day rolling calculation, before the window is full? What should happen if a date is missing because of a holiday? If two rows share a timestamp? A working request looks like this:

I have a CSV of daily OHLC data, sample below. Write a Python
script that computes 20-day close-to-close realized volatility,
annualized with sqrt(252), as a new column.

Requirements:
- Use log returns, not simple returns.
- The first 20 rows should be NaN, not zero and not partial-window.
- If any close is missing or zero, stop with an error that names
  the row. Do not fill it silently.
- Print the last 5 rows so I can check the output.

Sample:
date,open,high,low,close
2024-01-02,472.16,473.67,470.49,472.65
2024-01-03,470.02,471.19,468.30,468.79

The last requirement in the list, "Do not fill it silently," matters because the model's default instinct, absorbed from a million tutorials, is to make code run at any cost, and the cheapest way to make code run is to paper over bad data. You want the opposite default: loud failure. A script that crashes on bad data costs you five minutes. One that silently forward-fills a week of missing prices costs you a backtest built on flat, fictional data.

Work in small steps. "Build me a complete backtesting system for my strategy" produces a large pile of code you can't check. "Write a function that loads and validates the data" then "write a function that computes the signal" then "write the trade simulation loop" produces three small pieces you can verify one at a time. Slower per prompt, much faster per correct result. It also matches how the verification below works: you test components against known answers, and components have to exist separately to be testable.

And paste errors verbatim, the full message including the line numbers and the traceback. Models are genuinely excellent at reading error output. Summarizing the error in your own words throws away the exact information the model needs.

11.4.4 Verifying what the model wrote

Adopt this working assumption permanently: AI-written trading code is wrong until it has passed a check against a known answer. Not because the models are bad at code (they're good and improving) but because trading code has a property most code doesn't: its bugs produce numbers instead of crashes. A web page with a bug looks broken. A backtest with a bug looks like an edge.

The discipline has four parts, in escalating order of effort.

First, read what it wrote. You don't need to be able to write pandas from scratch to read it, and reading is a skill you build far faster than writing. When a line is opaque, ask the model itself: "explain line 14 token by token, what does shift(1) do to the signal column and why is it there?" Then, for anything load-bearing, check the explanation against the library's documentation rather than taking the model's word, since a model can misdescribe its own code as fluently as it wrote it. After a few weeks of this loop you'll read rolling-window and groupby code comfortably, which is most of what trading scripts contain.

Second, test with known answers. Before trusting a calculation on your real data, run it on data where you already know the result. A vol calculation is the cleanest example. Feed the script a series that alternates up 1 percent, down 1 percent, forever. Every daily log return has the same magnitude, so daily vol is almost exactly 1 percent, and annualized it should print very close to 16 percent, which you know without a computer because the rule of 16 from the realized vol lesson is sqrt(252) rounded to a memorable number. If the script prints 16, the core math is right. If it prints 4.5 or 32 or 0.16, you've just caught, respectively, annualizing by the window length instead of the trading-day count, a doubled calculation, or a units mix-up, in thirty seconds, before it touched anything real. Every calculation you rely on deserves one synthetic test like this: a series where the answer is known by construction. Ask the model to write the test too, but you choose the known answer, because a model asked to grade its own work leans toward passing itself.

Third, sanity-check outputs against hand arithmetic and against the platform. Pick one number from the script's output and reproduce it on a calculator from the raw inputs. One is enough to catch most systematic errors, because systematic errors corrupt every row, not just some. And when you compute something this platform also computes, compare. If your 30-day IV percentile or your COT index for the same symbol and date is far from what the site shows, one of you is wrong, and finding out which one teaches you something either way. Small differences are normal (window conventions, data vendors, timestamps differ); a large difference is a bug hunt you should not skip.

Fourth, spot-verify every backtest at the trade level before believing its summary statistics. This ties directly back to the backtesting lessons: you already know that look-ahead bias and overfitting produce beautiful fake equity curves. AI assistance adds a new route to the same disease, because the model can introduce look-ahead in a single character and the code still reads plausibly. The procedure: have the script output a trade log, every entry and exit with dates and prices, then pick three trades at random and replay each one by hand against the raw data. Look at the bar where the signal supposedly fired. Could you have actually known the signal value at that moment? Was the fill price available then, or is the trade entering at the close of the same bar whose close triggered the signal? Do the P&L numbers match your hand calculation including the costs you specified? Three trades checked honestly will catch the majority of backtest-invalidating bugs. If you can't spare fifteen minutes for that, you didn't want a test; you wanted the mood after all.

11.4.5 Where AI code goes wrong in trading, specifically

Certain bugs recur constantly in model-written trading code, and knowing the short list turns verification from a vague duty into a checklist. The deep reason behind the worst of them: the model has read vastly more tutorial code than production trading code, and tutorial code is riddled with look-ahead because tutorials optimize for a nice chart.

Two of these deserve a longer look because they're so cheap to commit and so expensive to carry.

The shift bug first. In pandas, signal.shift(1) moves the signal forward in time so that today's position depends on yesterday's information, which is the honest construction. The model usually gets this right, but "usually" is the problem, and when you later ask for a modification ("also add a filter on the 50-day average"), the edit is where the shift quietly disappears or flips. Every time a backtest is edited, re-run the trade-level spot check. Edits are more dangerous than first drafts because your guard is down.

The synthetic-data fallback second, because it's uniquely a failure of agent-tier tools. An agent whose data fetch fails is trained toward completing the task, and one way to complete a task is to fabricate inputs that let the rest of the pipeline run. The models have gotten better about announcing when they do this, but the stakes are too high to rely on the announcement. The defense is a standing instruction in your project (both Cursor and Claude Code support a persistent instructions file that's included with every request): "Never generate placeholder, sample, or synthetic market data under any circumstances. If data is missing or a fetch fails, stop and report the failure." Write that once and the whole category mostly closes.

11.4.6 Getting data

Analysis is downstream of data, and data work is where AI assistance pays off most per hour, because data work is glue code: fetching, parsing, reshaping, joining. Glue code is tedious for humans and trivial for models. The division of labor is clean. The model writes the plumbing; you decide what to plumb and check what came through the pipe.

APIs are the front door and should be your default. An API is just a URL that returns data in a structured format, almost always JSON, and the workflow barely varies across providers: sign up, get a key, put the key in the request, respect the rate limit, page through results. Crypto is the easy case, since major exchanges expose free public endpoints for candles, funding rates, and open interest with generous limits. Equities and options are the hard case: free sources are delayed, thin, or restrictively licensed, and serious options data is paid at every tier. Government and central bank statistical data sits at the other extreme: free, clean, well-documented, and ideal for macro series.

Practical points that survive tool churn. Read the API's own documentation for the endpoint you need, then paste the relevant section into your prompt; the model may know an outdated version of the interface, and the pasted doc overrides its memory, which is the same quote-and-verify move from the research lesson applied to code. Store keys in a separate file or environment variable, never in the script itself, so a script you later share doesn't carry your credentials. Write the fetched raw data to disk before transforming anything, so a bug in your processing never forces a re-download and you can always diff today's pull against yesterday's. And cache aggressively: a script that hits the API once and reads from disk afterward is faster for you and politer to the provider.

Scraping, meaning extracting data from web pages built for human eyes, is the fallback when no API exists, and you should treat it as the fallback it is. The model will happily write you a scraper: fetch the page, parse the HTML, pull the numbers out of the table. It'll work, and then it'll break, silently, the next time the site changes its layout, and a pipeline that breaks silently is worse than no pipeline. If you scrape, check the site's terms first (some data is contractually off limits and some sites will ban you), keep the request rate low, and build the scraper to fail loudly: assert that the table has the expected columns and a plausible row count on every run, so a layout change produces an error instead of garbage. Better yet, before scraping at all, check whether the page loads its numbers from an internal JSON endpoint you can call directly; the browser's network inspector shows this in a minute, and the model can walk you through looking. The JSON route is faster and far less brittle.

11.4.7 Cleaning what you collected

Raw market data lies. Bad ticks, missing sessions, duplicate rows, unadjusted corporate actions, timezone mismatches. The cleaning code is glue, so the model writes it, but the specification of what "clean" means is a trading judgment, so that part is yours. Give every new dataset the same battery before it feeds anything downstream: confirm the date range matches what you asked for, confirm the row count is plausible (a year of daily equity data is around 252 rows, and a year of daily crypto is 365, and confusing those two calendars is itself a classic bug), list any duplicated timestamps, list gaps and check them against the exchange holiday calendar so you can distinguish a legitimate closure from lost data, and flag any single-bar return beyond a threshold you set for manual review rather than automatic deletion.

That last distinction is worth a sentence, because a data pipeline is a backtest input and the backtesting lessons apply. An outlier in crypto is often a real flash move you absolutely want in your data, since liquidation cascades are half the point. The same-sized outlier in a large-cap equity is more likely a bad print or an unadjusted split. A cleaning rule that auto-deletes big moves would sand the most informative bars out of your dataset. Flag, inspect, then decide. Have the model wrap this whole battery into one validation function you run on every dataset forever; writing it is an afternoon, and it upgrades every analysis you do afterward.

A note on keeping the pile organized, kept short because light structure is all a one-person operation needs. One folder per project, raw data separated from processed data, a requirements file listing the libraries so the setup is reproducible, and version control with git, which the agent tools will set up and drive for you if you ask. Git earns its place the first time an agent rewrites a working script into a broken one and you get the working version back with one command instead of an evening of reconstruction.

The build is the easy part. Placement is what's left: where AI-assisted work actually belongs inside a live trading routine, where it has no business being, and what should never leave your machine in a prompt. That's the final lesson.

11.5 AI in the trading workflow

The last four lessons gave you the mechanics: how the models work and why they fabricate, how to prompt around your own bias, how to research documents without absorbing their mistakes, and how to get working code out of a machine that has never traded. This lesson is about placement. You have a powerful tool and a trading process built over ten parts of this course. The question is where the tool plugs into the process and where it must be kept out.

The rule is simple, and every section below applies it. A language model belongs wherever its output is cheap to verify and expensive to produce. It doesn't belong anywhere its output is expensive to verify, and it especially doesn't belong anywhere its output can't be verified at all. Compressing an hour of reading into five minutes is cheap to verify: the source material is right there, and the research lesson gave you the workflows. A prediction about next week's price is impossible to verify until next week, by which point you've already acted on it. That asymmetry decides where they fit, not any judgment about how smart the models are.

There's a second dividing line. Your trading process, if you built it the way Part 10 argued, has two layers: a text layer (research, journaling, idea generation, learning) and a numbers-and-rules layer (signals, sizing, stops, orders). The model is a text machine. It's best on the text layer and most dangerous when it leaks into the rules layer, because the rules layer is the part you systematized so that nothing, including a persuasive machine, could talk you out of it at the wrong moment.

11.5.1 Using it before the open

The morning is where most traders first find a real daily use. The portfolio process lesson back in Part 10 sketched a morning workflow through the platform's dashboards: regime first, then positioning, then whatever your active strategies need. Nothing in that workflow changes. The dashboards give you numbers, and numbers aren't what you need a model for. The model compresses the text around the numbers: overnight headlines, the day's scheduled events, anything that broke in markets you hold positions in.

The mechanics follow directly from the research lesson. Don't ask a bare chat model what happened overnight. A model without tools has no overnight; it has a training cutoff, and it will fill the gap with plausible text. Either use a product with live search attached and treat the citations with the suspicion you learned two lessons ago, or, better for a repeatable routine, feed it the material yourself: paste the headlines from your news feed, the day's calendar entries, and anything relevant you flagged the evening before, then ask for a brief in a fixed format. A prompt for this looks like this:

Here are today's scheduled events and the overnight headlines I collected, pasted below. Produce a pre-market brief in exactly this format: (1) scheduled releases today with times, (2) anything overnight that plausibly affects crude, gold, or BTC, one line each with the source headline quoted, (3) anything here that contradicts or updates what I noted yesterday, which I have also pasted. Do not add market commentary, do not predict reactions, and if a section is empty write "nothing."

Three constraints in that prompt matter. The fixed format stops the model from writing an essay. The quoted-headline requirement is the same checkability move as the quote-and-verify workflow, scaled down. And "do not predict reactions" shuts off something the model does otherwise: a model asked about a CPI print will happily speculate about what the market will do with it, and that speculation is the confident-sounding noise you don't want in your head at 8 a.m. Event times still get checked against the platform's events calendar or the primary source. A wrong release time is the kind of small specific fact models fumble, and the macro events lesson already showed you what being positioned wrong into a print costs.

This saves maybe twenty to forty minutes on a news-heavy morning and close to nothing on a quiet one. The value is the consistency more than the minutes. A compressed brief in a fixed format gets read every day; forty browser tabs get skimmed when you feel like it. What the model must not do in this slot is form the view for you. The brief tells you what's scheduled and what happened. What it means for your positions runs through the regime and positioning reads you built in Parts 4 through 6, and those come off the platform, not out of a chat window.

11.5.2 The journal review

This is the most underused application in this lesson and the one most likely to change your routine. Back in the semi-systematic lesson, the argument was that discretion belongs in trade selection and everything after entry should run on rails. The journal is where you find out whether that's actually true of your trading. Journals have a well-known failure mode: people write them and never honestly reread them, because rereading your own losers is unpleasant and your memory is happy to smooth the record. A model has no such problem. It reads all fifty entries with the same attention, has no ego invested in any of them, and doesn't remember that the third one still stings.

The precondition is a journal worth analyzing. Free-text feelings help less than structured fields: date, instrument, direction, planned entry and stop and target, actual entry and exit, size, the setup name, and a one-line reason written before the trade. If your journal has that structure, the review is one paste and two prompts. The two prompts should be separate turns, for the generation-and-critique reasons covered in the prompting lesson: first description, then interpretation.

Here are my last 60 journal entries as a table. First pass, description only: report any patterns you can support by counting rows. Compare winners and losers on: setup type, day of week, size relative to my median size, whether the actual exit matched the planned exit, and time between a losing trade and the next trade opened. Quote the row counts for every pattern you claim. Do not give advice yet.

Then, in the next turn, ask what the patterns might mean and what you should check. The counting constraint is what matters most. Without it, the model does what it does with any text: it produces plausible narrative, and plausible narrative about your trading psychology is worse than nothing because it feels like insight. With it, you get claims of the form "in 9 of your 11 largest losses, the actual exit was later than the planned stop," which is checkable in thirty seconds against your own table and devastating in the way only your own numbers can be.

The patterns this exercise tends to surface are the classics: size creep after winning streaks, a specific setup that accounts for most of the P&L while the other setups churn, stops honored on small positions and negotiated on large ones, and a cluster of impulsive entries within an hour of a big loss. None of these require a model to find. All of them require someone to actually look, and the model always looks.

Two cautions, both echoes of Part 10. The model finds patterns in noise as readily as patterns in signal, because pattern completion is what it does. Sixty trades is a small sample; you learned in the distributions lesson how long variance can masquerade as skill, and the same math means a day-of-week effect in sixty trades is almost certainly nothing. Treat every finding as a hypothesis, and either confirm it by counting a larger sample or demote it. The other caution: the model can only audit what you wrote down. A journal that omits the trades you're embarrassed by, or backfills reasons after the exit, produces a flattering review of a fictional trader. The garbage-in rule has no AI exception.

11.5.3 Unfamiliar paperwork and products

The third fit is the explainer role, pointed at documents you would otherwise skim or skip: a structured note term sheet, the prospectus of an ETF you are considering as a hedge, an exchange's margin methodology document, a broker's updated fee schedule, the settlement rules of a contract you are trading for the first time. The exotics lesson back in Part 2 gave you the concepts behind products like autocallables; a model gives you a fast reading of the specific document in front of you.

The research lesson already built the workflow, so this section is short and points at it: source in context, claims backed by quotes, spot-check what you would act on, and never let a model be the source of a contract spec when the exchange publishes the real one. The technique to add here works unusually well on product documents: scenario interrogation. Instead of asking what the document says, ask what happens to you. "Walk me through exactly what I receive, per the terms in this document, if the underlying is down 35 percent at the second observation date and recovers by maturity. Quote the clauses you used." Payoff documents are written as nested conditions. Models are good at tracing nested conditions when the text is in context, and a wrong trace is catchable because the quoted clauses either support the walkthrough or they don't. Run two or three scenarios including an ugly one, and you understand the product better than most people holding it. Then, per the futures lessons, anything that feeds a sizing decision (multiplier, margin, settlement style) gets confirmed against the primary source anyway.

11.5.4 From hunch to testable rule

The last fit sits at the boundary of the coding lesson, one step before it. You have a hunch: "alt perps seem to dump after funding gets extreme," or "the ES overnight session fades big gaps more often than it follows them." The backtesting lessons made the standard clear: an idea you haven't specified precisely enough to test is a mood. The step from mood to specification is a conversation, and it's a conversation models run well, because their weakness (no market knowledge you can trust) doesn't matter here and their strength (noticing vague language) is exactly what the job needs.

The prompt pattern is an interview with the roles reversed:

I have a vague trading idea: [state it in whatever loose terms you actually think about it]. Interview me, one question at a time, until the idea is specified tightly enough that a programmer could implement a backtest without asking me anything. Push on every word I use that is not quantified. When we are done, write the full specification back to me, including the universe, the exact signal definition, entry and exit timing, what data is needed, and what benchmark the result should be compared against.

Run that on the funding hunch and the model will, within a few questions, force answers out of you that you didn't know you owed: which symbols count as alt perps, extreme by what measure and over what window, does the dump have to start within a day or a week, entry on the close that triggers the signal or the next one, exit on a fixed horizon or a stop, and compared to what, because "alts dumped" during a period when everything dumped isn't a finding. Every one of those questions is a place where an untested idea hides its emptiness. You met this in the backtesting lessons as the overfitting and vague-hypothesis problem; the interview is the cheapest tool that attacks it before any code exists.

One more prompt belongs in this slot, run after the specification and before the backtest: "List the ways this rule could look profitable in a backtest while being untradeable or unprofitable live." The model will produce a decent pre-mortem (execution assumptions on illiquid alts, signals that cluster in one regime, costs, the survivorship in today's symbol list) and you'll recognize every item, because Part 10 taught all of them. Having them listed against your specific idea, before you fall in love with an equity curve, is the point. From there, the coding lesson takes over: small steps, known-answer tests, trade-level spot checks.

11.5.5 Where the model must be kept out

The fits above share the property from the top of the lesson: checkable output, source material in the window, text work rather than rules work. The misfits share the opposite property, and the three below account for most of the real money lost to these tools.

11.5.5.1 Predictions and signals

Asking a chat model where a market is going is a category error, and the reason survives every improvement in the models. A model synthesizes public text. Markets price public information; you spent the technical analysis part on exactly what is and isn't left over after they do. The best case, with live search attached and everything working, is that the model hands you a fluent summary of the current consensus narrative, which is the one thing already in the price. The worst case, without tools, is that it hands you a plausible continuation of stale training text. In both cases it answers confidently, because a confident tone tells you nothing about whether an answer is right, as the first lesson of this part established. And in both cases the answer is unverifiable at decision time, which fails the test this entire lesson runs on.

There's also a market-structure argument you can carry as a shortcut: any model that could genuinely predict returns would be monetized upstream of you, quietly, at scale. It wouldn't be available in a consumer chat product. The absence of that arbitrage is information.

The subtle version of this mistake is worse than the blatant one, because it looks like diligence. You describe your setup, your levels, your thesis, with all the enthusiasm of someone already positioned, and ask the model what it thinks. The prompting lesson told you what happens next: the model mirrors your framing and hands your own bias back with better prose and a tone of independent confirmation. That isn't analysis. You've laundered your conviction through a machine and made it feel like consensus. If you want the model anywhere near an active idea, use the patterns from that lesson: hide your side, ask for the strongest case against, ask what would change your mind. Those get you something useful. "Thoughts on my long?" gets you a mirror.

11.5.5.2 Sizing and risk decisions

Sizing is arithmetic applied to rules: your account, your vol target, the instrument's volatility, the sizing chain from Part 10. Two properties of language models make them the wrong tool for it, and they compound. Arithmetic is a known weak point; the first lesson of this part covered why a text predictor fumbles multi-step calculation, and a sizing error is wrong by a factor, not by a rounding. More dangerous: a conversation is a negotiation, and your risk rules exist precisely so that nothing is negotiable. The semi-systematic lesson put it plainly: overbetting kills more traders than bad analysis, and the cure is rules that remove the decision at the moment of temptation. A chat model is a machine for reopening decisions. The night you most want an exception to your max risk per trade is the night you'll find yourself describing the setup to a model in terms that invite it to agree the exception is reasonable, and it will agree, fluently, because agreement is what the tuning rewards.

So the rule is structural, not attitudinal: sizing lives in a spreadsheet or a script, deterministic, written once and tested against hand calculations, exactly as the coding lesson described. The model can help you build that calculator; the model must never be the calculator at decision time. The same applies to mid-trade management. "Should I hold or cut this position" typed into a chat window is asking an entity with no account, no history, and no stake to co-sign whatever your framing already implies. Your exit was defined before entry, on rails. Keep it there.

11.5.5.3 Anything you cannot verify

The general rule, restated once because everything above instantiates it: output you cannot check is output you cannot use, no matter how good it sounds. If a model's answer would change your position and you have no independent way to confirm it before acting, the answer isn't information yet. Either build the verification step or drop the use case.

11.5.6 A human on every order

Separate from where the model advises is the question of what it is allowed to touch, and here the line should be absolute: no language model output flows into an order without a human reading it first.

What this prohibits is narrow, and Part 10 explicitly endorsed automation. Deterministic automation of tested rules is fine: a script that computes your signal and sizes per your fixed formula is the rails the semi-systematic lesson argued for, and a model can help you write that script. The prohibition is on model calls inside the live path between signal and order: an agent that reads the news and trades on its reading, a bot that asks a model whether conditions look favorable and executes on the reply. The difference is that the script does the same thing every time and was tested; the model is nondeterministic (the same prompt can produce different answers on different runs), untestable in the backtest sense, and, if it reads external content, injectable. That last risk is easy to underestimate: a model that browses pages or feeds can be steered by instructions embedded in the content it reads, which means anyone who can get text in front of your agent can, in principle, get intent into your order flow. A pipeline where the model drafts and a human confirms keeps every benefit of the assistance and none of these failure modes. Read the order. Every order.

11.5.7 What not to paste

Everything in this part involves putting your material into someone else's software, so a short hygiene section, in descending order of severity.

Never paste credentials: broker logins, API keys, seed phrases, anything that authenticates as you. This is absolute, applies to every tool regardless of its privacy policy, and was already flagged in the coding lesson for keys embedded in scripts. A pasted key should be treated as a burned key.

Keep account identifiers out: account numbers, full statements with your name and address, tax documents. If you want a model to analyze a statement, strip the identity and keep the rows. The journal workflow above needs your trades, not your account number, and works exactly as well without it.

The data settings of the tool you use matter. Consumer chat products may use conversations for training depending on the plan and the toggles; API and business tiers generally commit not to. The specifics change and live in each vendor's data-usage documentation, which is the only current source worth consulting. In practice, assume anything pasted into a consumer tool with default settings may be retained, and decide what you paste accordingly. Your journal and your half-formed hunches are, realistically, of no value to anyone else. A genuinely proprietary edge, if you believe you have one, deserves the same paranoia you'd apply to emailing it to a stranger. And other people's confidential information (anything under NDA, anyone else's account data) doesn't go in at all, since the pasting decision was never yours to make.

11.5.8 Keeping pace without chasing

The warning label from the first lesson of this part applies to this lesson most of all: the placement decisions above are drawn where the capability lines sat when this was written, and capability lines move. Some of what this lesson filed under "does not fit" is there for structural reasons that won't move (unverifiable predictions, negotiable risk rules), but the boundary of what models do reliably has expanded every year, and tasks that failed cleanly two years ago work today.

So put a recurring review in the calendar, every few months: review which tasks you gave to AI and which you withheld, retry one task that failed last time, and check current capabilities against the official vendor documentation rather than against social media enthusiasm, which runs well ahead of reality in both directions. What you shouldn't revisit are the principles, because they don't date: verify what you act on, keep the model on the text layer and the rules on rails, read every order, and never paste what you can't afford to have retained. Product names will change over time. The discipline stays the same.

11.5.9 What this whole approach built

A concrete example to close on, because it answers the obvious question hanging over this part: what does a trader who uses these tools well, but is not a quant, actually end up with?

This is my own systematic book. I am not a quant. I have no deep software-engineering background and no advanced math, and I lead with that because it shaped every choice in the portfolio. Knowing what I cannot do, I did not try to compete where the specialists win. I do not build market-making systems, I do not hunt fleeting inefficiencies, and I do not chase alpha in the strict sense this course has been careful to define. Those games are played by teams with resources and speed I do not have, and using an AI to pretend otherwise is the fastest way to hand money to people who genuinely have the edge.

What I did instead is the thing this course argues for from Part 7 on: harvest low-frequency risk premia that are public, durable, and slow enough to run by hand, momentum and trend, the volatility risk premium, carry, and a handful of others, then lean on diversification across a range of them rather than on being right about any single one. No individual sleeve is remarkable. The book is, because the sleeves lose on different days.

That result, roughly a 1.8 Sharpe against the index's 0.9 at a fraction of the drawdown, was built and is run by someone with no special quantitative training, using exactly the AI-assisted workflow this part describes: models to write and check the code, to read the research, to speed up the reading, and never to make a prediction, size a position, or be trusted at face value. The edge is not the AI. The edge is picking a game I can actually play, and then verifying everything the machine hands me.

Which is the real lesson of this part. Watch different people use these tools and the outcomes are wildly unequal, and the gap has almost nothing to do with who has the best model, because everyone has the same models. The gap is between the person who can think a problem through, break it into pieces small enough to check, and verify each piece against something real, and the person who types a vague request and pastes the confident answer into their account. The first compounds the tool's leverage. The second compounds its errors, and in trading, compounding errors is just the long way of saying losing money. AI raises the ceiling for the careful and lowers the floor for the lazy at the same time, and which one it does for you is entirely a function of how much thinking you are still willing to do. The lazy path loses here, faster and more expensively than it did before these tools existed, because now the mistakes arrive fluent, confident, and at scale.

11.5.10 Take the whole course with you

The entire course is available as a single file you can give to a model as its knowledge, so that Claude, ChatGPT, or whatever you use becomes a tutor that has read all of it. Download it here: the whole course as one file. It is the whole course, so it is large: upload it as a file to a Claude Project or a ChatGPT conversation, both of which retrieve from an attached file rather than needing it pasted inline, then ask against it: "explain the forward-volatility trade using the calendar example from Part 9," or "quiz me on the vol-targeting lesson, one question at a time," or "I don't follow why the all-weather core needs futures, walk me through it." For a quick question about a single lesson, pasting just that section into any chat works too.

Two reminders, both from this part. Once the file is loaded the model answers from the course text rather than its own memory, which is the situation where it is most reliable, so lean on it for anything the course covers, and ask it to quote the passage when an answer matters; treat anything it adds beyond the text as a guess. And everything the course says about verification applies to the course's own numbers too: if a figure is going to touch your account, check it against the platform and the primary source, not against a chatbot's paraphrase of a lesson. Used that way, the course stops being something you read once and becomes something you can interrogate for as long as you keep trading.

That closes the part on AI and the course with it. Everything the tools compress feeds the process you built across the earlier parts, and never the reverse: the reading gets faster, and the decisions stay where you put them. The tools speed up the reading; the trading is still yours.