Aden: I built a "context compiler" because the bottleneck in AI coding isn't intelligence — it's context

# Aden: I built a "context compiler" because the bottleneck in AI coding isn't intelligence — it's context **Upfront, so there's no surprise in the comments:** I'm not a developer. My background is IT, so I understand systems, architecture, and how the pieces fit — but I built Aden *with* AI doing the heavy lifting on the actual code. I'm sharing it as someone who had a problem worth solving and used the tools available to chase it down, not as a Rust expert. Roast the idea, the design, and the code — that's exactly the feedback I'm here for. The bottleneck in AI-assisted development isn't model intelligence. It's **context**. Drop a capable LLM into a 100k-line codebase and it hits the same wall a human does: information overload. It doesn't know which 10 of 500 files matter. It doesn't know that changing `Database::connect()` will break `QueueWorker::drain()`. It has no map of the system. **Aden** is my attempt to fix that — a *referential context compiler*. It takes source code, docs, notes, and plans (any language) and compiles them into a **traversable knowledge graph** where every node is an AsciiDoc document connected by *typed* edges. ## What it is — and isn't - **Not a doc generator** (Rustdoc/Javadoc make HTML to *read*). Aden makes machine-navigable context to *reason over*. - **Not a static analyzer** (clippy/Semgrep find bugs in control flow). Aden finds *semantic relationships* between concepts and keeps them in sync as code changes. - **Not an IDE replacement.** It's a substrate your IDE, your agent, or your CI pipeline can *query*. ## Why a graph? Code isn't linear — it's a network. Modules `use` each other, functions `call` each other, ADRs `constrain` design choices, tests `verify` behavior. A directory tree can't express that. A graph can. So you can ask questions `grep` can't: - What depends on this function? - What's the **blast radius** of changing this module? - Which contracts are stale relative to the source? - What's the *minimum* context an agent needs to safely touch this file? ## Why token density? Every token an LLM reads costs money and dilutes signal. A 500-comment doc can burn 8,000 tokens of noise. Aden's assembly step does a **budgeted graph traversal**: start from any anchor, walk the edges, and assemble a prompt that fits a token budget while keeping the *most structurally critical* context. Surgical selection, not dumping the whole repo into the window. ## Why AsciiDoc as the native format? It's the rare format that's *both* human-readable and fully scriptable: - A senior engineer can open any `.adoc` and get it with zero tooling. - Anchors (`[[name]]`) and cross-refs (`<<name>>`) map directly to graph nodes/edges — referential by default. - It diffs cleanly in Git, so contract changes get reviewed in PRs like code. - `aden gen` regenerates contracts deterministically from source; `aden check` validates every reference as a CI gate. ## The part I care about most: docs that stay alive Documentation rots. A signature changes, the `.md` describing it doesn't, and six months later someone designs the wrong thing off stale docs. Aden's `heal` engine continuously detects **drift** between code and its contracts — when source changes, it flags the stale contract and proposes a patch. Documentation becomes a living, version-controlled artifact that's *tested at CI time*, like a unit test. Same mechanism powers refactoring safety (`aden query --backlinks` shows everything that references a module *before* you change it) and compliance (policies are nodes with `constrains` edges to the functions they govern — auditable continuously instead of annually). ## Built agent-first An autonomous agent doesn't need pretty HTML. It needs five things, and Aden provides all five: An accurate map of relationships (the **graph**) A way to know when the map is stale (`heal`) A way to assemble *just enough* context for a task (`asm`) A way to verify its work before committing (`check`) A way to leave breadcrumbs about what changed (`session`) When a human reviews an agent's PR, they don't read its "thoughts" — they read the contracts, run `aden check`, and confirm the session log explains what changed and why. ## The thesis The name *is* the mission: **A Dense Referential Context Compiler.** Every token is load-bearing, every edge is typed, every anchor resolves. It's a bet on a future where software is built by **hybrid teams** of humans and agents — and in that future, context is the scarcest resource. Aden makes it explicit, dense, traversable, and self-healing: an opaque codebase turned into a navigable knowledge graph both humans and machines can reason about. ## Links - **Repo:** https://github.com/RioPlay/aden - License: AGPL-3.0 --- *Would genuinely love feedback — especially from people building agent tooling. What context problems are you hitting, and does a typed graph + token-budgeted assembly resonate, or am I overcomplicating it?*