building-blocks

This repository is a document, not a piece of software. It describes a collection of open-source tools built around the Elixir and Erlang ecosystem, all aimed at solving a specific problem with AI-generated code: AI can write a frontend, a backend, a database schema, and a design, but nothing checks whether all those pieces agree with each other.

The core argument is that modern software is split by invisible boundaries: design lives in one tool, code in another, the browser runtime in a third, the server somewhere else. When any piece breaks, the error message has no way to point back to its actual cause because the tools cannot see across those walls. The project calls this the verification gap, and its thesis is that the answer is not smarter AI models but a better environment that pushes back when something is wrong.

To close that gap, the project ships or links to a set of tools, each addressing one boundary. There is a design editor that stores designs as structured data so they can be compared to code, a session recorder that replays what a user actually did, a dependency analyzer that traces why a piece of code runs, a toolchain that runs inside the application itself rather than as a separate build step, a JavaScript runtime inside the Erlang virtual machine, and linters that specifically flag patterns common in AI-generated code. All of these are already released as open-source packages under the Elixir Vibe and Elixir Volt organizations on GitHub.

The repository itself is a living standard in the style of web specifications: no version numbers, no release dates, continuously corrected, with the commit history as the changelog. Each layer gets its own page explaining what problem it addresses and what its limits are. There is also a manifesto explaining the philosophy, an architecture section with diagrams, a phased roadmap, and an uncertainties section that explicitly names what is unproven. Sections are marked draft or settled depending on their stability.

It is written by one person using some of the tools on themselves. The code for each tool lives in separate GitHub organizations; this document explains how they compose.