Vor wenigen Wochen haben wir bei fluado einen ziemlich radikalen Schritt gemacht: Wir haben Jira komplett durch reine Markdown-Dateien ersetzt. Aus diesem Experiment ist faru entstanden. Inzwischen organisieren wir unseren kompletten Arbeitsalltag damit. Weil das System für uns so hervorragend funktioniert, haben wir uns entschlossen, es Open Source auf GitHub zu stellen.
Warum das Ganze?
Uns ging es dabei eigentlich nie darum, noch ein weiteres Management-Tool für unsere KI-Agenten zu bauen. Der springende Punkt war ein anderer: Wir brauchten einen pragmatischen Weg, um die laufende, autonome Arbeit der Agenten für uns Menschen sichtbar zu machen.
Unsere Agenten legen ihre Tasks schlicht als Markdown-Dateien im backlog/-Verzeichnis unseres Repositories ab. Das Prinzip ähnelt einem geteilten Google Drive, nur dass die Synchronisation komplett über Git läuft. Da unsere Entwicklungsumgebungen und Tools ohnehin permanent mit diesem Ordner interagieren, war das der natürlichste Weg. Wir hatten absolut keine Lust, unseren etablierten Workflow für eine externe Projektmanagement-Plattform aufzubrechen. Sobald ein Agent eine Datei speichert, aktualisiert sich das Board. Mehr Magie steckt nicht dahinter.
Genau diese Philosophie vertreten wir bei fluado übrigens auch in Kundenprojekten: Stülpe niemandem krampfhaft neue Software über. Nutze einfach das, was ohnehin schon da ist.
Wir veröffentlichen den Code jetzt, weil wir glauben, dass genau dieser simple Ansatz auch anderen Teams extrem helfen kann – und sei es nur als Inspiration.
Was steckt technisch dahinter?
faru ist im Kern extrem simpel gestrickt: Eine einzige server.js, absolut keine externen NPM-Abhängigkeiten. Man startet das Script in einem beliebigen Verzeichnis, es parst die dortigen Markdown-Dateien und rendert daraus drei typische Kanban-Spalten.
npx github:fluado/faru
Wie funktioniert das in der Praxis? Jede "Aufgabe" auf dem Board ist ein eigener Ordner, der Markdown und klassisches YAML-Frontmatter enthält. Wenn man eine Karte verschiebt oder umbenennt, triggert das Script im Hintergrund automatisch einen Git-Commit und pusht die Änderungen. Da sich das Board zudem alle fünf Sekunden aktualisiert, arbeiten Entwickler nie an veralteten Ständen, selbst wenn das Team verteilt an demselben Repository sitzt.
Ein Klick auf eine Karte öffnet die Detailansicht mit allen wichtigen Metadaten, Meilensteinen und Kommentaren. Hier werden außerdem alle Dateien aufgelistet, die zu dieser Karte gehören. Das Wichtige dabei: Klickt man eine Referenz an, öffnet sich diese direkt in der eigenen lokalen IDE. faru maßt sich gar nicht erst an, ein Texteditor zu sein – dafür hat schließlich jeder Entwickler bereits sein Lieblingswerkzeug.
Stripping it down: Genau 3 Spalten
Und ja, das Board kennt wirklich nur drei Spalten: TODO, WIP und DONE. Keine Option auf mehr.
Das ist kein fehlendes Feature, sondern harte Absicht. Ein Status wie "In Review" fällt bei uns unter WIP. Ein "Blocked"-Ticket ist kein Parkplatz für Probleme, sondern schlicht ein Thema, das sofort gelöst werden muss, oder eben wieder zurück auf TODO wandert. Und "Ready for QA"? Warteschlangen sind erfahrungsgemäß einfach nur die Orte, an denen Tasks sterben.
Eine Aufgabe ist entweder unberührt, gerade in Arbeit oder abgeschlossen. Wer komplexere Zustände glaubt zu brauchen, sollte sich dringend noch einmal mit den Grundlagen von Lean Management beschäftigen.
Was faru definitiv nicht ist
Wir haben nicht vor, hieraus das nächste riesige SaaS-Produkt zu bauen. Es wird keine Gantt-Diagramme geben und wir werden ganz sicher kein Time-Tracking einbauen.
Ebenso wenig können wir eine riesige Open-Source-Community betreuen. Uns fehlt im Agenturalltag schlichtweg die Kapazität, hunderte fremde Pull Requests zu prüfen oder endlos Support-Tickets zu triagen. Klar, wenn jemand eine geniale Idee beisteuert, die uns selbst weiterhilft, ziehen wir das vielleicht nach. Aber wir machen hier keine Versprechungen. Schnappt euch den Code, forkt das Repo und macht damit, was ihr wollt.
Die Zielgruppe
Für wen lohnt sich der Blick also? Wenn ihr stark auf KI-Entwickler-Agenten setzt und wollt, dass diese ihre Arbeitsprozesse genauso nahtlos via Dateien steuern, wie sie Code schreiben – probiert es aus.
Gerade für extrem kleine Teams, die vielleicht nur aus ein oder zwei Entwicklern und einem Set an Agenten bestehen, ist das eine hervorragende Lösung, um sofortige Transparenz ohne monatliche Abo-Gebühren zu schaffen. Eure Daten verlassen niemals eure eigenen Rechner oder euer Git-Repository. Ein Unternehmen mit 50 Entwicklern wird hier hingegen sicherlich nicht glücklich.
Wir haben dieses Tool gebaut, weil wir es selbst brauchten. Und jetzt geben wir es raus – weil, why not?
Mehr aus dem Blog
- Der KI-Agenten-Dschungel — warum der Einsatz von KI-Agenten für die meisten Unternehmen ein Sicherheits- und Compliance-Albtraum ist.
- Der KI-Agent, den niemand offgeboardet hat — KI-Agenten bekommen breite Zugriffsrechte und werden nie überprüft. Woher wir das wissen? Es ist uns selbst passiert.
- Produktspezifikationen in der Lebensmittelindustrie — was ein KI-Agent bei der Prüfung von Produktspezifikationen übernehmen kann.
Lust auf eigene KI-Agenten? Sprecht uns an. Wir bauen Agenten, die wirklich Hand in Hand mit dem Mittelstand arbeiten, ganz ohne überflüssigen Overhead.
Wer ohnehin verfolgen will, woran wir arbeiten, kann unseren Newsletter abonnieren oder uns auf LinkedIn bzw. Bluesky finden.