🤖The AI Pre-Build Packet (A novel approach to token reduction)

 

🤖The AI Pre-Build Packet

(20260719.PreBuildPacketDesignPattern)

Compiling the reasoning that precedes code

A design pattern for cutting the cost of LLM-assisted programming Akien MacIain 2026-07-19

General (clean-room) case, reconstructed from first principles and from observing how coding assistants behave, not from any proprietary implementation.

---

The problem: We pay for the same thinking every time

An LLM coding assistant does a surprising amount of work before it writes any code. Given a task in a real codebase, it orients itself, works out the constraints, reads the surrounding files, breaks the task apart, decides what it already knows versus what it has to figure out, forms an approach, checks that approach — and only then writes.

Almost none of that preparatory reasoning is saved. The next task in the same codebase re-does most of it. Change one requirement on a task you finished yesterday and the assistant reconstructs the whole preamble from scratch. In a token-metered, latency-bound tool, you are buying the same thinking over and over.

This pattern captures that thinking once, so we stop paying for it.

The observation: the preamble is a fixed sequence

Ask a capable coding assistant what it does before writing code and you get a recognizable sequence of passes:

1. Orient — parse the request; ground it in what's actually being asked; place it in its domain.

2. Constrain — establish the bounds: what's required, what's forbidden, what shape the answer must take.

3. Survey — look at what already exists (files, patterns, prior art in the codebase) before touching the problem. Easy to skip; expensive when skipped.

4. Decompose — break the task into its constituent sub-problems.

5. Triage — sort those sub-problems into already-known / answerable versus genuinely novel.

6. Hypothesize — for the genuinely novel parts, form a candidate approach.

7. Validate — test that approach against the constraints from step 2 before committing. On a failure, drop back — to step 6 for a local miss, or up to the design for a structural one.

8. Build — only now is code written. (Building often reveals hidden sub-problems, which re-enter at step 4 — so this is a loop, not a line.)

The sequence is stable across tasks. That stability is the opening.

The insight: most of the preamble is deterministic

Here is the pattern's whole premise. Most of those passes do not actually require a language model. They are lookup, parsing, and rule-checking wearing the costume of reasoning:

• Orient and Survey are, in large part, retrieval — find the relevant files, the matching patterns, the symbols and call sites, the domain vocabulary. A symbol index and a pattern matcher answer most of it with no model at all.

• Constrain is largely rule application — the project's conventions, the type signatures, the forbidden dependencies, the required shape of the output. These are knowable without inference.

• Decompose and Triage are partly structural — the task's parts often fall out of the interfaces it touches, and "have we solved this before?" is a cache lookup against prior work.

What Claude thinks is irreducibly novel is Hypothesize... The candidate approach to the parts nothing has solved yet — plus the code in Build. That is the part is currently worth a model. The rest is preamble the model re-derives only because nobody handed it the answers.

The pattern: pre-answer, then hand over a packet

Run the deterministic passes in ordinary code. Assemble their outputs into a single structured brief — a build packet — and hand the model that packet instead of a bare request. The packet arrives with the questions already answered:

BUILD PACKET
  intent            — the task, grounded and disambiguated       (Orient)
  constraints       — required / forbidden / output shape        (Constrain)
  context           — the exact files, symbols, patterns to use   (Survey)
  sub-problems      — the task broken down                        (Decompose)
  known vs. novel   — which parts are retrieval, which need work  (Triage)
  success criteria  — how the result will be checked             (from Constrain)

The model no longer spends inference orienting, reading around, or re-establishing the rules. It spends inference where inference is actually required: forming and writing the solution to the genuinely novel parts. In independent testing on general programming tasks, moving the preamble into deterministic code and handing over a pre-answered packet cut the tokens on a build by roughly 89% — before any token caching.

The crux: triage is the starvation gate

Of all the passes, Triage is where the economics — and the risk — concentrate. It is the pass that decides which sub-problems get the expensive model and which are served from what's already known. Get it right and the model is starved down to only the novel core, which is the whole point. Two cautions:

• Don't fold Triage into Decompose. Decompose takes the problem apart; Triage sorts the parts by novelty. They are different jobs, and collapsing them loses the gate where the savings are decided.

• Triage is the pass most likely to be wrong. Misclassify a genuinely novel sub-problem as "known" and you hand the model a confident, pre-answered packet that quietly points it at the wrong solution. The failure is invisible until the build is wrong.

The staircase: migrate one pass at a time, on evidence

You do not compile the whole preamble at once. Each pass migrates from "the model does it" to "code does it" as you understand it well enough to make the deterministic version provably as good — starting with the cheapest and most mechanical (Orient, Survey, Constrain), leaving the model in place for whatever hasn't been compiled yet. The model is the fallback for the uncompiled remainder, so the system is useful at every step and gets cheaper as it climbs.

The discipline that keeps this honest: migrate a pass only when its deterministic version passes a check a hollow one couldn't. Compiling a pass before you actually understand it is how you get Triage wrong.

Failure modes to design against

• Over-compiling. A deterministic pass that passes its own tests but produces builds that answer the wrong question means a pass was compiled past its real understanding — usually Triage or Validate. Guard it with an end-to-end check on the build's output, not just the pass's output.

• Seam drift. Each pass hands a typed artifact to the next. That seam is where memoization lives — and where the original intent can quietly deform. The final check should trace back to the original request, not merely to the previous seam.

• Silent truncation. If the packet caps context (top-N files, sampled call sites), say so in the packet. A dropped-but-relevant file reads downstream as "considered and excluded" when it was never seen.

Why it generalizes

This is one instance of a general move: inference compilation — turning an answer you'd otherwise re-derive into reusable structure, so you pay for it once. The pre-build preamble is simply the densest, most-repeated reasoning in the build loop, which makes it the highest-yield place to start. The same pattern applies to any repeated LLM workflow with a stable preamble: identify the passes, separate the deterministic majority from the irreducibly novel core, pre-answer the former in code, and spend the model only on the latter.

The prize is not only the token savings. A preamble run in deterministic code is inspectable — each pass emits an artifact you can read — so a wrong orientation is caught before it becomes a confidently wrong build. Compiled inference is cheaper and more legible than inference re-run in the dark.