Hauptgedanke

Der Kontext, der die E-Mails einer Wohnanlage aufnimmt, beginnt mit einer context.md-Datei und einem Satz: aggregieren und nach Themen aufteilen. Diese Stufe trägt, bis man feststellt, dass der aktuelle Stand den Verlauf der Baustelle gelöscht hat – und man fügt ein chronologisches Protokoll hinzu. Sie trägt wieder, bis Gleichnamige und Personen mit zwei Namen doppelte Einträge erzeugen – und man schreibt fachspezifische Direktiven. Dann überschreitet die Datei die tausend Zeilen, und das Modell verliert in seinem Kontextfenster den Überblick – man löst die Direktiven heraus und teilt dann nach Themen auf. Dann wiederholt sich das Fachvokabular in jeder Datei – man zentralisiert es in einer glossary.md.

Jede Stufe hat also eine benennbare Ursache, und diese Ursache ist immer eine Panne der vorherigen Stufe, nie eine abstrakt gewünschte Verbesserung. Das unterscheidet wachsende Komplexität von Overengineering: Die eine antwortet auf einen Bedarf, der sich gezeigt hat, das andere auf eine Architektur, die man schön fand. Der Test steht vor jeder Stufe zur Verfügung – welches konkrete, bereits aufgetretene Problem beseitigt diese Stufe?

Auch die Reihenfolge, die sich daraus ergibt, ist nicht austauschbar: Sauber nach Themen aufteilen kann man erst, nachdem man die Verarbeitungsregeln herausgelöst hat, sonst weiß man nicht, was in jedes Teilstück kopiert werden muss. Und auf jeder Stufe hat man ein System, das funktioniert – keine halbfertige Baustelle, die erst nützt, wenn sie fertig ist.

Warum das wichtig ist

Es kehrt die Art um, wie man an ein System herangeht, das jemand anderes beschrieben hat. Ein vollständiges Modell – Ordner, Lademanifeste, verknüpfte atomare Notizen – liest man naheliegenderweise wie einen Bauplan, den man nur noch umsetzen muss; nützlicher ist es, darin einen Weg zu sehen, von dem man nur die Stufen übernimmt, deren Panne man selbst schon erlebt hat.

Es liefert auch ein Entscheidungskriterium für die nächsten Versionen: Man wechselt die Version, weil der Bedarf gewachsen ist, und die Feststellung, dass er nicht gewachsen ist, ist Grund genug, zu bleiben, wo man ist.

Nuancen und Grenzen

Manche Pannen sind für jemanden vorhersehbar, der schon ein vergleichbares System gebaut hat, und darauf zu warten, dass sie eintreten, kostet eine Migration, die man sich hätte sparen können. Die Regel schützt vor Overengineering, nicht vor Naivität.

Und nicht jede Panne zeigt sich als Mangel. Der Präzisionsverlust eines Modells bei einer langen Datei löst keinen Alarm aus: Er verschlechtert schleichend Antworten, die plausibel bleiben, und die nächste Stufe wird nur erreicht, wenn jemand den Mechanismus im Voraus benannt hat.

Offene Fragen

• Was zeigt in einem bestehenden System an, dass es nicht mehr ausreicht, wenn die Panne nicht die Form einer offensichtlich falschen Antwort annimmt?