Fabro: Die Dark Software Factory für KI-Agenten mit Hirn

Es gibt zwei Arten, mit KI-Coding-Agenten zu arbeiten. Die erste: jeden Schritt manuell begleiten, jede Entscheidung abnicken, jeden Output prüfen — Babysitting auf Entwicklerniveau. Die zweite: dem Agenten die Aufgabe überlassen, nach einer Stunde zurückkommen, und einen 50-Dateien-Diff vorfinden, dem man nicht vertraut.

Fabro nennt beides unzureichend. Und bietet einen dritten Weg.

Was ist Fabro?

Fabro — "The Dark Software Factory" — ist eine Open-Source Workflow-Engine für KI-Coding-Agenten. Das Kernkonzept: Softwareprozesse werden nicht als Prompt, sondern als versionierter, deterministischer Graph definiert. Der Agent führt den Graph aus. Der Entwickler greift nur da ein, wo es wirklich drauf ankommt.

Das Projekt ist in Rust geschrieben, MIT-lizenziert, selbst-gehostet, und braucht — das ist bemerkenswert — kein Python, kein Node.js, kein Docker. Ein einzelnes Binary, keine Abhängigkeiten.¹

# Installation via Claude Code
curl -fsSL https://fabro.sh/install.md | claude

# Via Codex
codex "$(curl -fsSL https://fabro.sh/install.md)"

# Via Bash
curl -fsSL https://fabro.sh/install.sh | bash

Das Kernproblem: Agenten haben keinen Prozess

Aktuelle KI-Coding-Agenten sind gut darin, Aufgaben zu erledigen — aber sie haben kein Prozessgedächtnis. Jede Session beginnt von vorne. Es gibt keine formale Unterscheidung zwischen "planende Phase" und "implementierende Phase", kein eingebautes Review-Gate, keine automatische Verifikation.

Das Ergebnis ist entweder Micromanagement oder blinder Vertrauen.

Fabro's Antwort: Workflow-as-Code. Der Prozess wird explizit gemacht, in Graphviz DOT geschrieben, versioniert wie Quellcode — und ist damit reviewbar, wiederholbar und iterierbar.

Workflow-Graphen in Graphviz DOT

Das zentrale Artefakt in Fabro ist eine .fabro-Datei — ein gerichteter Graph in der Graphviz DOT-Sprache. Jeder Knoten ist eine Stage: Agent, Shell-Kommando, Human Gate oder Bedingung. Kanten definieren den Ablauf.

Ein einfaches Plan-Approve-Implement-Workflow:

digraph PlanImplement {
  graph [
    goal="Plan, approve, implement, and simplify a change"
    model_stylesheet="
      * { model: claude-haiku-4-5; reasoning_effort: low; }
      .coding { model: claude-sonnet-4-5; reasoning_effort: high; }
    "
  ]

  start [shape=Mdiamond, label="Start"]
  exit  [shape=Msquare,  label="Exit"]

  plan      [label="Plan",      prompt="Analyze the goal. Write a step-by-step plan."]
  approve   [shape=hexagon,     label="Approve Plan"]
  implement [label="Implement", class="coding"]
  simplify  [label="Simplify",  class="coding"]

  start -> plan -> approve
  approve -> implement [label="Approve"]
  approve -> plan      [label="Revise"]
  implement -> simplify -> exit
}

Was hier passiert:

• plan ist ein Agent-Knoten. Er analysiert die Codebase, schreibt einen Plan.
• approve ist ein Human Gate (Hexagon). Der Workflow pausiert. Der Entwickler prüft den Plan, approvet oder schickt ihn zur Revision.
• implement und simplify sind Coding-Stages mit einem anderen Model (Sonnet statt Haiku).

Der Graph ist diffbar. Er lebt im Repository. Er kann wie Code reviewed und geändert werden.

Multi-Model-Routing via CSS-Stylesheets

Einer der originellsten Aspekte von Fabro ist das Model-Routing. Statt alle Nodes an dasselbe LLM zu schicken, werden Models in einer CSS-ähnlichen Syntax zugewiesen — mit Selector-Spezifität:

/* Standard: schnell und günstig */
* {
  model: claude-haiku-4-5;
  reasoning_effort: low;
}

/* Coding-Stages: Frontier-Model */
.coding {
  model: claude-sonnet-4-5;
  reasoning_effort: high;
}

/* Cross-Kritik mit anderem Provider */
#review {
  model: gemini-3.1-pro-preview;
}

Die Spezifität-Logik folgt CSS: #id > .class > shape > *. Ein Node kann einer Klasse zugewiesen werden (class="coding"), und bekommt damit automatisch das konfigurierte Model. Das bedeutet: billiges Model für Planung und Analyse, teures Model nur dort, wo es zählt. Laut Fabro-Dokumentation reduziert das die Token-Kosten erheblich ohne Qualitätseinbussen bei den kritischen Stages.¹

Unterstützt werden aktuell: Anthropic, OpenAI, Gemini — mit automatischen Fallback-Chains wenn ein Provider nicht erreichbar ist.

Human-in-the-Loop als First-Class Concept

