Früher bestand erstaunlich viel IT-Dokumentation aus Textdateien. README, Installationsanleitung, Konfigurationshinweise und technische Entscheidungen lagen direkt neben dem Code. Dann kamen Wikis, Dokumentenmanagementsysteme, Projektplattformen und Cloud-Dienste mit Datenbanken, Formularen und schicken Oberflächen. Viele davon waren ein echter Fortschritt.
Und jetzt? Jetzt schreiben wir wieder AGENTS.md, Spezifikationen, Pläne und Entscheidungsprotokolle in Klartext. Wir speichern Wissen in Markdown, legen es ins Git-Repository und freuen uns darüber, dass eine KI die Dateien lesen kann.
Das sieht verdächtig nach „Back to the 90s“ aus.
Ist es aber nur zur Hälfte.
Text war nie das Problem
Die alten Textdateien verschwanden nicht, weil Klartext grundsätzlich schlecht war. Sie verschwanden aus vielen Arbeitsabläufen, weil andere Anforderungen wichtiger wurden: mehrere Personen sollten gleichzeitig arbeiten, Berechtigungen mussten verwaltet, Prozesse abgebildet und Daten zuverlässig ausgewertet werden. Eine Datenbank konnte Dinge, die ein Ordner voller Dateien schlicht nicht leisten sollte.
Das Problem begann dort, wo die Oberfläche zur einzigen Wahrheit wurde. Informationen steckten plötzlich in proprietären Feldern, internen Verknüpfungen und schwer exportierbaren Datenmodellen. Menschen konnten sie bequem anklicken. Für andere Systeme waren sie häufig nur über spezielle Schnittstellen erreichbar – falls es überhaupt eine brauchbare gab.
Mit KI ändert sich der Wert offener Dokumente. Ein sauber aufgebautes Markdown-Dokument ist nicht mehr nur eine Datei, die jemand gelegentlich liest. Es kann zum Arbeitskontext für einen Agenten werden.
Dokumentation wird vom Archiv zum Arbeitsauftrag
Eine klassische Dokumentation beschreibt ein System. Agentenlesbare Dokumentation kann zusätzlich beeinflussen, wie an diesem System gearbeitet wird.
Eine AGENTS.md erklärt beispielsweise:
- welche Quelle verbindlich ist,
- welche Dateien nicht verändert werden dürfen,
- wie Änderungen geprüft werden,
- welche Architekturentscheidungen gelten und
- wo die Grenze zwischen Vorschlag und Ausführung liegt.
Das ist keine ausführbare Software im klassischen Sinn. Trotzdem hat der Text operative Wirkung. Ein KI-Agent liest die Regeln, bezieht sie auf seine Aufgabe und richtet sein Vorgehen danach aus.
Ähnlich funktionieren Spezifikationen, Projektpläne, Architecture Decision Records und strukturierte Arbeitsanweisungen. Natürliche Sprache wird nicht automatisch zu Code. Sie wird aber zu einer maschinenverarbeitbaren Schicht zwischen Absicht und Ausführung.
Genau das ist neu.
Wie alt sind die Methoden eigentlich?
Der Eindruck täuscht nicht: Viele Grundlagen unserer heutigen KI-Arbeit sind deutlich älter als ChatGPT. Manche stammen nicht einmal aus dem Computerzeitalter.
| Methode oder Standard | Historischer Anker | Alter im Jahr 2026 |
|---|---|---|
| Zettelkasten | 16. Jahrhundert; Luhmann ab etwa 1951 | über 470 Jahre; moderne Ausprägung etwa 75 Jahre |
| Getting Things Done | ab 1981 entwickelt; 2001 als Buch veröffentlicht | 45 beziehungsweise 25 Jahre |
| Softwareanforderungsspezifikationen | spätestens 1984 formalisiert | mindestens 42 Jahre |
| ITIL | 1989 | 37 Jahre |
| Wiki | 1995 | 31 Jahre |
| Markdown | 2004 | 22 Jahre |
| Git | 2005 | 21 Jahre |
| Johnny.Decimal | 2010 entwickelt; ab 2015 dokumentiert | 16 beziehungsweise 11 Jahre |
| Architecture Decision Records | 2011 | 15 Jahre |
| Semantic Versioning | spätestens 2011 öffentlich dokumentiert | mindestens 15 Jahre |
| Diátaxis | ab 2014 entwickelt | etwa 12 Jahre |
| Keep a Changelog | spätestens 2015 öffentlich dokumentiert | mindestens 11 Jahre |
| Conventional Commits | spätestens 2016 öffentlich dokumentiert | mindestens 10 Jahre |
| Building a Second Brain und PARA | spätestens 2017 praktisch gelehrt | mindestens 9 Jahre |
| Local-first Software | 2019 | 7 Jahre |
Das ist keine zufällige Sammlung alter Nerd-Hobbys. Diese Methoden lösen Probleme, die Menschen und KI gemeinsam haben: zu viele Eingänge, unklare Ablageorte, fehlende Beziehungen, widersprüchliche Quellen und nicht nachvollziehbare Veränderungen.
Warum ausgerechnet Markdown und Git?
Markdown ist unspektakulär. Genau das ist seine Stärke. Überschriften, Listen, Links, Zitate und Codeblöcke bleiben schon im Quelltext erkennbar. Die Datei lässt sich ohne Spezialsoftware lesen, durchsuchen und verarbeiten.
Git ergänzt das, was einer einzelnen Datei fehlt:
- Wer hat etwas geändert?
- Was wurde entfernt oder ergänzt?
- Welcher Stand war zu einem bestimmten Zeitpunkt gültig?
- Welche Änderung gehört zu welcher Entscheidung?
- Lässt sich ein früherer Zustand gezielt wiederherstellen?
Für Menschen entsteht Nachvollziehbarkeit. Für KI entsteht strukturierter Kontext. Markdown und Diátaxis sorgen zusätzlich dafür, dass nicht jede Datei gleichzeitig Einführung, Anleitung, Referenz und Grundsatzdiskussion sein muss.
Das ist der eigentliche Vorteil: nicht bloß Text, sondern lesbarer Text mit Struktur, Beziehungen, Status und Geschichte.
Die Datenbank bleibt
Aus dieser Entwicklung folgt nicht, dass wir CRM, Projektmanagement, Warenwirtschaft oder Dokumentenmanagement künftig durch Markdown-Ordner ersetzen sollten. Wer das versucht, entdeckt sehr schnell, warum Datenbanken erfunden wurden.
Transaktionen, Berechtigungen, Fristen, strukturierte Auswertungen, gleichzeitige Bearbeitung und verbindliche Geschäftsregeln gehören weiterhin in dafür geeignete Systeme. Eine Kundennummer ist kein philosophischer Essay. Eine offene Rechnung sollte nicht davon abhängen, ob ein Sprachmodell das Frontmatter richtig interpretiert.
Eine brauchbare Arbeitsteilung sieht eher so aus:
Datenbanken verwalten Zustand. Markdown beschreibt Bedeutung und Absicht. Git schafft Nachvollziehbarkeit. Oberflächen dienen Menschen. APIs ermöglichen kontrollierten Zugriff.
Diese Ebenen konkurrieren nicht miteinander. Sie erfüllen unterschiedliche Aufgaben.
Warum viele Cloud-Werkzeuge trotzdem schlecht altern
Ein Werkzeug kann heute bequem und morgen ein Problem sein. Der Anbieter ändert Preise, stellt eine Funktion ein oder exportiert zwar alle Daten, aber nicht deren Beziehungen. Die hübsche Oberfläche bleibt dann vor allem eine Erinnerung daran, wie ordentlich alles einmal aussah.
Offene Formate senken dieses Risiko. Sie garantieren keine ewige Portabilität, aber sie verbessern die Ausgangslage. Ein Markdown-Bestand mit verständlichen Links und dokumentierten Metadaten lässt sich meist leichter migrieren als ein undurchsichtiges Exportarchiv aus einer geschlossenen Plattform.
Der Local-first-Ansatz verbindet deshalb lokale Datenhoheit mit moderner Zusammenarbeit. Es geht nicht darum, wieder allein am Rechner zu sitzen und Dateien per Diskette zu verteilen. Es geht darum, dass Zusammenarbeit nicht automatisch den Verlust der eigenen Daten und Arbeitsgrundlagen bedeuten muss.
Alte Methoden, neuer Zweck
Auch GTD, PARA, Johnny.Decimal oder der Zettelkasten werden durch KI nicht magisch besser. Ein chaotischer Zettelkasten bleibt ein chaotischer Zettelkasten – die KI findet nur schneller mehr davon.
Ihr neuer Wert liegt in den Signalen, die sie erzeugen:
- GTD trennt ungeklärten Eingang von verantworteter Arbeit.
- PARA und Johnny.Decimal geben Informationen einen nachvollziehbaren Ort.
- Zettelkasten, Atomic Notes und Evergreen Notes zerlegen Wissen in verständliche und verknüpfbare Einheiten.
- ADRs trennen eine getroffene Entscheidung von der Diskussion, die zu ihr geführt hat.
- Changelog und Semantic Versioning machen Veränderung und ihre Wirkung sichtbar.
Ein Mensch profitiert von diesen Unterscheidungen. Ein Agent ebenfalls. Er muss weniger raten, welche Information gerade gilt und was als Nächstes passieren soll.
Was Unternehmen daraus ableiten sollten
Die falsche Reaktion wäre, jetzt überall Markdown einzuführen. Die richtige Frage lautet: Welche Information muss dauerhaft verständlich, portabel und für Menschen wie Maschinen zugänglich bleiben?
Ein pragmatischer Anfang:
- Für jede wichtige Information eine kanonische Quelle festlegen.
- Dauerhafte Regeln und Entscheidungen aus Chats in gepflegte Dokumente überführen.
- Textbasierte Formate nutzen, wenn Inhalte ohne Spezialoberfläche verständlich bleiben sollen.
- Änderungen an Code, Konfiguration und technischer Dokumentation gemeinsam versionieren.
- Datenbanken dort einsetzen, wo strukturierter Zustand und verlässliche Prozesse gefragt sind.
- KI nur auf Quellen zugreifen lassen, deren Status, Verantwortung und Grenzen geklärt sind.
Das klingt weniger spektakulär als „Wir führen eine autonome Agentenplattform ein“. Dafür ist nachher eher erkennbar, was der Agent eigentlich tun sollte.
Nicht zurück, sondern weiter
Ja, vieles erinnert an die 1990er. Textdateien, Verzeichnisse, README-Dokumente und Versionsverwaltung stehen wieder erstaunlich weit oben auf der Werkzeugliste. Der entscheidende Unterschied liegt aber nicht im Format, sondern in seiner Rolle.
Früher wartete die Dokumentation darauf, von einem Menschen gelesen zu werden. Heute kann sie zugleich Menschen informieren, Software konfigurieren, Prüfungen auslösen und Agenten bei ihrer Arbeit begrenzen.
Wir gehen deshalb nicht zurück in die 1990er. Wir nehmen die besten Eigenschaften offener, einfacher Systeme mit nach vorn.
Oder kürzer: Forward to open, agent-readable systems.
