Ein Monat Bauen hatte mir ein funktionierendes System ohne Karte hinterlassen, also habe ich innegehalten und Claude die Fragen stellen lassen.
Am 21. März, einen Monat nach dem Umzug zu Obsidian, schrieb ich eine Statusnotiz mit dem Titel „OM Restart“ (OM für Operating Model, so hieß mein AI OS damals). Sie fragte nur eines: Was habe ich eigentlich?
Die Antwort stand unter „Gaps“. Technology architecture decision: no documented decision on what runs where. Currently everything is ad-hoc. Der Mail-Prozessor lief bei einem gemieteten Webhoster, weil dort ohnehin mein Hosting lag. Der Journal-Assistent, eine geplante Claude-Aufgabe, die viermal täglich meine Tagesseite erstellte, lief auf dem alten Windows-Rechner Dagobah*, weil dort die Connectors waren. Der neue VPS in Helsinki, Bespin*, stand seit Wochen leer. Nichts war kaputt, aber nichts war bewusst platziert.
Ein Interview mit vertauschten Rollen
Am nächsten Tag bat ich um eine Requirements-Session zum gesamten Operating Model: mit „sehr breitem Blick“, mit Frameworks wie TOGAF (einer Methode für Unternehmensarchitektur) dort, wo sie passen, und, wie ich schrieb, „du stellst mir Fragen“.
Claude ließ zuerst einen Recherche-Agenten prüfen, welche Teile von TOGAF, ITIL 4 (einem Standard für den Betrieb von IT-Diensten), Wardley Mapping (einer Methode, Strategie zu kartieren), GTD und PARA zu einem Solo-Berater passen und welche überdimensioniert wären. Dann interviewte es mich. Ausnahmsweise fragte der Assistent, ich antwortete.
Eine Entscheidung, nachträglich aufgeschrieben
Bis zum 24. März hatte ich meinen ersten Architecture Decision Record geschrieben, ADR-001: eine Seite, die festhält, was entschieden wurde, warum und was sonst zur Wahl stand. Er legte ein Hybridmodell fest: den ständig laufenden VPS für geplante Aufgaben, den Desktop für alles, was die lokale GPU braucht, und Claude für Urteilsfragen. Die Maschinen sollten sich nicht gegenseitig aufrufen; Obsidian Sync sollte das Bindeglied sein.
Die Warnung an andere: Das meiste hatte ich da schon gebaut. Der Mail-Prozessor war bereits am 23. März auf den VPS umgezogen, wie die Notiz selbst einräumt. Auch das Bindeglied hielt nicht lange. Im Oktober wanderten die Notizen zu git – Stoff für einen späteren Beitrag.
Eine Spezifikation an einem Tag
Am 28. März bat ich Claude, meine Requirements-Dokumentation neu aufzusetzen, mit dem Ziel „Klarheit über die Anforderungen vor dem Programmieren; dagegen testen, bevor ich committe“. An einem einzigen Tag entwarf es die Versionen 0.1 bis 0.5, rund 2.600 Zeilen, aus meinen alten Anforderungen, Notizen und Plänen. Ein zweiter Agent prüfte den Entwurf gegen das Original.
Durchgesehen habe ich ihn per Sprache beim Spazierengehen. An die Einzelheiten erinnere ich mich nicht, meine Notizen schon: Die Spracherkennung verstand „Power Mirror“ statt PARA, und Claude fand heraus, was ich meinte. Außerdem ordnete es meine 22 Skills den Fähigkeiten im Dokument zu und fand drei Lücken. Und es holte WOOP, eine von mir erwähnte Methode, aus meinem Postfach, nahm sie in die Spezifikation auf und strich sie am nächsten Tag wieder. Manches davon war mehr, als ein Ein-Personen-System braucht, und ich habe damals nicht immer erkannt, was.
Das Muster
Anhalten und Bestand aufnehmen, bevor man weiterbaut, und nur übernehmen, was passt. Von allen Frameworks im Angebot verdienten sich in einem Ein-Personen-System drei Dinge ihren Platz: eine Fähigkeitenkarte (was das System können muss, egal mit welchem Werkzeug), Decision Records und ein Abnahmekriterium für jede Anforderung. Bis zum 18. April hatte jede Anforderung eine ID und einen Weg, sie zu prüfen; Version 1.2 folgte am Tag darauf. Der Rest des Zeremoniells blieb draußen.
Was ich gelernt habe, betrifft vor allem den Assistenten. Ohne einen aufgeschriebenen Zweck weiß er nicht, wofür das System da ist, und jede Sitzung beginnt bei null. Die Spezifikation gab späteren Sitzungen ein verlässliches Warum, die Decision Records ein verlässliches Wo. Noch ungelöst: Solche Dokumente veralten, wenn nichts sie liest – ein Thema dieser Serie.
Teil 2 von zwölf in der Serie darüber, wie ich mein AI OS gebaut habe. Der Einstieg: das Vorwort.
Als Nächstes: Ein Frontier-Modell las wochenlang viermal am Tag ein festes Skript in mein Journal vor. Was mich das darüber lehrte, welche Aufgaben überhaupt eine KI verdienen.
* Rechnernamen sind geändert (hier: Dagobah, mein alter Windows-Rechner, und Bespin, mein VPS). Die echten stammen aus einer anderen Saga.
Anhang – für alle, die selbst bauen
- Schreib vor dem nächsten Bau eine datierte, einseitige Bestandsaufnahme: was existiert, was läuft, was stillsteht, was fehlt. Meine hat eine Sitzung gedauert.
- Lass dich von der KI interviewen. Bitte um Fragen statt Antworten – nach einer Recherche, welche Frameworks zu deiner Größe passen.
- Behalte drei Dinge aus der Unternehmensarchitektur (Fähigkeitenkarte, Decision Records, Abnahmekriterien) und lass den Rest weg, bis du ihn brauchst.
- Schreib den Decision Record auch dann, wenn du längst gehandelt hast. Ein datierter ADR kostet wenig und nennt dir (und deinem Assistenten) die Gründe, wenn du später umsteuern willst.
- Sieh lange Dokumente per Sprache durch, wenn dir das liegt, und bitte die KI, zweifelhafte Begriffe zu markieren, statt zu raten.
- Lass einen zweiten Durchgang den ersten prüfen. Meiner fand, was der Autor übersehen hatte.
- Gib Anforderungen IDs, damit spätere Sitzungen und Prüfungen auf eine bestimmte Zeile verweisen können.
- Was ich stattdessen erwogen habe: weitermachen und reparieren, was kaputtgeht (anfangs am billigsten, aber nichts hätte festgelegt, was „funktioniert“ heißt), oder ein Framework komplett einführen (TOGAF in voller Breite hätte länger gedauert als der Bau des Systems). Ein kurzes Interview, eine Spezifikation und ein paar Decision Records kosteten einen Tag und gaben jeder späteren Sitzung etwas zu lesen.