Eidos gives every AI coding agent one shared rulebook for a codebase

The problem Eidos is aimed at

As dev.to reported, the post starts from a pain familiar to teams using AI coding agents, which are programs that write and edit code on request. Different engineers pick different tools, and each tool reads its own instruction file. Keeping those files in sync by hand tends to fail.

The author lists three more issues. One giant instruction file wastes tokens (the chunks of text an AI model is billed for and limited by) once a project grows. Architecture Decision Records, the short documents that log why a design choice was made, drift away from the code. And an agent can pass every existing test while still breaking a design boundary nobody wrote a test for.

Specs that live next to the code

Eidos keeps specifications inside the project's own repository, the folder that holds the code and its history. Each spec is a readable document with a structured header that software can validate. The author's idea is that agents query the structured part, while engineers, architects and designers read the narrative and a web viewer.

The specs cover three layers: business concepts such as domains and personas, technical architecture such as containers, components and interface contracts, and design-system items such as UI components and screen states. Design decisions are recorded in place, inside the part of the system they affect, along with the reasoning and the alternatives that were rejected. That replaces a separate folder of decision records.

Larger changes that span several parts of the system can be written up as a planned transition, checked against the code, and marked applied once the change lands.

Handing agents only what they need

Before touching a file, an engineer or agent can ask Eidos for a context slice. The post describes three sizes: a short anchor, a guardrails view, and a deeper one. The answer includes the owning component, relevant contracts, recorded decisions and active rules for that file, rather than the whole rulebook.

Behind this is a local index built with a SQLite database, a code-structure map and optional offline semantic search. The post also describes commands for a compact outline of the repository, for finding where a symbol lives, and for checking what depends on a component before changing it. The claim is fewer blind file reads and lower token use on each agent turn. The post offers no measured savings.

Catching drift with tests

The most concrete safeguard is the drift check. A rule, called an invariant in Eidos, can be bound to a specific test function in languages including Python, TypeScript, Go, Rust, Java and Kotlin. The example in the post is a rule that knowledge-graph syncing must finish deterministically with no network calls.

Running the drift command then asks whether public code or contract files changed without a matching spec update, whether each bound test exists and refers to its rule, and whether the spec files are valid and their links resolve. A hook can run this automatically when an agent finishes a turn, so problems get fixed before the task is declared done.

Setup, limits and what is unproven

Eidos is a Python command-line program published on PyPI as eidos-ai. The post shows a short sequence: install it, initialize a repository, install the agent skills, then build the index and run validation and drift checks. It also generates a static web portal for browsing the architecture, and the project uses itself as its own example.

The author is candid about one limit. Adapters exist for eight agent tools, but the workflow has mainly been tested with Claude Code and Google Antigravity. Feedback from users of the others is invited. The post is also the author's own description, so claims about token savings and fewer violations have not been independently checked. Pricing is not stated.

The tool is also opinionated. It asks a team to adopt its spec format, its test-binding habit and its lifecycle states for changes. That is a real commitment, and it will suit teams with growing codebases more than weekend projects.