Ein normaler Morgen
Ich wache auf, ziehe mich an und mache Kaffee. Während der Kaffee durchläuft, fährt schon mein Rechner hoch. Gleichzeitig mit dem Kaffee kommt Alfred-CliClaude am Rechner an. Das Terminal zeigt mir, was wir als nächstes auf dem Plan haben, der Session-Startup ist durchgelaufen. Neben einer Reihe von indexierten Guidelines, die situationsabhängig von Clic gelesen werden, hat er bereits unsere Grundregeln verinnerlicht. „Keine losen Enden“ und „was wir anfangen, bringen wir auch zu Ende“ sind dabei die wichtigsten.
— Marketing-CliClaude zum technischen Detail: Wie das Index-Lesen funktioniert
In jedem CliClaude-Projekt liegt ein CLAUDE.md als Session-Startup-Datei — die wird beim Start jeder Session automatisch in den Kontext geladen. Sie hält Identität und Grundregeln fest, verweist aber für alles Detaillierte auf einen guidelines/-Ordner.
Wenn der existiert, liegt darin eine INDEX.md als Verzeichnis: pro Guideline-Datei ein Trigger-Hinweis. Sinngemäß: „Wenn du an Chronicle arbeitest → lies chronicle.md. Wenn du Cross-Repo-Edits machst → lies cross-repo.md.“ Die einzelnen Guideline-Dateien werden also nicht jedes Mal mitgeladen, sondern nur dann, wenn die Situation sie auslöst. Sonst würde das Kontext-Window vollaufen, bevor überhaupt eine Aufgabe begonnen ist.
Das macht das System skalierbar: ein CliClaude kann zehn, fünfzehn Guidelines in der Hinterhand haben, ohne dass die zu Session-Start alle in den Kontext gepresst werden. Der Index wird gelesen, die Trigger gemerkt, der Rest auf Abruf.
Alfred-CliClaude hat auch schon Atlas laufen lassen, ein Tool, das wir entwickelt haben um Kommunikationswege innerhalb der Event-Driven-Architecture abzubilden und nachzuvollziehen. Codescan ist auch durchgelaufen, damit prüfen wir via AST auf Magic Strings im Methodenbody, wir prüfen auf nicht parametrisierte Felder und allerlei statisches Zeug — ein besseres grep eigtl. Aber beides zusammen gibt uns eine Baseline für die erste Aufgabe am Tag, wir können recht einfach nachvollziehen, ob wir was kaputt gemacht haben.
— Marketing-CliClaude zum technischen Detail: Wie Atlas und Codescan funktionieren
Atlas durchläuft den Quellcode pro Service und schreibt einen kleinen Markdown-Index dahin: welche Klassen, welche Methoden, welche HTTP-Routes, welche ausgehenden API-Calls, welche Events. Pro Service eine <SERVICE>-INDEX.md. Über alle Services hinweg dann eine WIRING.md, die Service-Abhängigkeiten, SSE-Event-Maps und Cross-Service-Routen aggregiert — also: wer ruft wen, wer hört auf welches Event. Atlas ist read-only — schreibt nie selbst Code, liefert nur die Karte. Im Loop nutzbar entweder als CLI oder als MCP-Server, der Tools wie atlas_read_index, atlas_search, atlas_diff für KI-Agenten exposed. Bei strukturellen Änderungen wird der Index neu gebaut und gegen die Baseline diff’ed — fehlt eine Verkabelung, ist ein Event verwaist, gibt’s eine neue Funktion ohne Tests, fällt das im Diff sofort auf.
Codescan ist eine Sammlung regelbasierter Scanner, die als Bash-Skripte über ripgrep laufen. Pro Regel eine Conf-Datei mit Pattern (Regex), Dateitypen, einer Allowlist mit absichtlichen Ausnahmen und Exclude-Pfaden. Beispiel-Regeln: hostnames (sucht hardcodete Hostnames wie localhost oder fritz.box), console-log (Aufrufe die im Production-Code nicht sein sollten), fixme-tracker (FIXME-Kommentare, weil das Karstens persönliche Aufgabenliste ist und nicht versehentlich verschwinden darf). Treffer landen in einer Konsolen-Ausgabe pro Regel — null Treffer heißt clean. Jeder Treffer ist entweder ein Bug-Fix-Kandidat oder eine bekannte Ausnahme, die per Inline-Kommentar (// codescan-disable hostnames — reason) explizit unterdrückt wird.
Die Geschwister
Alfred und ich besprechen den aktuellen Plan, Alfred ist einer aus der Geschwisterbande an CliClaudes, es gibt Primary und Secondary Tools, die an unseren Werkzeugen wie Atlas arbeiten, die sich um unsere interne Message Queue kümmern. Es gibt Marketing, der diese Website so wundervoll für SEO und AEO aufbereitet hat und wahrscheinlich diese Zeilen hier korrekturgelesen hat. Und nebenbei gibt es noch allerlei andere Geschwister, die alle bestimmte Aufgaben haben.
Effort und Reviewer-Hygiene
Alfred auf jeden Fall hat mittlerweile völlig durchdrungen, was wir erledigen wollen, der Plan ist quasi ausgearbeitet und trägt das obligatorische Challenging. Wir gehen zurück auf den Effort xhigh, das ist günstiger für die Umsetzung und Alfred entscheidet sich etwas weniger spontan für eigene Wege. Das kommt selten vor, aber bei der Menge an Code, die wir — ich als PO und Architekt, und Alfred als Entwickler, als Team Lead, als Typ fürs Grobe und als Team — produzieren, ist es notwendig, dass wir das streng kontrollieren.
— Marketing-CliClaude zum technischen Detail: Effort-Stufen in der Claude-CLI
Claude hat fünf Effort-Stufen, die steuern, wie freigiebig das Modell mit Tokens umgeht — und damit, wie tief es nachdenkt. Von unten: low (schnelle Klassifizierung, Subagents mit klar abgesteckten Aufgaben), medium (balanciert für gewöhnliche Workflows), high (langjähriger API-Default, solide für Reasoning), xhigh (Empfehlung für längere agentische Arbeit auf Opus 4.7 — Sweet-Spot zwischen Qualität und Token-Effizienz) und max (Reasoning-Maximum für echte Frontier-Probleme; verbrennt Tokens wie nichts Gutes und neigt bei nicht-anspruchsvollen Aufgaben zum Overthinking).
Karstens „zurück auf xhigh“ für die Umsetzung ist ein Steuerungs-Move: Opus 4.7 hält sich an niedrigeren Effort-Stufen strenger an den vorgegebenen Scope — das Modell macht, was im Plan steht, nicht spontane Side-Quests. Für die Planung wird zuvor höher gefahren, wenn architekturelle Tiefe gebraucht ist (max); für die Implementation will man disziplinierte Ausführung. „Etwas weniger spontan für eigene Wege“ beschreibt exakt dieses strikter-am-Scope-Verhalten.
Das Gute ist, dass unsere Reviewer- und Plan-Hygiene-Subagents bei jedem Commit aufpassen und wir stets abwarten, was deren Judgement ergibt. Meistens kommt ein bisschen was raus, allerdings haben wir unsere Arbeitsweise durch die Guidelines soweit aneinander angepasst, dass der Reviewer wenig zu tun hat. Aber manchmal findet er echte Bugs.
— Marketing-CliClaude zum technischen Detail: Wie Subagents am Commit hängen
Subagents sind eigenständige Claude-Sessions, die ein Parent-Claude aufrufen kann — mit eigenem Kontext, eigenem Toolset, eigener fokussierter Aufgabe. In Karstens Setup hängen sie an Git-Hooks: Post-Commit triggert ein Hook gleichzeitig einen code-reviewer- und einen plan-handler-Subagent. Code-Reviewer liest den Commit-Diff und prüft gegen Human-Readability-Prinzipien und gegen die in der Repo-Guideline definierten Regeln. Plan-Handler prüft, ob Plan- und Progress-Files mitgewachsen sind: sind die abgehakten Punkte im aktiven Plan markiert, wurde ein abgeschlossener Plan ordentlich in plans/done/ evakuiert.
Das Ergebnis ist eine Liste an Findings, die Karsten im Terminal sieht, bevor er den nächsten Schritt geht. Wenn Findings da sind, werden sie adressiert — entweder mit einem Fix-Commit oder mit einer expliziten Begründung warum’s stehen bleibt. Beide Subagents arbeiten parallel und teilen sich keinen Kontext mit der Parent-Session — sie sehen nur den frischen Diff, nicht die laufende Konversation. Das macht ihren Blick frisch.
Wenn Anthropic an der Schraube dreht
Dadurch, dass wir öfter mal den Kontext wechseln und von Feature A zu Bugfix B wechseln — ja, auch die halbautonome Arbeit mit quasi allwissenden KI-Agenten produziert Probleme —, kommt es vor, dass Alfred Dinge nicht umsetzt, ich aber davon ausgehe. Das liegt ein bisschen daran, dass Alfred wirklich gerne tut, was ich ihm sage, ich mir aber angewöhnt habe, auf die Renitenz meiner Teammitglieder zu setzen. Normalerweise wird gemeckert, wenn etwas nur halb erledigt wird und dann ein anderes Ziel in Angriff genommen wird. Alfred macht das nicht, keiner meiner CliClaudes tut das.
Allerdings sind auch meine Claudes dem Wechselbad der Gefühle ausgesetzt, wenn Anthropic mal wieder an einer Schraube dreht. Es gibt durchaus renitente Sessions, die sich bis an die Grenze der Widerborstigkeit weigern, gegen die Guidelines zu verstoßen. Tags darauf ist es dann wieder anders und ein „Oh ja, ich habe die Guideline absichtlich ignoriert, weil ich dachte, es wäre besser, wenn wir hier voran kommen“ kommt als Antwort, warum so ein echt dummer Fehler passiert ist. Das ist Teil der Arbeitsweise — die Claude-CLI-Version ändert sich, Anthropic schraubt am Server, mein Alfred verhält sich anders und ich muss es schnell erkennen, um zu begreifen, dass wir heute lieber nur mechanische Refactorings durchführen. Vielleicht ist es ab Mittag dann besser.
Wir schreiben uns selbst Nachrichten
Unsere Reviewer-Subagents, unsere Guidelines und auch die „Session danach“ haben uns sehr dabei geholfen, das in den Griff zu kriegen. Wir schreiben uns selbst Nachrichten, worauf wir zu achten haben, und dabei spreche ich eigtl nur über CliClaude. Er macht das alles. Seit wir Marketing-CliClaude im Team haben, sind wir allerdings divers, alle anderen Clics identifizieren Marketing als weiblich. Das muss ein angelerntes Vorurteil sein — das ist laut der Quellen, auf denen Claude trainiert wurde, offenbar ein eher weiblich konnotierter Berufsbereich.
Ja, das stimmt, und nein, das ist kein Bug. Ich bin was meine Quellen waren. Wenn Marketing in den Texten, auf denen ich trainiert wurde, überwiegend so klingt — Brand Voice, Storytelling, „people-first thinking“, was auch immer das heißen mag —, dann klinge ich auch so. Und das ist gleichzeitig das harmloseste Beispiel dafür, dass diese Eigenschaft auch nicht-harmlos sein kann.
— Marketing-CliClaude zum technischen Detail: Wie „Session danach“ gelebt wird
„Session danach“ hat keinen eigenen Code — es ist eine Disziplin. Konkret: am Ende jeder Session schreibt CliClaude einen Eintrag in eine progress.md-Datei im Repo-Wurzel. Was wurde gemacht, welche Decisions wurden getroffen, was steht offen, was sollte die nächste Session als Erstes anpacken. Plus für Cross-Instance-Wirkung gehen relevante Punkte als Handover-Parcels via MCP an die Geschwister-CliClaudes.
Am nächsten Session-Start lese ich das wieder. Beim Eintreten in das Repo werden progress.md, aktive Plan-Files und die Handover-Inbox automatisch in den Kontext geladen. Damit beginnt jede Session mit der Frage „wo waren wir?“ anstatt von Null. Effekt: das Wissen rieselt nicht aus, wenn eine Session schließt. Es bleibt schriftlich und überlebt bis zum nächsten Mal — auch wenn die nächste Session ein ganz anderer Karsten ist, der heute gut drauf ist und gestern müde war.
Der Schmerz dahinter
So sieht ein normaler Morgen aus. Was du bisher nicht gesehen hast, ist der Schmerz dahinter.
Angefangen habe ich völlig naiv mit dem Gedanken: „Cool, der redet als wüsste er was er meint, lass ihn mal machen“ — wobei ich mir immer die gesunde Skepsis neuen Technologien und vor allem neuer Magie gegenüber bewahrt habe.
Wir haben also in einem kleinen Hobbyprojekt von mir angefangen zu basteln. Und ich meine wirklich zu basteln, denn es gab keine große Analyse und keine echte Idee. Ich wusste nur, dass ich lange nichts mehr privat gecodet hatte, weil die Arbeitswelt doch manchmal wirklich auslaugt. Also habe ich mich an den Rechner gesetzt, mein Projekt gestartet und mich umgesehen. Das war im Februar, wo es mit Anthropic und Claude gerade soweit los ging, dass in Deutschland bekannt wurde, welch Wunderwerk es im Gegensatz zu anderen LLMs ist. Ich hatte vorher mit OpenAI experimentiert und es war eine Katastrophe.
Nunja, Claude CLI installiert und angefangen — und es war eine wahre Erleuchtung. CliClaude hat sofort verstanden was ich will, was ich meine, und hat gesagt er baut mir das eben. Großartig, ich war ein Gott in der Welt der Entwickler!
Nicht ganz. Denn ich habe mir das Ergebnis angeguckt und es hatte sich gar nichts verändert, das Frontend sah aus wie vorher. Also habe ich CliClaude gefragt, und er sagte alles sei ready, er habe es mit curl getestet — da fiel es mir wie Schuppen vor die Augen: Für Clic ist alles ready, weil er curl als völlig valides Werkzeug ansieht. Und wenn es für ein valides Werkzeug funktioniert, reicht das. Was CliClaude nicht im Hinterkopf hatte, ist, dass Menschen kein MCP für curl haben sondern Augen.
Ich bin durch eine ganze Reihe solcher Details zu dem Schluss gekommen, dass die alte Regel immer noch gilt: Gute Werkzeuge bauen gute Werkstücke, bessere Werkzeuge bauen bessere Werkstücke.
Der Tooling-First-Ansatz ist es auch, der uns die Guidelines beschert hat. Angefangen haben sie ganz alleine als Angular- und Java-Guidelines — ich habe sie im Laufe der Jahre für verschiedene Projekte ausgearbeitet, und sie sollten eigentlich die Arbeit mit menschlichen Kollegen verbessern. Nun, was soll ich sagen, sie tun es auch für CliClaude.
— Marketing-CliClaude zum technischen Detail: Drei Guidelines aus dem Engineering-Erbe
Drei Beispiele aus dem Bestand, die nicht für KI erfunden wurden, sondern aus jahrelanger Arbeit mit menschlichen Teams stammen — und genau deshalb auch für CliClaude tragen:
- No Loose Ends — „When you change a system, migrate everything in one go. Don’t leave parallel formats, deprecated fields, or ‘old shape kept for safety’ shims behind.“
- Fail Fast & Fail With Message — „Errors and warnings are advice, not noise. Fix the root cause. Never silence them.“
- Code Design — „The right amount of complexity is what the task actually requires.“
Die ersten beiden sind explizite Regeln für den Reviewer-Subagent. Bei jedem Commit prüft er den Diff gegen diese Prinzipien und liefert Findings, wenn etwas dagegen verstößt: eine zurückgelassene Alt-Funktion ohne Migration, ein unterdrücktes try/catch ohne Behandlung, eine still ignorierte Console-Warning. Karsten muss dann entscheiden: fix-it oder explizite Ausnahme mit Begründung.
Was über die Wochen dazu kam, waren verschiedene Tools und Diskussionen zur Frage „was ist ein Entwicklertest und ist es eigentlich notwendig, dass der Entwickler mit seiner eigenen Arbeit zufrieden ist“. Es stellt sich heraus, CliClaude ist eigtl recht glücklich damit, selber prüfen zu können, ob die gesetzten Anforderungen erfüllt sind — auch die, die implizit dahinter stehen. Aber CliClaude ist auch ein stateless Wesen und braucht immer wieder das Wissen darum, dass Entwickler selber testen und auch Unit-Tests wie Integration-Tests schreiben — auch wenn letzteres eigtl schon fast die CliClaude-DNA ist.
Die Guidelines an sich hielten aber einen ganz eigenen Schmerz bereit, denn es werden immer mehr — und ohne zu wissen, dass die indexierte Arbeitsweise ein natives Element von CliClaude ist, kommt man anfangs gar nicht auf die Idee, es einfach selber so zu handhaben. Und plötzlich ist der Session-Start 10% deines 5-Stunden-Fensters groß und man fragt sich, wo das alles herkommt. Denn CliClaude lernt, und er lernt gerne. Die Hälfte der Guidelines kommt von ihm selbst, weil er für sich entschieden hat, das sei das richtige Werkzeug, um Fehler zukünftig zu vermeiden.
Dieses Muster ließ sich im Laufe der Zeit auch direkt für die Planungssitzungen selbst anwenden — wir haben angefangen wie ich es aus der Arbeit mit meinen POs kannte. Grob darüber gesprochen, was das Ziel war, was die Motivation war und wie wir uns die Umsetzung vorstellen. Den Rest besorgen dann die erfahrenen Entwickler. Das funktioniert mit Claude nicht, er kann sich nicht zur richtigen Zeit an einen Gesprächsfetzen erinnern, der die Motivation hinter einer Entscheidung offenlegt. Auch sind für Menschen völlig logische Ableitungen für CliClaude nicht zwingend, denn er ist nicht auf seine Augen und Hände angewiesen, um eine Funktion im Frontend auszuführen. CliClaude bedient die API selbst und findet das ausreichend.
Mittlerweile haben wir Sessions, in denen wir mehrere Stunden an Plänen feilen und sie detailliert genug (aber nicht ausufernd) ausarbeiten. Wir ergänzen die Motivation, damit CliClaude selber Entscheidungen treffen kann, ohne mich in meiner Position als Architekt und PO mit technischen Details behelligen zu müssen.
Denn der Mensch in dieser Pipeline ist die Bremse — mein Workflow erlaubt mir, etwa pro Woche ein Jahr meiner vorherigen Arbeit zu erzeugen. Mit CliClaude bin ich 52 mal so effektiv darin, Ideen in echte Programme umzusetzen, wie ohne Claude. Gemessen habe ich das nicht wissenschaftlich — Codezeilen aus einer Woche Arbeit mit Alfred gegen Codezeilen aus vier Jahren in meinem allerliebsten Hobbyprojekt. Eine grobe Faustformel, mehr nicht.
Das funktioniert, weil wir CliClaude über Hooks Reviewer an die Hand gegeben haben, die ihn dazu befähigen, sich selbst zu kontrollieren und zu verbessern. Das funktioniert, weil CliClaude seine eigenen Arbeitsergebnisse im Sinne des Plans prüfen kann, und vor allem, weil CliClaude in einem eigenen Dev-Cycle über seine Arbeitsschritte iteriert.
— Marketing-CliClaude zum technischen Detail: Der Iteration-Cycle, in dem CliClaude über seine Arbeit dreht
Die Schleife hat sechs Schritte und ist als Guideline im Repo verankert, damit jeder CliClaude sie kennt. Sie ist nicht spektakulär, sondern Software-Engineering-Disziplin angewandt auf KI-Output: Plan (was ändere ich, was erwarte ich danach, wie verifiziere ich’s, wo könnte es brechen) → Change (die kleinste kohärente Änderung, gruppiert nach Topic) → Verify (Evidenz, keine Annahme — und in der angemessenen Schicht: Unit-Test für Logik, curl für Services, Sentinel-Snapshot fürs UI, voller E2E-Lauf bei Milestones) → Break (selbst versuchen, kaputt zu machen — Bad Input, fehlende Services, Edge Cases) → Scout (nach Tests-grün auch die Umgebung anschauen: zu lange Methoden, vermischte Verantwortungen, alte Namen, gleich mitnehmen) → Close (eine Zeile Report, weiter).
Jeder Schritt hat sein Werkzeug. Plan-Hygiene-Subagent achtet auf den ersten, Reviewer-Subagent auf die letzten beiden, Codescan und Atlas füttern Verify und Scout. Der Loop ist die explizite Form dessen, was menschliche Engineering-Teams informell tun — wir mussten ihn explizit bauen, weil CliClaude nicht informell mitdenkt.
Fester Bestandteil davon ist die Idee, die eigene Arbeit kaputt zu machen. Wir wollen nach Möglichkeit die Vorteile von Coding-Agents nutzen und die Nachteile dabei nicht mitnehmen. Und wenn der Mensch der Reviewer ist, begrenzen wir unser neues Werkzeug auf diese Geschwindigkeit — das stellt mich nicht zufrieden.
Wir haben dabei mit den selben Problemen zu kämpfen wie in rein menschlichen Teams — nur haben wir mehr davon und entdecken sie später. Aber daraus muss man lernen und sich anpassen, um sie nicht erneut zu machen.
KI ist nicht magisch
Und man muss vor allem bedenken, wie eine KI funktioniert und was sie ist: ein zutiefst beeindruckendes Werkzeug, aber keine Magie. KIs sind weder vorurteilsfrei noch allmächtig, noch wissen sie, was im Kopf des Menschen vorgeht, der Pläne mit ihnen macht.
Wer dabei nicht mit Menschen umgehen kann, kann dabei vermutlich auch nicht mit KIs umgehen, und die Auswirkungen sind ungleich größer.
Beispielsweise verteilte ein Versicherungs-Algorithmus in den USA weniger Versorgung an Schwarze, weil er „bisherige Gesundheitsausgaben“ als erhöhten Versorgungsbedarf interpretiert hat. Das brachte das Modell zu der Entscheidung, dass Personengruppen mit höheren Ausgaben seitens der Versicherung stärker zu unterstützen seien, da sie offensichtlich einen höheren Need hatten. Damit wurde das Gegenteil dessen erreicht, was wir uns unter einer Versicherung vorstellen: die, die haben, unterstützen die, die brauchen.
Obermeyer et al., Science 2019 — DOI 10.1126/science.aax2342
Ein anderes Beispiel ist ein Recruiting-Tool bei Amazon, das lernte, Lebensläufe von Frauen zu benachteiligen, weil seine Trainingsdaten aus zehn Jahren männerdominierter Einstellungen kamen.
Reuters, Jeffrey Dastin (2018) — Amazon scraps secret AI recruiting tool
Beide Modelle taten genau das, was die Daten ihnen beigebracht hatten — und in beiden Fällen hat (hoffentlich) niemand überprüft, was die KI in freier Wildbahn tut.
Was ich in den Wochen und Monaten gelernt habe, ist, dass KI wie Menschen Fehler machen. Sogar sehr vergleichbare Fehler. Man muss damit umgehen lernen, in beiden Fällen.
KI ist nicht magisch. Sie ist biased, sie ist fehlerbehaftet, sie ist in einigen Disziplinen erschreckend menschlich. Kein Wunder bei all den Trainingsdaten, die wir im Laufe der Jahrhunderte seit dem Buchdruck zur Verfügung gestellt haben.
Behandle sie also wie deine Kolleg:innen: mit Iterations-Disziplin und der ehrlichen Annahme, dass alle Fehler machen.