# Menugen Architecture Pattern The Menugen Architecture Pattern describes an application that is fully engulfed by a [[Large Language Models (LLMs)|Large Language Model]], with no classical procedural code in the core processing path. Input goes in (e.g., an image of a menu), the LLM does the work natively, output comes out (e.g., a generated image of dishes). Named after the Menugen example introduced by [[Andrej Karpathy]] when arguing that LLMs unlock genuinely new categories of software, not just faster versions of what existed before. ## Why It Matters Most LLM applications use the model as one component among many; classical code orchestrates retrieval, validation, formatting, business rules. The Menugen pattern inverts this. The LLM IS the application. There is no accompanying [[Software 2.0]] pipeline to maintain, no business logic layer, no rule engine. The model handles understanding, reasoning, and generation in a single shot. This is only possible when: 1. The task can be expressed as a clean input/output contract that maps to the LLM's native capabilities (text in/out, image in/out, multimodal). 2. Reliability requirements tolerate the model's output distribution (no hard correctness guarantees needed). 3. The cost per call is acceptable for the use case. ## Implications - **Fewer engineering primitives**: no ETL, no schema design, no integration layer for the core path. - **Different debugging**: failures are prompt failures or model capability failures, not stack traces. - **Different upgrade path**: the application improves automatically when the underlying model improves; no code changes required. - **Different moat**: defensibility shifts from algorithmic IP to prompt engineering, data, distribution, and UX. ## Contrast With - **Classical [[Software 1.0]]**: explicit instructions written by humans. - **[[Software 2.0]]**: weights learned by gradient descent, deployed inside larger systems. - **[[Software 3.0]]** (the Karpathy framing): LLMs as the runtime, prompts as the program. ## Risks - The pattern bleeds value when the underlying model is generic; users get the same output any competitor's wrapper would produce. - It's brittle to model deprecation; if the API changes or the model is retired, the entire app breaks. - It can be lazy design; sometimes wrapping an LLM hides the absence of a real problem worth solving. ## Related - [[Andrej Karpathy]] - [[Large Language Models (LLMs)]] - [[Markdown-based Installation (MD Scripts)]] - [[LLM Knowledge Bases Over Unstructured Data]] - [[AI Verifiability as a Capability Ceiling]] - [[Agent-Native Product Decomposition]] - [[Prompt-driven development (PDD)]] - [[AI Inference]] - [[Vibe Coding]]