Aelyx

The problem

AI coding tools forget. Every session starts from nothing, rereads the same files and rebuilds the same approximate mental model of a repository it has already seen many times. On a large codebase that is slow, expensive and unreliable.

The system

Aelyx is a Rust service that keeps a durable, Git-aware model of a project: how it is structured, how the parts depend on each other, and what has changed since it last looked. That knowledge is exposed to AI tools over MCP, so an assistant asks the project questions instead of inferring answers from a handful of file reads.

My role

I own it end to end: architecture, the Rust implementation, the MCP surface, and the judgement calls about what is actually worth remembering.

The hard part

Keeping the model correct while the repository keeps moving. Code changes constantly, and a stale answer about architecture is worse than no answer, because it is confidently wrong and gets acted on.

Architecture decisions

1. The parser records that a call happens; it does not record what the call reaches. Where syntax cannot prove the target there is no field to hold one — no target_symbol, no resolved, no callee_id. An optional field for an answer you do not have is an invitation: the first consumer who wants a graph fills it with inference, and everything downstream reads it as fact. That price is real — Aelyx builds no call graph.
2. There is no confidence score on the public surface, and a test fails if one appears. I could not defend a single cheap number that would honestly summarise certainty across evidence that is only ever partial, and every cheap way of producing one fabricates it. What that costs consumers is the convenience of sorting by one column.
3. Listing the workspaces and repositories on a machine would have been easy to expose over MCP, and it is deliberately absent. Enumerating somebody's local projects is metadata disclosure that no agent had demonstrated it needed. A caller arrives holding a path and resolves that, instead of asking what else is on the machine.
4. A rule that forbids a dependency and a rule that requires one are not checked alike. One observed dependency breaks a prohibition outright, whatever the coverage. Proving a requirement unmet means proving nothing was there, which only holds if everything that could have held it was read. So under partial coverage the answer is “no violation observed” — deliberately not the same sentence as “satisfied”.

Where it stands

Used inside Red Sentra and under continuous development, and narrower than that use suggests. It runs for one operator on one machine, has been validated against a single Rust repository, and its behaviour on mixed-language projects is untested. There is no hosted endpoint and no release. The repository stays private.