Give the agent an authoritative book on the subject as a wiki in the repo \u2014 indexed and cross-linked, not a one-off file drop into the chat. Then even a short prompt designs in the source\u2019s terms: queues, delivery guarantees, idempotency, fault tolerance. Below: the book-as-context method, a shop\u2192ERP walkthrough, and the method\u2019s limits.<\/p>\n
<\/p>\n
A familiar scene. Someone \u2014 a founder, a product lead, sometimes even an engineer outside their usual zone \u2014 opens Claude or Cursor and types something like: \u201cmove orders from the online shop into the ERP.\u201d The ask sounds reasonable: orders appear on the site; accounting needs them. They skip the details not out of laziness, but because they do not know which details matter. \u201cERP is sometimes down,\u201d \u201corders must not be lost,\u201d \u201cduplicates are bad,\u201d \u201cCRM should get them too\u201d \u2014 all of that lives as common sense, not as requirements.<\/p>\n
The agent answers with confidence. A minute later you have a design: dump orders to CSV on a cron, push the file over FTP, \u201csomething on the other side will pick it up.\u201d The chat says \u201cdone.\u201d From the outside it looks like a solution. Inside it is textbook minimum: a night batch, a share, manual cleanup when ERP did not answer, and a magical \u201cjust send again\u201d when something vanishes.<\/p>\n
From here the story splits.<\/p>\n
Branch one: an engineer who has already built these paths is close enough to help. They look at FTP and see the bill \u2014 six hours of ERP downtime, stock drift, who owns redelivery, where the audit trail is. They go back into the chat and raise the brief: async, a queue, idempotency, a state journal, channel security. After a dozen clarifications the agent draws an adult design. The moral of this branch is familiar: \u201cAI works if you already know how to ask.\u201d<\/p>\n
Branch two: that experience is not nearby. Or a seasoned colleague is around and smirks: \u201csure, chat-driven amateurs can ship a three-page site \u2014 never real architecture.\u201d For them CSV-over-FTP is not a method bug; it is proof the model \u201ccan\u2019t do architecture.\u201d They are right about one thing: an empty prompt does not yield industrial grade. They are wrong about another: the model is not \u201cdumb.\u201d<\/p>\n
The root is what the model was trained on. Open internet has orders of magnitude more tutorials about \u201cexport CSV and drop it on FTP\u201d than production write-ups with a broker, an outbox, and retry semantics. The average temperature of the sample is textbooks and Stack Overflow, not a write-up from a real corporate integration. Without a domain base the agent does not know that the sane answer here is event-driven: an order is not \u201ca file left\u201d; it is an event that survives ERP downtime, does not duplicate on retry, and leaves a trail you can use in an incident review.<\/p>\n
So the question is not whether AI \u201ccan do architecture.\u201d The question is where it takes its bar from when you cannot state that bar yourself. If the domain is yours \u2014 you are the bar, and a long dialogue saves you. If it is not \u2014 you need an external carrier of expertise for the design phase. Not one more paragraph in the prompt (\u201cmake it reliable and production-ready\u201d), but a substrate the agent must read as a tech lead\u2019s handbook.<\/p>\n
Book-as-context<\/strong> means giving the agent an authoritative primary source (a book, a spec) as a structured context substrate: a wiki of concepts, cross-links, and traceability back to book chunks. It lives in the project; the agent walks it like a tech lead\u2019s handbook \u2014 without hoping a single system-prompt line or raw PDF search will hold the architectural bar.<\/p>\n It is a concrete case of what people now call context engineering<\/strong>: the model works from a corpus assembled for the task, not from \u201cwhatever it remembers.\u201d Nearby names in the community are other packagings of the same idea. LLM Wiki<\/a> (Karpathy) \u2014 compile sources into linked markdown pages instead of pulling raw chunks from RAG on every ask. Book-to-skill<\/strong> (and \u201cturn a book into a Claude skill\u201d) \u2014 compress a book into a Claude Code \/ Copilot skill: For distributed systems, high load, and eventing I used Tanenbaum\u2019s Distributed Systems: Principles and Paradigms<\/em>. In that zone it plays the role Kotler plays for marketers: hard engineering, not a blog paraphrase.<\/p>\n The cutting pipeline is obsidian-llm-wiki<\/a> (olw, a fork in the LLM Wiki vein): a fast model for ingest (concepts from a chunk), a heavy model for compile (concept pages). On the Tanenbaum run: 30<\/strong> source chunks \u2192 116<\/strong> concept pages. A full run is about $1.5<\/strong> via OpenRouter. \u201cRun once and ship\u201d does not work: three runs produced 16 + 14 + 23 notes \u2014 chunk and model parameters need iteration.<\/p>\n The wiki sits in the repository (or a symlink). The agent does not load the whole book into the window: it walks the index and pulls the nodes it needs \u2014 via Cursor\u2019s built-in indexing or a hybrid-search MCP. From there, plans, API contracts, infrastructure, and vibe-coding lean on the book\u2019s concepts and methods. The bar holds from a single prompt: you do not have to append \u201cadd eventing, async, contracts, and fifty more requirements\u201d every time.<\/p>\n Same class of problem. Two outcomes.<\/p>\n Without a substrate:<\/strong><\/p>\n \u201cMove orders from the online shop into the ERP\u201d<\/p>\n<\/blockquote>\n \u2192 CSV, cron, FTP, \u201cdone.\u201d<\/p>\n With a Tanenbaum wiki<\/strong> \u2014 a real brief: 1C-Bitrix \u2192 ERP Galaktika \u2192 CRM Creatio<\/strong>. The agent does not rush straight into writing code, and it does not stop at a list of smart words. It walks the book\u2019s concept graph first \u2014 from a business risk to the author\u2019s term, from the term to a pattern:<\/p>\n Those formulations do not stop as a smart paragraph in the thread. They get worked through on two layers. In the brief<\/strong> \u2014 spec sections, SLOs, transport priority, partial-success rules, a \u201cwiki principle \u2192 section number\u201d map. In the implementation<\/strong> \u2014 the same decisions become concrete mechanisms: a transactional outbox next to the order, a persistent broker, ERP\/CRM adapters, idempotency keys on retries, a DLQ, an end-to-end state journal. Without a wiki the agent says \u201cqueue\u201d and draws FTP; with a wiki the book\u2019s queue has to survive into the design and into the code.<\/p>\nSKILL.md<\/code>, chapters, checklists the agent can load on demand. Delivery differs: a skill lives in the assistant\u2019s skills folder; book-as-context puts the wiki in the project repo<\/strong>, so plans, specs, and code share one substrate. The point is the same \u2014 the book becomes working context, not a one-shot chat summary.<\/p>\nOne prompt, two worlds<\/h2>\n
\n
\u201cERP may be down for hours; orders must not be lost\u201d\n \u2192 message-oriented middleware:\n persistent communication \u2014 the queue keeps the message until delivery\n vs transient \u2014 the receiver must accept now\n \u2192 message queue systems \u2014 guarantees, journal, balancing\n \u2192 AMQP: unsettled \u2192 settled \u2192 forgotten\n \u2192 two-phase commit \u2014 when two databases must update atomically<\/code><\/pre>\n