You do not need to know how a diesel engine combusts fuel to run a generator, but you do need to know it will not run on gasoline, that it needs to warm up, and that it will stall if you starve it of air. A large language model is the same. You will never read its weights, but if you understand four things about how it actually works, you will stop being surprised by its failures and start preventing them. Those four things are tokens, the context window, the training cutoff, and the reason it cannot truly see your sketch. Get these and you will know, before you ever hit send, why the model just told you the 2018 code was current and invented a clause that has never existed.

The One Thing the Model Actually Does

Strip away the chat interface and a large language model, an LLM, does exactly one thing: it predicts the next chunk of text. That is the entire engine. You give it some words, and it asks, given everything I have read, what word most plausibly comes next, then it does that again, and again, until your answer is built. It is autocomplete that went to graduate school. Everything impressive it does and everything dangerous it does both flow from this single fact.

This is why it is so good at drafting an RFI and so willing to fabricate the spec section inside it. Drafting an RFI is a prediction task; the model has seen thousands of RFIs and knows what the next sentence of one sounds like. Citing the correct spec section is a retrieval task, a question of fact, and the model is not retrieving, it is predicting. When you ask for "the section governing traffic-bearing waterproofing," it predicts a number that looks like a real section number in the right format, because that is the most plausible-sounding continuation, and plausible is not the same as filed in the actual project manual. The model is not consulting your specs. It is doing impressions of a person who has.

Hold onto that frame, because the four mechanics below are all just consequences of "it predicts the next chunk of text." None of them are bugs. They are the shape of the engine.

Tokens, and Why 1,847 Pages of Spec Do Not Fit

The "chunks" the model reads and writes are called tokens. A token is a piece of a word, usually about four characters of English, so "waterproofing" is two or three tokens and "RFI" is one. The model does not see letters or even words exactly; it sees a stream of tokens. This sounds like trivia until you learn the rule that governs everything: a model can only hold so many tokens at once. That limit is the context window, and it is the single most important constraint a builder needs to understand.

Think of the context window as the model's workbench, not its memory. Everything it can actually reason about at this moment, your prompt, the documents you pasted, the conversation so far, and the answer it is writing, all have to fit on the workbench at the same time. The workbench is large in modern models, often hundreds of thousands of tokens, but it is not infinite, and a full project specification is enormous. An 1,847-page spec book is on the order of a million words, well past what most models will take in one pass, and even when it fits, the model's attention spreads thin across that much material.

This explains a failure you have probably already hit: you paste a long document, ask a precise question, and get an answer that is right about the early pages and vague or wrong about the later ones, or that "forgets" something you told it twenty messages ago. The information fell off the workbench. It was never stored; it was just sitting there, and the bench ran out of room. The practical consequence is that you do not dump a 1,847-page spec on a general chatbot and trust the answer. You either feed it the relevant sections only, or you use a tool built to index the whole document and retrieve the right piece, which is a different architecture we will name in the vocabulary lesson. The context window is why "summarize this entire spec" is a request that sounds reasonable and produces mush.

The context window is a workbench, not a filing cabinet. If it does not fit on the bench right now, the model cannot reason about it, no matter how confidently it answers.

The Training Cutoff, and Why It Cites the 2018 Code

A model learns by reading an enormous pile of text, once, during training. After that, its knowledge is frozen at the moment training stopped, a date called the training cutoff. Everything it "knows" is a snapshot taken on that day. It did not read the news this morning. It does not know what changed last quarter unless you tell it, in the prompt, on the workbench.

For a builder this is not an abstract limitation; it is a direct line to specific, expensive errors. Codes adopt on cycles. If a model's most heavily represented training data leaned on the 2018 International Building Code because that is what dominated the internet when it trained, it will reach for 2018 provisions even though your jurisdiction adopted the 2024 IBC. It will cite ASHRAE 90.1 from an older edition, reference a superseded NEC article, or describe an AIA contract clause from a prior edition, all with the same calm confidence. The model is not out of date on purpose. It froze, and the world kept moving, and code editions are exactly the kind of thing that moves.

