Most descriptions of AI-native software development still reduce to two steps: idea, then prompt, then code. That collapses a layer of thinking that matters, the layer where a person's intent gets worked out in enough detail that it can be executed reliably by something other than the person who had it.
This paper proposes a five-stage workflow, Idea → Conversation → Documentation → Knowledge Compilation → Creation, in which documentation is not the byproduct of building software but an intermediate representation of it: a structured, durable artifact that sits between human reasoning and AI execution, and that gets compiled, not just read.
Monowire, a continuity layer for AI-assisted work discussed elsewhere in this Research section (a Samiel product), is one implementation of this idea. It is not the point of this paper. The point is the workflow itself, checked against what the field has already built.
01The missing layer
Two shorthand descriptions dominate how people talk about building software with AI today: Idea → Prompt → Code, and its slightly more disciplined cousin, Idea → Requirements → Code. Both treat the prompt, or a short requirements note, as the entire interface between what a person wants and what gets built.
That interface is thin. A prompt captures intent at one moment, compressed to fit inside a context window, and mostly discarded once the code exists. It rarely survives the next session, the next contributor, or the next six months.
The claim of this paper is narrow: there is a cognitive layer that today lives briefly inside a chat window and then evaporates, and that layer deserves to be treated as a durable, structured artifact, because it is the thing future agents and future humans actually need to pick the work back up correctly.
02The proposed pipeline
The workflow has five stages. An idea starts as loosely as it always has. A conversation works that idea into shape. That conversation is captured as documentation, organized by domain. Once enough of that documentation exists and holds together, a distinct compilation step reads across all of it and produces deterministic, execution-ready artifacts. Only then does creation happen, driven by those compiled artifacts rather than by the original conversation.
The compilation step is the part that actually does work. In the implementation this paper draws on, a single role, referred to internally as Coach, performs it: it reads the accumulated documentation across every domain and produces deterministic, department-scoped skill files that downstream builder agents execute against. Its job is synthesis, not authorship.
03The compiler analogy
The analogy to a traditional compiler pipeline is direct enough to be useful, and precise enough to be worth stating carefully.
The analogy is not original to this paper, section four covers that directly. What this paper adds is specificity about what plays the role of the front end, the IR, and the back end in an organizational rather than a single-file context, and an argument that the IR should be long-lived organizational memory rather than a spec authored once per feature and discarded.
04Related work
None of the individual pieces of this workflow are new. What follows is a direct accounting of the closest prior work.
Multi-agent frameworks that encode process as documents
MetaGPT (Hong et al., 2023) is the closest and earliest prior art. It assigns software-engineering roles to distinct LLM agents and encodes Standardized Operating Procedures into their prompts, requiring each role to produce structured intermediate artifacts before code is generated. ChatDev (Qian et al., 2023) takes a similar premise, structured as a "chat chain" rather than SOPs.
Agile-flavored planning agents
BMAD-METHOD runs an agentic planning phase that produces PRDs and architecture documents as versioned, living artifacts, then a distinct "sharding" step breaks those documents into focused, execution-ready story files. That shard step is functionally close to the knowledge-compilation stage proposed here.
Spec-driven development
By 2026, a "spec-driven development" movement, GitHub's Spec Kit, AWS's Kiro, OpenSpec, Tessl, treats a written specification as the source of truth, with implementation generated from and validated against it. This is the same core inversion this paper argues for.
The compiler and IR analogy, stated explicitly elsewhere
The comparison between agent planning artifacts and compiler intermediate representations has already been drawn explicitly and independently of this paper. Commentary on emerging "deterministic agent runtimes" in mid-2026 describes agents as functioning like a compiler front end. Separately, an open-source project offers a language-agnostic textual intermediate representation specifically designed for LLM agents to target instead of generating code directly.
Anthropic's reusable skill format
The specific compilation target this paper's implementation uses is Anthropic's Agent Skills, a folder-based, filesystem-native format with staged, on-demand loading. That framing, reusable organizational knowledge as a discrete, loadable artifact, is close to how this paper treats compiled department skill files.
Formal process and governance specification
A 2026 formal-methods paper proposes a domain-specific protocol language for specifying human-agent responsibility boundaries, explicitly critiquing MetaGPT and similar frameworks for encoding process only inside agent prompts, which drift. That critique applies with equal force to this proposal.
05How it compares
Laid out side by side, the honest picture is one of convergent evolution, not one lineage with a single missing piece.
| Approach | Unit of work | Compilation target | Status |
|---|---|---|---|
| MetaGPT (2023) | Single feature / task | Code, via structured role prompts | Established |
| BMAD-METHOD | Feature or epic | Sharded story files → code | Established |
| Spec-Driven Dev. (Kiro, Spec Kit) | Feature | Code + generated tests | Established |
| Anthropic Agent Skills | Reusable capability | N/A skills are the target | Established |
| This proposal | The organization, continuously | Skill files, not code directly | Partial synthesis |
Two differences hold up under that comparison. First, the unit of work: existing frameworks scope documentation to a feature that is largely retired once it ships; this proposal scopes it to the organization as a standing structure. Second, the compilation target: rather than compiling into code or tests directly, this proposal compiles into a reusable-capability format that downstream agents load on demand.
06A field that moved fast
Worth seeing plainly: almost every element of this proposal was independently arrived at by others within a roughly three-year window.
The general paradigm is not novel. A narrower synthesis is.
Treating structured documentation as the real interface between human intent and AI execution, and compiling it into something downstream agents run against, is well-established by 2026, visible independently in MetaGPT's SOPs, BMAD's shard step, and the spec-driven-development ecosystem. The compiler/IR framing has also already been stated explicitly elsewhere.
What is not already established is the combination of (1) scoping the source documentation to a persistent, department-organized organization rather than a per-feature spec, and (2) compiling that memory specifically into a reusable agent-skill format rather than into code, tests, or a task DAG. That combination is a legitimate, modest contribution: a specific point in an existing design space, not a new paradigm.
07Limitations
- No formal enforcement layer. Encoding process expectations only in prompts is subject to drift; nothing here guarantees compilation behaves deterministically without a separate checking mechanism.
- Compilation quality is unproven at scale. A synthesis step reading an entire organizational knowledge base and producing correct, non-contradictory skill files is harder than it sounds.
- The org-scoped framing is the weakest-evidenced claim. It's argued here on structural grounds, not demonstrated empirically.
The compiler analogy is correct. It just isn't new, and neither is most of the pipeline it describes. What's left after checking is smaller, and more honest, than the pitch.
08References
- Hong, S. et al. "MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework." arXiv:2308.00352, 2023.Standardized Operating Procedures encoded into role-based agent prompts; the closest and earliest prior art to this paper's pipeline.
- Prifti, Y. "Specifying AI-SDLC Processes: A Protocol Language for Human-Agent Boundaries." arXiv:2606.20615, 2026.Formal critique of prompt-encoded process as subject to drift; motivates this paper's limitations section.
- BMAD-METHOD: Breakthrough Method for Agile AI-Driven Development. GitHub, bmad-code-org.Agentic planning + document-sharding pipeline; the closest analog to the proposed knowledge-compilation step.
- GitHub Spec Kit open-source spec-driven development toolkit.Specification treated as source of truth; part of the broader spec-driven development movement.
- Anthropic. "Agent Skills" Claude Platform Docs.The reusable, filesystem-native compilation-target format referenced throughout this paper.
- "Spec: A language-agnostic Intermediate Representation for autonomous agent-driven software development." GitHub, mronus.Independent project drawing the same compiler/IR analogy explicitly.
- "Agentic AI in the Software Development Lifecycle." arXiv:2604.26275, 2026.Survey covering MetaGPT, ChatDev, AgileCoder, and the broader agentic-SWE literature.
—How to cite this work
https://hamdibouzidi.com/research-documentation-as-ir.html