donumAI

donumAI ist aus einem sehr konkreten Ärgernis entstanden: Werkzeuge, die versprechen, „Projektdokumente mit KI zu schreiben“, liefern plausiblen Text und keinerlei Möglichkeit zu wissen, ob er noch stimmt. Ein im März erzeugtes Architekturdokument bleibt liegen, überzeugend wie am ersten Tag, während sich im Mai die Anforderungen geändert haben und es niemandem auffällt. donumAI geht von der gegenteiligen Annahme aus: Der schwierige Teil ist nicht das Erzeugen, sondern sechs Dokumente zusammenzuhalten, die einander widersprechen, sobald sich das Projekt bewegt. Das Produkt ist eine Engine, die ein Softwareprojekt durch sechs Stages führt — Discovery, Schätzung, Domain Design, Architektur, Umsetzungsplan, Testplan — und bei jedem Übergang einen Menschen vor das stellt, was die Agenten geschrieben haben.

## Die sechs Stages und das Gate

Jede Stage erzeugt ein versioniertes Artefakt, das aus Abschnitten besteht. Die Agenten schreiben es, aber sie schließen es nicht ab: Die Prüfung geschieht Abschnitt für Abschnitt, und für jeden lässt sich zustimmen, kommentieren oder Änderungen anfordern. Eine Stage schaltet die nächste erst frei, wenn ihr Gate freigegeben ist — das ist keine Formalie, das ist ein echtes Schloss. Genau darin liegt der Unterschied zwischen einem Assistenten, der produziert, und einem Prozess, der vorankommt.

## Wenn sich weiter oben etwas ändert

Die Wette hinter donumAI ist eng und mechanisch: jedes Dokument versionieren, festhalten, aus welcher Entscheidung jeder Teil stammt, und in dem Moment, in dem sich ein Input ändert, alles als „veraltet“ markieren, was weiter unten davon abhing. Die Drift verschwindet dadurch nicht — sie hört auf, unsichtbar zu sein, und das ist am Ende der größte Teil des Problems. Die Trace Links werden nicht von einem Modell erschlossen: Sie entstehen als Projektion aus den Daten, denn ein erschlossener Link hat eine Fehlerrate, und von da an trägt die ganze Kette diese Fehlerrate mit.

## Deterministische Regeln vor Bewertungsrastern

Jedes Artefakt durchläuft eine Prüfschicht, bevor es das Gate erreicht. Das Prinzip: Jede Eigenschaft, die sich als typisiertes Feld erfassen lässt, verlässt das Urteil eines Modells und wird zu einer strukturellen Regel — Vorhandensein, Kardinalität, Typ, Zugehörigkeit zu einer geschlossenen Menge. Strukturelle Regeln kosten keinen einzigen Aufruf, ändern sich zwischen zwei Durchläufen nicht und lassen sich von gut geschriebener Prosa nicht überzeugen. Nur was übrig bleibt — das unauflösbar semantische Urteil — geht ans Bewertungsraster.

## Markdown ist niemals ein Input

Das ist die Invariante, die alles andere trägt, und zugleich die technische Entscheidung, auf die ich am meisten halte. Der Worker erzeugt keinen Text, sondern typisierte Objekte, über einen erzwungenen Tool Call. Die Regeln laufen auf den Objekten. Markdown ist eine Projektion, erzeugt von einem reinen Renderer, und keine nachgelagerte Komponente liest es jemals. Wenn ich mich in diesem Projekt dabei ertappe, einen Parser oder eine Regex auf Fließtext zu schreiben, bin ich in die falsche Richtung gelaufen. Eine Extraktionsschicht ist eine Inferenz mit einer Fehlerrate, und sämtliche nachgelagerten Regeln würden diesen Fehler erben und aufhören, deterministisch zu sein. Es gibt sogar einen Test, der die Invariante auf dem AST prüft — über den Rückgabetyp und nicht über den Funktionsnamen — und der zeigt, dass er nicht blind ist, indem er die alten Parser erkennt, die in einem älteren Modul verblieben sind.

## Die Methodenleitfäden

Hinter jeder Stage stehen Methodendokumente, und diese Dokumente sind im Produkt selbst lesbar: ein Studienbereich, der erklärt, warum ein Artefakt so aussieht, wie es aussieht, was eine Entscheidung überhaupt festschreibbar macht und nach welchen Kriterien sie beurteilt wird. Sie sind auf Italienisch verfasst, während die übrige Oberfläche auf Englisch läuft — was die Typografie zu einem realen Problem gemacht hat: Lange italienische Prosa hat eine andere Zeilenbreite und einen anderen Rhythmus als eine dichte Oberfläche.

## Design und visuelle Identität

Die Oberfläche ist für technische Menschen gedacht, die stundenlang darin arbeiten: dichte Tabellen, lange Dokumente, Gate-Entscheidungen. Dichte und Lesbarkeit vor Dekoration. Das System heißt „Slate & Ferrous“ und ist nahezu monochrom, mit einem einzigen blauen Akzent: Das Tiefschwarz markiert die primären Aktionen, das Blau markiert den Zustand — so bleibt ein Board voller Karten lesbar, ohne dass die Farbe zwei Aufgaben gleichzeitig übernimmt.

## Tech-Stack

Das Projekt ist ein TypeScript-Monorepo, in dem Control Plane und Execution Plane bewusst getrennt sind: Die API nimmt Anfragen entgegen und verwaltet den Zustand, ein eigener Worker führt die Läufe aus, die Minuten dauern können.

donumAI ist ein persönliches Projekt, allein entwickelt, und folgt einer Reihenfolge, die ich mir selbst auferlegt habe: zuerst die typisierte Verdrahtung, dann der Aufruf des Prüfers und die Messung seiner Varianz, dann der Rest. Die bislang geschriebenen 154 Regeln bleiben Hypothesen, solange sie nicht auf wirklich erzeugten Artefakten gelaufen sind, und die Tabelle, die mich interessiert, hat zwei Spalten: die Regeln, die nie auslösen, und die, die immer auslösen. Ihre Diagnosen sind entgegengesetzt und müssen zusammen gelesen werden — eine Regel, die immer auslöst, ist kein Erfolg der Prüfschicht, sondern das Symptom für etwas, das weiter oben zu korrigieren ist.