Die KI hat verändert, wie ich Software baue
Es ist schon eine Weile her, dass ich den Großteil des Codes nicht mehr von Hand schreibe. Ich beschreibe, was ich will, überprüfe, korrigiere die Richtung, und die KI führt aus. Das hat alles verändert: Was früher einen Nachmittag Tipparbeit kostete, ist heute in Minuten erledigt. Die Lieferung ist nicht mehr eine Frage davon, wie viele Stunden ich sitzen bleiben kann, sondern eine Frage davon, wie gut ich die Maschine lenken kann.
Aber jeder Geschwindigkeitsgewinn legt einen neuen Engpass offen. Und meiner tauchte schnell auf.
Der Engpass, der an die Stelle trat
Ein Code-Agent hat kein Gedächtnis zwischen den Sitzungen. Wenn ich das Terminal schließe und morgen wieder öffne, hat er nicht die geringste Ahnung, was wir gestern entschieden haben, warum wir es entschieden haben, was schon fertig war und was noch fehlte. Jede Sitzung beginnt bei null.
Solange die Arbeit klein war, ließ sich das im Kopf behalten. Aber als die KI anfing, wirklich schnell zu liefern, hatte ich plötzlich mehrere offene Baustellen gleichzeitig — und der schwierigste Teil meines Tages war nicht mehr, Code zu schreiben. Es war, mir den Stand der Dinge zu merken. Was entschieden war, was wovon abhing, was schon erledigt war und was auf halbem Weg liegen geblieben war.
Mit anderen Worten: Die Dokumentation hörte auf, ein Luxus „für später” zu sein, und wurde zu dem, was das Projekt am Laufen hält. Ohne sie halluziniert die KI — sie schreibt neu, was bereits existierte, ignoriert eine Entscheidung, die wir letzte Woche getroffen haben, führt in der falschen Reihenfolge aus. Die Qualität dessen, was sie liefert, hängt nun direkt davon ab, wie gut die Arbeit organisiert und festgehalten ist.
Ich habe fast alles getestet — und alle stießen auf dieselbe Mauer
Ich bin nicht direkt losgezogen, um das Rad neu zu erfinden. Ich habe Monate damit verbracht, die Plugins und Skills zu testen, die die Community genau dafür entwickelt hatte: das superpowers, das GSD (get-shit-done), das cavekit, unter anderem.
Alle haben ihre Verdienste. Es sind durchdachte Projekte, voller guter Ideen, wie man einem Agenten Prozess und Disziplin gibt. Ich habe von jedem einzelnen viel gelernt. Aber am Ende stießen alle auf dasselbe grundlegende Problem: Die Art, das festzuhalten, was die KI „weiß”, war ein Haufen Spec-Dateien in Markdown, die ins Repository committet wurden.
Und das tut in der Praxis auf zwei Arten weh:
- Es verschmutzt das Git. Jede Planung wird zu einer Handvoll
.md-Dateien, die zusammen mit dem Code hochgeladen werden. Die Historie füllt sich mit Prozessrauschen, und das Repository trägt eine Schicht Papierkram, die nicht wirklich das Produkt ist. - Es veraltet schnell. Eine Spec ist die Momentaufnahme eines Augenblicks. Am nächsten Tag hat sich die Realität bereits geändert, aber die Datei bleibt da und behauptet selbstbewusst Dinge, die nicht mehr gelten. Dann liest die KI einen alten Plan, als wäre er die Wahrheit, und die Halluzination wird nur schlimmer.
Ich wollte das Gegenteil einer statischen Datei: Ich wollte einen lebendigen Zustand, den die KI konsultiert und aktualisiert, während die Arbeit voranschreitet — und nicht noch ein Dokument, das allein in der Ecke des Repos altert.
Und wenn das Board der KI selbst gehörte?
Da kam mir die Idee. Jedes Software-Team hat das Problem von „was zu tun ist, warum und in welcher Reihenfolge” längst gelöst — es heißt Aufgabenboard. Jira, Trello, Linear. Warum sollte die KI nicht ihr eigenes haben?
Nur mit einer wichtigen Umkehrung: Dieses Board würde überwiegend von der KI selbst genutzt werden, per MCP (das Protokoll, das es dem Agenten erlaubt, externe Werkzeuge abzufragen und zu bearbeiten). Der Agent liest den aktiven Sprint, nimmt das nächste Card, hält die Entscheidungen fest, hängt den Commit an, schließt die Aufgabe ab. Und ich — der Mensch — komme über die Oberfläche vor allem herein, um zu begleiten und zu überprüfen: zu sehen, was in Echtzeit gemacht wird, Cards zu verschieben, einen Kommentar zu hinterlassen, den er in der nächsten Sitzung liest.
Es ist nicht die KI, die ein Werkzeug für Menschen nutzt. Es ist ein Werkzeug, das für die KI entworfen wurde, mit einem Fenster, durch das der Mensch hineinschaut.
So entstand der claude-organizer
Der claude-organizer ist das, was aus dieser Idee entstanden ist. Es ist nicht nur ein Board: Es ist ein ganzes Ökosystem rund um die Organisation der Arbeit des Agenten. Es gibt Projekte, Sprints, Geschichten und Unteraufgaben, Blocker, Tags, Prioritäten — und eine Oberfläche in Nuxt, die all das in Echtzeit spiegelt, mit Aktualisierung per WebSocket, während die KI arbeitet.
Der gesamte Ablauf geschieht über Skills + MCP. Es sind fünf Skills, die durch das ausgelöst werden, was ich sage, ohne dass ich eine von Hand aufrufe: eine, um das Board zu orientieren und zu bedienen, eine, um eine neue Anforderung in Sprint/Geschichten/Aufgaben zu planen, eine, um ein Card durch seinen Lebenszyklus zu führen, eine für Review (ein verpflichtendes Gate, ausgeführt von einem frischen Subagenten, das die Akzeptanzkriterien prüft und Bugs jagt) und eine für Autopilot, um selbstständig durch mehrere fertige Cards voranzuschreiten. Die dauerhafte Dokumentation — Architektur, Entscheidungen (ADRs), Muster — lebt in den Docs des Organizers selbst, die die KI liest, bevor sie das Rad neu erfindet.
Wie er in der Praxis funktioniert
Der entscheidende Umschwung war für mich dieser: Da das Geplante im Organizer lebt und nicht in der Sitzung, kann ich jede Aufgabe in einer völlig frischen Sitzung ausführen, ohne Qualität zu verlieren. Der Agent öffnet, liest das Board, versteht, wo er steht, erledigt die Arbeit. Es spielt keine Rolle, ob der vorherige Kontext bereits verdampft ist — der Plan steckte nicht in seinem Kopf, er steckte in der Datenbank.
Das löst auf einen Schlag die beiden Gespenster: die Ausführungsreihenfolge (was wovon abhängt, ist in den Blockern explizit) und die Halluzination (er geht von dem aus, was entschieden wurde, nicht von einer vagen Erinnerung). Und es lässt mich mehrere Baustellen gleichzeitig bespielen, sequenziell oder parallel, ohne den Überblick zu verlieren.
Die Entscheidungen gehen nicht verloren, weil sie zu Kommentaren auf dem Card werden: Der Agent hält fest, warum er es auf eine bestimmte Weise gemacht hat, und ich antworte dort. In der nächsten Sitzung liest er die Kommentare, die er noch nicht gesehen hatte, und macht von dem Punkt aus weiter. Es ist ein Protokoll von Entscheidungen, das das Ende jedes Gesprächs überlebt.
Der schönste Nebeneffekt: Das Repository ist wieder nur das Produkt. Keine Spec-Ordner mehr, die das Git aufblähen. Das „was zu tun ist und warum” wohnt im Organizer, zugänglich von jeder Sitzung aus; der Code wohnt im Repo. Jedes Ding an seinem Platz.
Wie man anfängt
Er läuft als Plugin von Claude Code (die fünf Skills + der MCP-Server), mit dem gesamten Stack in Docker. Zum Hochfahren:
1. Fahre den Stack hoch (Postgres + Migrations + API + UI + MCP, auf einmal):
git clone https://github.com/fmilioni/claude-organizer.git
cd claude-organizer
cp .env.example .env
docker compose up -d --buildDie UI läuft unter http://localhost:4401, die API unter :4400 und der MCP unter :4402/mcp. Die Migrations laufen von selbst, bevor die API hochfährt.
2. Installiere das Plugin — es liefert die Skills und registriert den MCP, ohne dass ein claude mcp add nötig ist:
/plugin marketplace add fmilioni/claude-organizer
/plugin install claude-organizer@claude-organizer3. Sprich mit Claude. Es genügt, einfach zu reden. „Ich will folgende Funktion planen” löst die Planungs-Skill aus; „lass uns weitermachen, was kommt als Nächstes?” bringt die KI dazu, das Board zu lesen und dort weiterzumachen, wo sie aufgehört hat. Die Skills werden durch das ausgelöst, was du sagst — du musst dir keinen einzigen Befehl merken.
Das Projekt ist Open Source (MIT). Man kann es zu 100 % lokal mit Docker betreiben oder auf einem VPS hosten und Claude Code dorthin zeigen lassen.
Ich möchte wissen, wie du das organisierst
Das ist im Grunde die Brücke, die mich am meisten interessiert: die Prozessdisziplin, die das Ingenieurwesen längst hat, in die neue Art des Bauens zu holen, mit der KI am Steuer. Der claude-organizer ist mein Versuch, diese Lücke zu schließen — und er ist aus einem echten Schmerz entstanden, daraus, gute Arbeit zwischen einer Sitzung und der nächsten verloren gehen zu sehen.
Und du, wie gehst du damit um? Wirfst du alles in eine Spec-Datei? Vertraust du dem Gedächtnis des Modells? Hast du einen Ablauf, der funktioniert? Erzähl es mir in den Kommentaren — ich würde sehr gerne hören, wie andere Menschen genau dieses Problem lösen.
Und falls du es ausprobieren möchtest, der Code ist komplett offen: klonen, testen und auf GitHub beitragen. Feedback und PRs sind sehr willkommen.
