Audit-trail-by-construction: a thesis for spec-driven AI coding

TL;DR. is a multi-agent framework that takes the opposite bet: discipline first, velocity second. The thesis: for software you eventually have to defend — regulated industries, security-critical systems, anything that gets reviewed by an auditor — the audit trail is not an afterthought. It is the primitive.

The closest cousin to this approach is

The Business Analyst writes a Story body once: "Customer places an order", with two success criteria — SC-1 (the customer receives a confirmation) and SC-2 (the order is visible in the customer's account). The Requirements Engineer then adds a comment that refines SC-1 into testable acceptance criteria — AC-1.1 (email arrives within 60 seconds), AC-1.2 (the order carries a unique and stable number) — plus an edge case EC-1.1.a for the payment-provider timeout. None of this overwrites anything; it is all append.

When the Backend Developer implements, every test carries an inline comment that names the upstream ID it satisfies: // AC-1.1, // EC-1.1.a. A grep for // AC- in the codebase enumerates the acceptance criteria that already have proof. A grep for AC-1.1 traces a single criterion from BA intent down to the line of code that proves it.

That is the audit trail you can show to anyone — auditor, customer, incident reviewer — without having to interpret it. The IDs do not need an explanation; the chain is the explanation.

How a feature flows

. The shortest path:

CODE Kopieren

git clone https://github.com/mahmadhuebsch/trail-aiac

cd trail-aiac

claude

> /trail-install-helper

The install-helper is a meta-agent that walks you through three scenarios — greenfield (Ansible provisions a Plane host for you), existing Plane without agents, existing Plane with agents already provisioned — and lands a working consumer project with the ten personas wired in.

One operational note. The framework assumes a Claude Max 5x subscription as the practical ceiling. That is roughly the level at which a human can still read every ticket the agents are producing. If you find yourself burning through significantly more, you are not really reviewing any more — you are vibe-coding. No human can process that much input consciously, which defeats the entire point of the human-in-the-loop discipline.

Honest caveat: this is not for every team. Most teams do not need that much rigour — they need velocity, and they should pick a velocity-first framework. Trail is for the cases where someone, eventually, will ask you to defend your code: regulated industries, security-critical systems, agencies whose deliverables get reviewed by auditors. In those settings, the discipline is not overhead. It is the only thing that makes AI-generated code defendable.

Trail v0.1.0 is early beta. PRs and design feedback at — the same agent runtime that the framework wraps — and edited by hand from there. The thesis, the worked example, the trade-offs section, and the vibe-coding caveat are mine; structure and phrasing had AI assistance throughout. Given the topic, disclosure felt appropriate.

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen