Towards a Meta Design of LLM Skills

Ich gehe an Skills philosophisch heran, nicht als Anleitungssammlung. Dann ergeben sich Schichten:

• Schicht 0: die Debugging-Bewegungen, die schon im Modell stecken.
• Schicht 1: Skills, die diese Bewegungen lenken, etwa die Schichtenanalyse.
• Schicht 2: Skills höherer Ordnung, die delegieren, welcher Skill zum Problem passt.
• Schicht 3: Meta-Skills, die dieselben Debugging-Bewegungen auf die Skills selbst anwenden.

Das Modell bisectet, minimiert, vergleicht den laufenden mit dem nicht laufenden Fall und liest Fehlermeldungen, ohne dass ich es ihm sage. Vermutlich stecken diese Bewegungen aus den Trainingsdaten schon darin. Ich kann das von innen nicht belegen, es ist eine Vermutung, die zu dem passt, was ich beobachte.

Ein Skill muss diese Bewegungen deshalb nicht beibringen. Was ihm bleibt: dem Modell eine Richtung geben (worauf soll es sich richten), Vollständigkeit erzwingen (alle Ebenen, alle Geschwister) und von außen prüfbar machen, was das Modell behauptet.

Die Schichtenanalyse ist dafür ein gutes Beispiel, weil sie das Modell auf das Design der Software lenkt. Ohne sie bleibt ein Fix leicht an der Oberfläche, eine Zeile an der Stelle, an der es weh tut. Mit ihr zwingt man das Modell, nach Klasse, Annahme und Prozesslücke zu fragen, und kommt zu tiefen Korrekturen statt zu Pflastern. Ob das Modell ohne den Skill bei der Zeile geblieben wäre, habe ich nicht geprüft. Ein Ablationsversuch (derselbe Fall mit und ohne Skill) steht aus.

Ein Ausdruck new Date() lieferte die echte Uhrzeit des Rechners, wo die fixe Systemzeit der Auswertung erwartet war. Der Fix war eine Zeile.

Die Analyse danach hat vier Ebenen gebraucht.

• L1, gleicher Mechanismus. Es war nicht nur die Uhr. Ich habe alle Host-Imports, Globals und Bibliotheksfunktionen abgesucht und zwölf Quellen ambienten Zustands gefunden: Zufall, Zeitzone, Reihenfolge von Hash-Maps, Stacktiefe und weitere.
• L2, gebrochene Annahme. Caches und inkrementelle Läufe vertrauten der deklarierten Input-Menge. Ein impliziter Input machte sie alle still falsch. Der Test „inkrementell = voller Lauf“ konnte das nicht finden, denn beide Läufe sahen dieselbe Wanduhr.
• L3, Prozess. Im Konzepttext stand „gleiche Engine, gleiches Verhalten“. Dafür gab es nie einen Test. Gleiche Bytes sind nicht gleiche Inputs. Wo pro Behauptung ein Test existierte (Sandbox-Ausbruch), gab es keinen Fehler.
• L4 habe ich geprüft und gestrichen. Sie fand nichts, was L3 nicht schon hatte.

Jede Ebene bekam eine eigene Gegenmaßnahme: Fix, Konstruktion mit Checkliste, ein Eigenschaftstest mit absichtlich verstelltem Ambient, eine Tabelle „Behauptung → Test“.

Das Entscheidende ist nicht, dass es vier Ebenen sind. Jede Ebene wird benutzt, um weiter zu suchen, und jede gefundene Instanz wird geprüft. Eine Ebene, die den bekannten Fehler nur abstrakter formuliert, fliegt raus.

Vom Konkreten zur Klasse aufsteigen, auf jeder Stufe suchen, auf jeder Stufe benennen, was wir falsch gemacht haben, und eine Gegenmaßnahme bestimmen: Das ist eine Denkbewegung. Ich habe sie als Skill festgehalten, bug-layer-analysis.

Pólya hat für die Mathematik genau so gearbeitet. In How to Solve It sammelt er Bewegungen mit Namen und Leitfrage, etwa Spezialisierung, Verallgemeinerung und Rückwärtsarbeiten („Könntest du ein allgemeineres Problem lösen? Ein spezielleres?“). [Pólya]¹ Ein Skill ist in diesem Sinn eine ausgeführte Heuristik.

Drei Begriffe, die ich dafür benutze:

• Denkobjekt: alles, womit man denkend umgehen kann. Ein Bug, eine Entscheidung, eine Annahme, ein Diff. Auch ein Skill.
• Denkoperator: die Klasse von Denkobjekten, die andere Denkobjekte verarbeiten. Die Schichtenanalyse nimmt einen Defekt und liefert eine Fehlerklasse.
• Raum der Denkoperatoren: Operatoren liegen nicht verstreut, sondern in einem Raum mit Achsen. (Vorläufig, siehe unten.)

Die Notiz zum Datumsfehler beginnt nach der Lokalisierung. Gefunden hatte den Fehler ein Agent in einer Case Study. Wie, steht nirgends.

Davor passieren die Bewegungen aus Schicht 0: die Fehlermeldung lesen, den Fehler auf Knopfdruck reproduzieren, ihn minimieren, bisecten (im Raum und in der Zeit), den laufenden mit dem nicht laufenden Fall vergleichen, „das kann nicht passieren“ als Signal für eine verletzte Annahme nehmen. Das Modell macht sie von sich aus.

Die Schichtenanalyse dagegen macht es nicht von sich aus. Sie kommt nach dem Fix und fragt, was der Fehler über das Design sagt. Meine Wette ist, dass genau das die Stelle ist, an der ein Skill am meisten ändert. Das ist eine Hypothese. Beleg wäre ein Ablationsversuch und ein Blick in echte Debugging-Sessions: Wo hört das Modell ohne Skill auf?

Von oben. Ich zerlege einen Operator in Achsen (Objekt, Zeit, Abstraktion, Haltung) und drehe eine um. So bin ich von der Schichtenanalyse zum Pre-Mortem gekommen (Zeitpfeil gedreht) und zum Annahmen-Sturmtest (Abstraktionsrichtung gedreht).

Von unten. Ich frage, was jemand tatsächlich denkt und tut, wenn er debuggt, und leite die Operatoren daraus ab. Die Fachbegriffe dafür sind Protokollanalyse (lautes Denken als Datenquelle) und Cognitive Task Analysis. ²

Den ersten Weg bin ich zuerst gegangen, und das Ergebnis ist die ehrlichste Stelle dieses Posts: Ich hatte vier Skills, die in sich stimmig waren und nie gelaufen sind. Die Einordnung in die Achsen bestätigte die Konstruktion, weil sie aus ihr stammte. Dann habe ich die Schichtenanalyse auf diesen Fehler angewendet:

• L1: Artefakte werden aus einer Struktur erzeugt und nicht an der Praxis geprüft.
• L2: „Ein freier Punkt im Raum ist ein nützlicher Operator“ ist eine Annahme, kein Befund.
• L3: Es gibt kein Annahmekriterium für Skills. Erzeugen kostet nichts.
• Gegenmaßnahme: Ein Operator wird nur gebaut, wenn eine beobachtete Instanz ihn belegt. Jeder Skill führt einen Abschnitt „Belege“ mit einer Streichregel.

Deshalb gehe ich jetzt den zweiten Weg. Der erste taugt, um Lücken zu sehen, nicht um zu entscheiden, was gebaut wird.

Schicht 2 delegiert. Ein Skill höherer Ordnung wählt, welcher Skill zum Problem passt (ein Router). Schoenfeld hat in empirischen Studien gezeigt, dass Pólyas Heuristiken allein nicht reichen. Entscheidend ist die Kontrolle: wann welche Strategie gewählt wird, wie der Fortschritt überwacht wird und wann man einen Weg verlässt. Die Auswahl ist dabei nur ein Teil. ³

Schicht 3 wendet dieselben Debugging-Bewegungen auf die Skills selbst an. Ein Skill hat Fehler wie Code: Er kann auf die falschen Fälle auslösen, mit einem anderen Skill überlappen oder nie etwas finden. Dann lassen sich Schichtenanalyse, Pre-Mortem und Sturmtest auf ihn richten.

Wenn Operatoren Denkobjekte sind, kann man Operatoren auf Operatoren anwenden. „Welche Skills liegen neben diesem?“ ist dieselbe Bewegung wie die Schichtenanalyse, nur eine Ebene höher: von der Instanz zur Klasse, von dort zu den Geschwistern. Das ist auch die Bewegung, mit der der Post entstanden ist.

Bisher sehe ich fünf:

• eine Achse wählen,
• einen Operator umkehren,
• mehrere komponieren (Schichtenanalyse → L2-Annahme → Sturmtest),
• einen Operator auf sich selbst anwenden,
• vor der Anwendung den passenden wählen (ein Router).

Das Risiko ist ein Turm. Meta-Ebenen verschieben das Problem nach oben, und ein Router kann sich selbst irren. Ich halte die Meta-Ebene deshalb dünn: eine Nachbarschaftssuche und ein Router, mehr nicht.

Die Zuordnung ist meine Einschätzung, und die Achsen sind gewählt, nicht gegeben. Nach Popper hat die Kreativität keine Logik und deshalb auch keine vollständige Achsenliste: Ein neuer Begriff kann jederzeit eine neue Achse bringen. Eine Bewegung, die in keine Achse passt, ist der Normalfall und sagt, dass eine Achse dazukommt. Jeder Punkt im Raum ist ein möglicher Wachstumspunkt. (Ich habe den Satz Wheeler zugeschrieben und keine Quelle gefunden, deshalb steht er hier als meine These.) Für Haltungen und Denkgewohnheiten gilt dasselbe.

Debugging ist auch eine Linse auf Denken und Kreativität. Minsky zeigt 1967, dass sich schlecht verstandene Ideen als Programm ausdrücken und dann am Programm korrigieren lassen; Debugging als Denkhaltung geht auf Papert zurück. ⁴ Bei Popper steht die Kritik im Zentrum: Auf ein Problem folgt eine vorläufige Theorie, dann der Versuch der Fehlerbeseitigung, und daraus entsteht in der Regel ein neues Problem. ⁵ Ich lese das als Debugging. Ein Programm ist eine Vermutung, ein fehlschlagender Test ist die Widerlegung.

Nach Popper gibt es für das Erzeugen von Ideen keine Logik, wohl aber für das Prüfen. ⁵ Daraus ergibt sich eine Arbeitsteilung: Operatoren erzeugen fehlbare Vermutungen, und der Kern ist die Kritik. Bei Minsky erkennen Kritiker Problemtypen und aktivieren passende Denkweisen. Das ist nicht Poppers Kritik, die Parallele ziehe ich selbst. ⁴

Die Kritik muss von der Quelle der Vermutung unabhängig sein. Ein Modell, das sich im selben Gespräch selbst kritisiert, ist dafür schwach: Ohne externes Feedback verbessert Selbstkorrektur bei Denkaufgaben meist nichts und wird teils schlechter. ⁶ Der Grund ist wohl, dass Erzeuger und Kritiker dieselben Annahmen teilen; das ist meine Deutung, nicht die der Autoren. Stärker wird die Kritik schrittweise: ein Verifier-Agent mit frischem Kontext, dann eine ausführbare Prüfung wie ein Test, ein grep oder eine REPL-Form, die gar nicht vom Modell abhängt. Deshalb verlangen meine Skills Läufe statt Erzählungen und markieren Ungeprüftes sichtbar.

Die Schichtenanalyse ist in diesem Sinn schon so gebaut: Jede Ebene ist eine Vermutung über die Fehlerklasse, die Suche nach Geschwistern ist der Widerlegungsversuch, und eine Ebene, die nichts findet, wird gestrichen. Operatoren selbst sind auch Vermutungen. Sie überleben, wenn sie Funde bringen.

• Pre-Mortem, Annahmen-Sturmtest, Router und Nachbarschaftssuche sind nicht an echten Fällen erprobt. Nur die Schichtenanalyse hat Funde gebracht.
• Ob der Skill die Funde auf L2 und L3 erzeugt oder nur strukturiert hat, weiß ich nicht.
• Dass die Debugging-Bewegungen schon im Modell stecken, ist eine Vermutung. Ich kann sie von innen nicht belegen.
• Ob die Schichtenanalyse tiefere Fixes bringt als ein nackter Auftrag, ist nicht per Ablation geprüft.

• Welche Bewegungen tauchen in echten Debugging-Sessions wiederholt auf, und welche davon haben noch keinen Operator?
• Wie bewertet man einen Operator? Mein Vorschlag: Er hat Instanzen gefunden, die ohne ihn unentdeckt geblieben wären. Reicht das?
• Wie viele Operatoren braucht man wirklich, und woran erkennt man, dass einer überflüssig ist?
• Welche Achse fehlt noch? Und wer entscheidet, welche Achsen ein Problem braucht?
• Verändert die Schichtenanalyse wirklich, wo das Modell mit dem Fix aufhört, oder hätte es ohne Skill dieselbe Tiefe erreicht?

Ein Fach mit festem Namen ist das nicht. Das hat einen Grund: Reichenbach trennte 1938 den Entdeckungszusammenhang vom Rechtfertigungszusammenhang. [Reichenbach]⁵ Popper hatte schon 1934 bestritten, dass es eine Logik des Entdeckens gibt: Nur das Prüfen ist logisch analysierbar, das Erfinden gehört für ihn zur Psychologie. [Popper]⁵ Die Denkbewegungen wanderten in Psychologie, Mathematikdidaktik und KI. Hier die Spur, die ich bisher gefunden habe.