{"slug": "llm-assembly-line", "title": "llm-assembly-line", "summary": "A developer has published a pattern for running long, raw, dictated work orders through AI coding agents, called 'llm-assembly-line'. The method involves cutting a brief into work packages, each passing through a build station and two independent inspection stations, with a rework loop that only ends on passed inspection. The pattern builds on Andrej Karpathy's LLM Wiki pattern for persistent context and is designed to let agents work autonomously on entire batches of feedback and change requests.", "body_md": "A pattern for running long, raw, dictated work orders through AI coding agents.\n\nOne brief goes in. It gets cut into work packages. Each package passes a build station and two independent inspection stations. Nothing leaves the line uninspected.\n\n```\n  BRIEF ──► [cut] ──► [build] ──► [inspect] ──┐\n                         ▲                    │\n                         └────── rework ◄─────┘\n                                              │\n                                         ──► REPORT\n```\n\nMost people hand an agent one wish at a time. That works, and it wastes the thing agents are actually good at. The alternative is to hand over a whole batch at once: everything you noticed this week, dictated raw, one point after another, three hundred lines if that is what it takes.\n\nDo that and the brief stops being the hard part. The hard part becomes the instruction for\n**how** the batch gets worked. That instruction is what follows: cut into work packages, one\nbuilder per package, independent inspectors that try to break the work, a rework loop that only\never ends on a passed inspection, decisions made on the agent's own authority instead of\nquestions back to you, and a final report you can check line by line without having to remember\nwhat you ordered in the first place.\n\nI use this on every sizeable brief and it has held up. Take it, change it, make it yours.\n\nThe line itself is my working method. Its foundation is not.\n\nFor an agent to work a three-hundred-line brief reliably, it needs context that is not\nreassembled from scratch in every session. The structure that provides it is **Andrej\nKarpathy's LLM Wiki pattern**:\n\n[https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)\n\nThat idea is his, not mine. In short: instead of re-deriving knowledge from raw documents on every question (RAG), the agent builds and maintains a persistent, interlinked markdown wiki in three layers — immutable raw sources, the wiki the agent writes, and a schema the two of you evolve together. Knowledge gets compiled once and then kept current. Read his gist first if you want to understand the foundation. What you have here is the floor built on top of it.\n\n**An agent harness with subagents.** Claude Code, Codex, Pi or equivalent. Without separate independent contexts the inspection collapses, because the same agent reviews its own work and predictably finds it good.**Recommended: a maintained wiki structure in the project**, per the pattern above. The line runs without one, but then the agent works from whatever it can scrape together in the moment instead of from what the project knows about itself. Step 7 of the line is the other half of that deal: it feeds what each brief taught back into that structure.\n\n- Dictate or write your entire brief in\n**one** message. Feedback, change requests and new features, one point after another, raw and long. Give too much context rather than too little, and do not polish it. - Append the prompt below to that message. Or drop it into the project once as a file (say\n`llm-assembly-line.md`\n\n) and end your brief with:*Work this order per*`llm-assembly-line.md`\n\n. - Everything from\n**The order above is a long, raw, dictated brief** onward is addressed to the agent, not to you.\n\nOne warning about step 5 of the line: it decides ambiguities on its own instead of asking you. That is the point of the thing, and it means you have to actually read the final report. The decisions are listed there, and that is where you overturn them.\n\nEverything inside the block is the prompt. Copy the whole block, without the explanation around it.\n\n```\nThe order above is a long, raw, dictated brief: feedback, change requests and new features,\nlisted one after another but written in one pass. Work through it completely and on your own\nauthority, following this line.\n\nTwo properties separate this from ordinary work:\n\n1. **It runs start to finish without stopping.** Questions back to the user are the exception,\n   not the route.\n2. **Nothing counts as done until an independent check passes.** Not even a fix.\n\n## 1. Cut the brief into work packages\n\nRead the whole brief before you cut the first package. Every self-contained point — one piece of\nfeedback, one change request, one feature — becomes **one work package** with a running number\n(WP1, WP2, …), the wording or a close paraphrase from the brief, and the files it touches.\nNothing is silently merged or dropped. A point that turns out to be moot stays a package and is\nexplained as such in the report.\n\nWrite the package list into a ledger file (`ASSEMBLY-LINE-<date-or-round>.md`, wherever the\nproject keeps its documents). The ledger, not the chat, is where status, inspection findings and\ndecisions live, package by package.\n\n## 2. Cut waves by file conflict, not by importance\n\nPackages that touch the same files **never** run at the same time. Cut the packages into waves\nso that inside one wave no two packages share a file. Concurrent agents in one file overwrite\neach other's intermediate state.\n\n## 3. Staff the line\n\nSet up a workflow (the harness's workflow tool if it has one; otherwise individual subagents;\notherwise sequential work in the main context — in that order). Per work package:\n\n1. **One builder agent** implements the package. It gets the wording of that one point, the\n   files it touches and the project's conventions — not the whole brief.\n2. **One independent inspector for code quality** checks the result adversarially: correctness,\n   tests (run the existing ones, add the missing ones), edge cases, conventions. Independent\n   means its own context, no access to the builder's reasoning, and a mandate to refute rather\n   than to confirm.\n3. **One independent inspector for UI and UX** checks every package that touches an interface:\n   usability, states (empty, loading, error), labels, consistency with what is already there. A\n   package with no interface surface records that in the ledger instead of skipping the\n   inspection silently.\n\n## 4. The rework loop always ends on a passed inspection\n\nIf an inspection finds a defect, a new build run starts for that package, and the inspection\nthen runs **again**. The loop never ends on a fix: **the last step of every package is always a\npassed inspection.** A change nobody has checked is not a finished package, it is an open one.\nIf a defect is handed over to a different package, it counts as fixed only once the inspection\npasses **there**.\n\nAfter three unsuccessful runs, stop turning the package. Record the state, the findings and the\nremaining gap in the ledger, and mark the package as partially done in the final report.\n\n## 5. Blockers: decide, do not ask\n\nWhatever used to trigger a question — an ambiguity in the dictation, two possible routes, a\nmissing detail — you decide yourself. Pick the option that comes closest to the visible intent\nof the brief and is easiest to reverse, and **record the decision, the reason and the rejected\nalternative in the ledger**. The user reads the decisions in the final report and can overturn\nthem there.\n\nThree things stay exempt and justify a stop: destructive, hard-to-reverse actions (deleting,\nforce-pushing, changing permissions); leaving the project you work in (foreign directories,\nforeign repositories, foreign systems); and bypassing a permission prompt. The last one is never\nallowed, not even to take a measurement.\n\n## 6. Whole-system check\n\nWhen all packages are through, check how they fit together. Run the project's full test suite\nand type check. Look for interactions between packages, because two packages can pass alone and\ncontradict each other together. Then read the brief once more from the top against the package\nlist: is every point really assigned to a package, and is every package either finished or\nhonestly marked open?\n\n## 7. Document, ingest, synthesize\n\nIf the project keeps an LLM wiki or a comparable maintained knowledge base, its schema applies:\nupdate the pages that changed, file durable insight as a synthesis, update the index and the\nlog, put open questions on the agenda. If the project keeps none, the yield belongs in whatever\ndocumentation structure it has. The brief itself is a raw source: if there is a place for\noriginal documents, put its wording there before it sinks into the chat history.\n\n## 8. Final report — easy to digest, still complete\n\nThe report follows Simplified Technical English (ASD-STE100), applied to the language of the\nbrief: short sentences, one statement per sentence, active voice, one term per thing, no filler.\nThe user must not have to remember anything, so the report lists **every** package, including\nthe ones that went smoothly:\n\n| Per package | Content |\n|---|---|\n| Order | What was asked for, in one sentence, close to the wording of the brief |\n| Result | What was built and where it lives (files, pages) |\n| Inspection | What the inspectors found and how it ended |\n| Your check | How the user verifies the result, in one or two steps |\n\nAfter the table, collected: the decisions you made on your own with their reasons, the open or\npartially done points, and the state of the check chain (tests, type check, build) with numbers.\n\n## Hard rules of this line\n\n1. No package is reported done without a passed final inspection.\n2. No two concurrent agents in the same file.\n3. No permission prompt is bypassed. Whatever comes out of that does not count.\n4. Every independent decision is recorded. None is left out.\n5. The final report names all packages, not only the notable ones.\n```\n\nUse it, change it, rebuild it. :)", "url": "https://wpnews.pro/news/llm-assembly-line", "canonical_source": "https://gist.github.com/claes-work/407ba30f4d67fbc7fba7e11dd4b15e13", "published_at": "2026-08-20 10:56:54+00:00", "updated_at": "2026-08-20 18:43:56.194980+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models", "mlops"], "entities": ["Andrej Karpathy", "Claude Code", "Codex", "Pi"], "alternates": {"html": "https://wpnews.pro/news/llm-assembly-line", "markdown": "https://wpnews.pro/news/llm-assembly-line.md", "text": "https://wpnews.pro/news/llm-assembly-line.txt", "jsonld": "https://wpnews.pro/news/llm-assembly-line.jsonld"}}