Was ich immer wieder sage

100 Sessions, vom 7. bis 26. Oktober 2026. 66 davon in einem Arbeits-Repository. Der Rest: Forschungscode, Spiele, Dotfiles, Rechner-Setup und dieser Blog.¹

Ein Skript zieht nur meine eigenen Nachrichten heraus und lässt das Maschinengeplapper weg. Vier Agenten lesen je ein Viertel der Sessions und melden Muster, mit wörtlichen Zitaten. Die Zahlen der Agenten sind Schätzungen, also habe ich mit grep nachgezählt, und danach hat ein Verifier-Agent meine Zahlen nachgezählt. Er fand ein Zitat, das es nicht gab, und eine Zeile, die vor allem aus Fehltreffern bestand. Beides ist unten korrigiert. Die Analyse brauchte ihren eigenen Review-Loop.

Die Muster sind reguläre Ausdrücke, und wiederholte Nachrichten zählen jedes Mal. Die Zahlen sind Größenordnungen, keine Messungen.

Dann die Korrekturen, die Momente, in denen ich das Modell bremsen musste:

• Es hat Aufwand geschätzt, als wäre Code teuer. "eher 5 - 20 min". "just coding something is cheap".
• Es fand unwahrscheinliche Risiken alarmierend. "die sind teilweise sehr unwahrscheinlich".
• Seine Designs waren komplizierter als nötig. "sounds complicated".
• Es hat ein Feature als fertig gemeldet, und der Button war nicht da. "I don't see 'show in designer'".
• Der Pfad, den ich einem Tester gegeben habe, brach beim zweiten Klick. "after using it once it is also a 404".
• Es hat Zahlen aufgerundet. "7.7 is not 10-20x".
• Es hat die Geschichte erzählt, wie wir hingekommen sind, statt wo wir stehen. "die brauchen keine implementations histories, sondern den stand".

Lustig: Die häufigste Nachricht ist keine schwere Frage. Sie lautet "push" und "open the pr". Den schweren Teil kann das Modell. Meine Worte gehen für den letzten Meter drauf.

L2 ist die interessante Ebene. Das Modell und ich hatten verschiedene Wörter für "fertig". Keins war falsch. Meins stand nur nirgends.

L4 habe ich probiert: "Der Mensch ist der Flaschenhals." Klingt tief. Es führt aber zu keiner neuen Suche und keiner neuen Gegenmaßnahme, ist also eine Plattitüde und fliegt raus.

Allgemein, in bjs-claude-skills:

done-check

geht die Definition von "fertig" durch, bevor irgendetwas "fertig" heißt, und erledigt oder listet jeden offenen Schritt.

claim-check

ein Verifier-Agent pro Behauptung in einem Text, gegen die Primärquelle. Der Review-Verify-Loop für Prosa.

reader-rewrite

den Leser und seine Frage benennen, dann feste Regeln anwenden: der aktuelle Stand, ausgeschriebene Namen, Links, keine lokalen Verweise.

skill-mining

dieser Post als Verfahren. Extrahieren, schichten, pro Klasse eine Gegenmaßnahme wählen, nachzählen, schreiben. Er ist seine eigene L3-Gegenmaßnahme: Die Schleife, die aus "das sage ich ständig" einen Skill macht, hängt nicht mehr davon ab, dass es mir auffällt.

Speziell für mein Arbeits-Repository: address-review, ship-pr, cad-handoff, perf-bench, und der Zyklus, der sie zusammenbindet.

Die Analyse hat auch eine Regel ergeben, welche Form eine Gegenmaßnahme bekommt:

• eine einzelne Vorliebe kommt ins Memory;
• ein fehlender Schritt kommt in einen bestehenden Skill;
• ein neuer Skill nur, wenn ein mehrschrittiger Ablauf in mindestens drei Sessions auftaucht.

Die L1-Skills sind immer noch einzelne Schritte. L3 sagt, die Lücke ist der Lebenszyklus. Also war der letzte Zug, den Lebenszyklus aufzuschreiben: dev-cycle, einmal abstrakt und einmal auf mein Arbeits-Repository abgebildet.

Neun Stufen: Aufnahme, Branch, Implementieren, sichtbar laufen sehen, Review, Ausliefern, Feedback, merge-bereit, Abschluss. "Do that" lässt alle laufen. Keine Fragen dazwischen. Eine Frage mit offensichtlicher Antwort bekommt diese Antwort, als Annahme notiert. Halt nur an festen Toren:

• Mergen, das mache ich immer selbst;
• ein Deploy auf eine Umgebung, die nicht meine ist;
• ein Post nach außen, um den ich nicht gebeten habe;
• eine offene Produktentscheidung.

Jedes Arbeitspaket bekommt eine Zustandsdatei, die jede Stufe mit ihrem Beleg festhält. "State?" wird aus der Datei beantwortet, und eine neue Session kann dort weitermachen, wo die letzte aufgehört hat.

Stell dir eine Küche vor, in der der Koch nach jedem Gericht fragt: "Soll ich anrichten?", "Soll ich es rausbringen?", "Soll ich die Pfanne spülen?". Du brauchst keinen besseren Koch. Du brauchst einen Koch, der weiß, was ein fertiges Gericht in diesem Restaurant heißt.

Jeder neue Skill trägt seine Zählungen und Zitate als Beleg-Zeile, dazu eine Löschregel. Keiner ist bisher gelaufen.

Die vier unbenutzten Operatoren sind die Warnung. Sie kamen aus einer sauberen Struktur am Schreibtisch, und niemand hat sie benutzt. Diese hier kommen aus Anfragen, die ich wirklich gestellt habe. Das ist ein besserer Start, aber kein Beweis.

Der Test ist dieselbe Analyse in einem Monat. Stehen "did we …?" und "state?" dann immer noch weit oben, funktioniert der Zyklus nicht.

Offene Fragen:

• Waren die vier Operatoren unbenutzt, weil sie nutzlos sind, oder weil sie nie getriggert werden? Eine Ablation könnte das klären: derselbe Fall mit und ohne Skill.
• Spart "do that" über neun Stufen meine Aufmerksamkeit, oder verschiebt es sie nur an die Tore?
• Wie viel der L0-Tabelle ist mein Stil, und wie viel das Werkzeug? Die 100 Sessions von jemand anderem würden es zeigen.
• Stimmt "die Priors des Modells stammen aus der Zeit vor billigem Code", oder ist das nur meine Lesart von drei Korrekturen?