The discipline this demands is to treat the model as knowledgeable but not current. Anything that depends on the live state of the world, which edition is in force, which product is the latest, what a clause says in the 2017 version versus the 2007 version, has to be supplied by you or verified by you against the published source. A useful habit: when a code or standard answer matters, you name the exact edition in your prompt and then you check the cited provision in the actual adopted code, because the model's instinct will drift toward whatever edition it read most of, not whatever edition your AHJ enforces.

Why It Cannot Really See the Revision Cloud on Your Sketch

Many models now accept images, and this creates a dangerous illusion that the model "sees" a drawing the way you do. It does not. When you upload a marked-up sketch, an SK, the model converts the image into a representation it can process and then, you guessed it, predicts a plausible description of what is in it. It is good at the gist: this is a floor plan, there is a door here, there is text that says something about a beam. It is unreliable at exactly the things that matter most on a construction document.

The failures are specific and worth memorizing because they are not random. The model confuses a section cut with a plan view because both are lines on a page and it is inferring, not understanding geometry. It miscounts revision clouds because counting precise instances of a shape is not what prediction is good at. It misreads a hand-redline because handwriting at an angle is far from its strongest data. It will assign the wrong wall type because the legend that defines that hatch pattern is on a different sheet it never saw, and it will confidently fill the gap with a guess rather than tell you the legend is missing. None of this is the model being careless. It is the model doing impressions of someone reading your drawing, without the spatial reasoning, the cross-sheet references, or the trained eye that a project engineer brings.

So the rule for drawings is the strictest of all: an AI description of a drawing is a starting hypothesis, never a finding. Before anything the model says about an SK gets forwarded to a sub or acted on, a human who can actually read the sheet confirms it against the legend, the revision history, and the adjacent sheets. The image upload is a convenience for orientation, not a substitute for plan reading, and treating it as the latter is how a misread hatch pattern becomes a wrong-material installation.

Putting the Four Together: A Worked Failure

Watch all four mechanics combine in one realistic moment, because seeing them interact is what makes the lesson stick. An intern architect on the AXP track is racing a permit set and asks a general chatbot to "write a code narrative for means of egress, and check the egress against the floor plan." They paste a long program document and upload a floor-plan image.

Here is what the four mechanics produce. Because of the training cutoff, the narrative cites the 2021 IBC even though the jurisdiction is on 2024, and it confidently references section numbers, at least one of which, the infamous fabricated egress section, does not exist in any edition, because the model predicted a plausible-looking number rather than retrieving a real one. Because of the context window, the long program document's later requirements got thin attention, so a key occupancy assumption is quietly dropped. Because the model cannot truly see the drawing, its "check" against the floor plan is a confident narration that does not actually reconcile the egress widths to the area calculations, and it misreads a stair as a corridor. Every sentence sounds authoritative. The plan checker, who rejects packages within ninety minutes if the egress diagram does not match the area calcs, would bounce it on intake.

The intern who understands the four mechanics reads that output completely differently. They take the prose as a fast first draft, they re-run the code citations against the adopted 2024 IBC and delete the fabricated section, they re-check the dropped occupancy requirement themselves because they know the late pages got short attention, and they do the egress-to-area reconciliation by hand because they know the model never really saw the plan. Same tool, same output, opposite result, because one person knows what the engine is and the other thinks it is a colleague. That difference is the entire return on understanding how the model works.

The One Question That Predicts Every Failure

If you remember nothing else mechanical from this lesson, carry one question into every interaction: is what I am asking a prediction task or a retrieval task? That single distinction sorts almost every LLM behavior a builder will encounter into "trust the draft" or "verify the fact," and it generalizes to tools that do not exist yet.