Fabro behandelt menschliche Entscheidungen nicht als Sonderfall, sondern als normalen Node-Typ. Human Gates sind Hexagon-förmige Knoten, die den Workflow pausieren bis ein Mensch interagiert.

Drei Arten von Human-Interaktion:

• Approval Gates — Approve oder Revise, mit Feedback
• Interview Steps — Strukturierte Eingabe sammeln (z.B. Feature-Specs, Anforderungen)
• Mid-turn Steering — Laufende Agenten können während der Ausführung gesteuert werden

Das gibt Engineers die Kontrolle zurück, ohne sie in jeden Schritt zu involvieren.

Cloud Sandboxes und SSH-Zugriff

Agenten laufen standardmässig auf dem lokalen Rechner. Für sicherheitsrelevante oder ressourcenintensive Workflows bietet Fabro Cloud Sandboxes via Daytona — isolierte Cloud-VMs mit:

• Snapshot-basiertem Setup (schnelle Umgebungsinitalisierung)
• Konfigurierbaren Netzwerk-Kontrollen
• Automatischem Cleanup nach dem Run
• fabro ssh — Shell-Zugang in laufende Sandboxes
• fabro preview — Port-Forwarding für Live-Previews

Das bedeutet: untrusted Code läuft nicht mehr auf dem eigenen Laptop. Der Agent kann beliebige Befehle ausführen, ohne das lokale System zu gefährden.

Git Checkpointing und Retrospektiven

Nach jeder Stage committet Fabro automatisch den aktuellen Stand auf einem Git-Branch — inklusive Execution-Metadaten. Das erlaubt:

• Resume — Unterbrochene Workflows können von jedem Checkpoint fortgesetzt werden
• Revert — Zurückrollen auf jeden Zustand
• Tracing — Vollständige Nachvollziehbarkeit was welcher Agent wann geändert hat

Am Ende jedes Runs generiert Fabro eine automatische Retrospektive: Kosten, Dauer, berührte Dateien, und ein LLM-geschriebenes Narrativ das erklärt was gemacht wurde und wo Reibung entstand. Die Idee dahinter ist ein Compounding-Effekt: Workflows verbessern sich über Zeit, nicht nur der Code.

API-Server und Web-UI

Fabro läuft entweder als lokales CLI oder als persistenter API-Server mit REST-Endpunkten und SSE-Event-Streaming. Eine React Web-UI ist eingebaut. Das bedeutet:

• Workflows können programmatisch getriggert werden (CI/CD-Integration)
• Runs werden gequeued und parallel ausgeführt
• Der Laptop muss nicht offen bleiben — Workflows laufen auch nach dem Schliessen weiter

Die vollständige OpenAPI-Spezifikation inklusive Client-SDKs ist dokumentiert.¹

Was Fabro NICHT ist

Ähnlich wie Paperclip ist Fabro ehrlich darin, was es nicht löst:

• Kein Agent-Framework — Fabro baut keine Agenten. Es orchestriert sie.
• Kein Prompt-Manager — Prompts gehören zu den Workflow-Nodes, nicht zu Fabro selbst.
• Kein Code-Review-Tool — Fabro orchestriert Arbeit, nicht Pull Requests.
• Keine Magie — Ein schlecht definierter Graph liefert schlechte Ergebnisse. Fabro macht den Prozess explizit, aber nicht automatisch gut.

Installation und Einstieg

# Fabro global installieren
curl -fsSL https://fabro.sh/install.sh | bash

# Einmaliges Setup
fabro install

# Pro-Projekt initialisieren
cd my-project
fabro init

# Ersten Workflow ausführen
fabro run plan-implement.fabro --goal "Add input validation to the login form"

Die Dokumentation unter docs.fabro.sh ist ausführlich — von Hello World bis zu parallelen Multi-Model-Ensembles.

Einschätzung

Fabro adressiert ein reales Problem: Die Lücke zwischen "ich habe einen Agenten, der manchmal gute Ergebnisse liefert" und "ich habe einen zuverlässigen Softwareprozess, der reproduzierbar gute Ergebnisse liefert."

Die Graphviz-DOT-Syntax ist ungewöhnlich, aber konsequent: ein Softwareprozess ist ein Graph, und DOT ist eine bewährte, diffbare, lesbare Sprache dafür. Das CSS-ähnliche Model-Routing ist konzeptionell originell und praktisch sinnvoll.

Was mich besonders interessiert: das explizite Bekenntnis zu Verifikation als First-Class Concept. Build-Failures und Testfehler triggernn automatische Fix-Loops. Human Gates sind keine Notlösung, sondern ein designierter Teil des Workflows. Das ist eine andere Philosophie als "give the agent more context and hope for the best."

Ob Fabro sich durchsetzt, hängt davon ab, wie viel Aufwand Teams bereit sind, in die Workflow-Definition zu investieren. Der Lernaufwand ist real. Der potenzielle Return — wiederholbare, qualitätsgesicherte, kostenoptimierte Codier-Prozesse — ist es ebenfalls.

Links:

• Website: fabro.sh
• GitHub: fabro-sh/fabro
• Dokumentation: docs.fabro.sh