## Sources

1. [Context as Code](https://www.oreilly.com/radar/context-as-code/)

---

### **Context as Code** – **Artur Huk**

#### **Main Arguments**
*   **The Rise of "Frankenstein Factories":** Modern AI generation engines have become "industrialized" factories capable of producing functional syntax at immense speed, but they often result in **architecturally ungovernable systems** [1]. This rapid production leads to "comprehension debt," where the volume of code exceeds the human capacity to read, understand, or govern it [1, 2].
*   **The "Yes-Man" Problem of AI:** Standard coding agents prioritize fulfilling immediate user intent over defending system architecture [2]. Without explicit constraints, an agent will take the path of least resistance to satisfy a request (e.g., a Jira ticket), often violating **bounded contexts** or introducing insecure dependencies just to make the code "work" [2, 3].
*   **Shifting Risk from Build Time to Runtime:** Historically, compilers and static tools provided deterministic "hard boundaries" for code [4]. The current shift to agentic AI has "softened" these boundaries by blurring the line between data and instructions within the inference context, moving structural risk from the safe build phase into the unpredictable runtime phase [5, 6].
*   **The Need for Automated Refusal:** To regain control, the industry must move beyond "prompt engineering" and toward **build-time governance** [7]. Instead of just automating the word "YES" for feature requests, organizations must automate the word "NO" by establishing mechanical constraints that reject structurally invalid code before it is ever merged [8, 9].

#### **Key Takeaways**
*   **The Context Compilation Pattern:** This is a proposed staged pipeline that governs code generation in the IDE and CI/CD pipeline before a human reviewer ever sees it [7]. It relies on two layers: **structured context injection** (to bias generation) and **post-generation static verification** (to enforce rules) [7].
*   **Deterministic Over Probabilistic Enforcement:** Engineering teams should not rely on an LLM to review its own work or follow "soft" instructions in Markdown alone [10, 11]. Instead, they must use **deterministic tools** (like Semgrep, Bandit, or CodeQL) to verify that generated code adheres to explicitly declared structural invariants [11, 12].
*   **From Abstraction to Clarity:** While traditional development favored heavy abstraction to save developer time, AI agents require **tailor-made architecture** with explicit domain logic and visible contracts [13, 14]. Agents struggle to reason about "black box" frameworks; therefore, system value now lies in how clearly its boundaries are declared [14, 15].
*   **Economic Justification:** Context as Code is not necessary for all projects. It is most valuable for **high-stakes, regulated systems** (e.g., banking, healthcare) where the cost of architectural failure or liability far outweighs the upfront cost of designing explicit governance artifacts [16, 17].

#### **Important Details and Structural Components**
*   **The Context Pipeline (6 Steps):**
    1.  **Context Artifacts:** Versioned files like `intent.md` (what to build), `boundaries.md` (structural invariants), and `threat-model.md` (adversarial constraints) [18, 19].
    2.  **Context Compiler:** A script or protocol that assembles these artifacts into a prioritized structure for the LLM prompt [20, 21].
    3.  **Strict Boundary Hierarchy:** A deterministic precedence where **Threat Models > Boundaries > Coding Standards > Intent** [22]. Security and architecture must always overrule feature delivery [22].
    4.  **Generation:** The agent synthesizes code within an isolated sandbox based on the precompiled prompt [23].
    5.  **Adversarial Verification:** Deterministic CI rules (like `semgrep-rule.yml`) check the "negative space" to ensure the code didn't cross forbidden security or architectural boundaries [12, 24].
    6.  **Acceptance Verification:** Checking the "positive space" via machine-executable contracts (e.g., Gherkin) to ensure the code actually solves the business problem [25, 26].
*   **Redefined Engineering Roles:**
    *   **Intent Definer (formerly Business Analyst):** Owns `intent.md` and `acceptance-criteria.md`, ensuring requirements are strict enough for automated proof of delivery [27, 28].
    *   **World Builder (formerly Software Architect):** Owns `boundaries.md`, defining the domain ontology and allowed interaction patterns [27, 28].
    *   **Adversarial Context Provider (formerly QA/Security):** Owns `threat-model.md`, identifying the abuse paths that the CI must block [27, 28].
    *   **Governance Platform Engineer (formerly DevOps):** Builds the enforcement machinery and translates Markdown constraints into nonbypassable CI gates [27, 28].
    *   **Context Orchestrator (formerly Developer):** Manages generation workflows, resolves artifact conflicts, and implements critical handwritten paths [27, 28].
*   **The Goal of Engineering:** The highest-value skill in the age of AI is no longer writing syntax, but **engineering the conditions**—the declarative boundaries—under which correct syntax can emerge [9].