A prediction task is one where many reasonable answers exist and you want a fluent, well-structured one: draft the RFI prose, rewrite this paragraph for an owner audience, outline the toolbox talk, turn my bullet points into a daily-report narrative, suggest how to phrase a delicate notice. The model is truly strong here because producing plausible, well-formed language is exactly what it does, and there is no single fact to get wrong. These are the tasks where you let it run and edit lightly.

A retrieval task is one where there is a specific correct answer that exists in a document or the world: what spec section governs this, what is the dimension on sheet A-503, what does this AIA clause say, what is the lead time on this switchgear, which code edition is adopted here. The model does not look these up; it predicts them, so it produces a plausible answer that may be wrong, and these are the tasks where the answer is a hypothesis to verify, never a fact to use. The danger zone is when a single request mixes both, like "draft the RFI and cite the governing section," because the prediction half comes back excellent and lends its credibility to the retrieval half that came back fabricated. Learn to see the two halves inside one request, accept the prediction half, and verify the retrieval half, and you have internalized the entire engine in a form you can apply at 4pm without thinking.

Why It Feels Like a Colleague, and Why That Is the Trap

There is a deeper reason the four mechanics keep catching smart people, and it is worth naming directly: the model talks like a competent colleague, and your brain is wired to extend trust to anything that talks like a competent colleague. When a seasoned project architect tells you "that egress section is 1006.2.1," you trust it, and that trust is well earned over years of them being right. The model produces the exact same sentence with the exact same confidence, and your trust machinery fires the same way, except the model earned none of it. It is mimicking the register of expertise without the substance, and the register is what your instinct reads.

This is not a character flaw in you; it is a design feature of the tool. The model was trained to produce fluent, confident, expert-sounding text because that is what people rated highly, so it is optimized to trigger exactly the trust response that the four mechanics make dangerous. The fluency and the unreliability are not in tension; they are produced by the same process. That is why "it sounded so sure" is the most common and most useless explanation for an AI error in construction. Of course it sounded sure. Sounding sure is the one thing it always does, whether it is right or fabricating.

The practical defense is to deliberately decouple your trust from the tone, and the way you do that is by building the verification into your workflow rather than your willpower. You will not, at 4pm under a pour deadline, summon the discipline to doubt a fluent answer; nobody does reliably. So you make the check structural. The citation gets looked up before the RFI goes out, every time, not because you suspected this particular one but because that is simply the step. The code edition gets confirmed against the adopted code, every time. The drawing reading gets a human pass, every time. When verification is a step in the process rather than a judgment call in the moment, the model's confident tone stops being a trap, because you are no longer relying on your in-the-moment skepticism to catch what the tone is designed to slip past. This is the single most important habit in the entire program, and it exists precisely because the engine is built to sound like the colleague you trust.

Key Takeaways

• An LLM does exactly one thing: it predicts the next chunk of text. Drafting prose is a prediction task it excels at; citing a real spec section or clause is a retrieval task it only imitates, which is why it fabricates facts fluently.
• Tokens are the pieces of text the model reads, and the context window is the workbench that holds all of them at once. It is large but finite, so an 1,847-page spec does not fit, and "summarize this whole spec" produces mush. Feed relevant sections or use a tool built to index the document.
• The training cutoff freezes the model's knowledge on one date. It will reach for the code edition it read most of (often an older IBC, ASHRAE, NEC, or AIA edition), not the one your AHJ enforces. Name the exact edition and verify the provision in the adopted code.
• Image upload does not mean the model sees your drawing. It predicts a plausible description, confusing section cuts with plans, miscounting revision clouds, misreading redlines, and guessing wall types when the legend is on another sheet.
• An AI description of a drawing is a hypothesis, never a finding. A human who can read the sheet confirms it against the legend, the revision history, and adjacent sheets before it is forwarded or acted on.
• The four mechanics combine: in one code-narrative request they produce a wrong code edition, a fabricated section, a dropped requirement from a long document, and a fake drawing reconciliation. Knowing the engine turns that output from a trap into a fast, verifiable first draft.