Mon usine logicielle à l'heure de l'IA

Kernpunkte

1. Datum / Quelle. 28. Juli 2026, eventuallycoding.com, Hugo Lassiège. Eine als solche ausgewiesene Referenzseite, die das Setup beschreibt, mit dem der Autor seine eigenen Produkte allein in Produktion betreibt.
2. Zentrale Einordnung. Dies ist kein vibe coding — „Vibe coding, wie von Karpathy definiert, war Experimentieren und sich treiben lassen. Hier werde ich über context engineering sprechen.“ Mit der Verantwortungsklausel: „Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten.“ ### Das Drei-Fragen-Raster Das gesamte Werkzeug-Set beantwortet drei Fragen, und das ist der am besten wiederverwendbare Beitrag des Textes: | Frage | Was sie beantwortet | |---|---| | Was weiß der Agent? | Kontext, Gedächtnis, Code-Graph | | Was kann er deterministisch? | Skills, Prozeduren | | Was stoppt ihn, wenn er einen Fehler macht? | Hooks, Architekturtests, Qualitäts-Gates | Vor ein agentisches Setup gestellt, zeigt sie, welche der drei Kategorien leer ist. Zugehöriges Leitprinzip: „Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt, kann aber vergessen werden. Ein Hook oder ein Test wird immer befolgt.“ Und zu Architekturtests: „er lässt sich nicht umgehen, im Gegensatz zu einer Regel.“ ### Die sechs Schichten | # | Schicht | Inhalt | |---|--------|---------| | 1 | Kontext | kurzes, permanentes Wurzel-CLAUDE.md (Architektur, Konventionen, Spec-Index); bedingte .claude/rules/.md, aktiviert über paths:-Frontmatter; .agents/.md für nicht-technische Belange (Positionierung, Personas, Tonalität) | | 2 | Skills | rund dreißig, sechs Familien; Existenzkriterium: die dritte Wiederholung | | 3 | Tools | JetBrains-IDE-MCP, GitNexus (Code-Graph), Claude-mem, Sentry, schreibgeschützte Datenbank | | 4 | Leitplanken | Harness-Hooks, Architekturtests, Pattern-Linting (ast-grep) | | 5 | Fabrik | blockierendes Qualitäts-Gate, fünf Teststufen | | 6 | Produktprozess | nummerierte Specs, Skill zum Verfassen und Skill zum Abschließen, Feature-Flags | Schicht 1 — der permanente Kontext trägt den Index, nicht den Inhalt: Die vollständig betrachtete Regel ist eine Routing-Tabelle, die neun Skills zusammen mit der sie auslösenden Aufgabe auflistet. „Wenn die KI keine Schema-Änderung vornimmt, hat es keinen Sinn, den db-migration-Skill zu öffnen.“ Schicht 2 — Skills für „dateiübergreifende Prozeduren“ sind am kosteneffizientesten: „das Hinzufügen eines Blocks zum Content-Editor betrifft drei Rendering-Oberflächen; ohne Skill vergisst der Agent systematisch eine davon.“ Nuance: „Dieses automatische Laden kann manchmal fehlschlagen. In diesem Fall muss man ihn explizit bitten, den Skill zu verwenden.“ Subagenten sind rückläufig, vorbehalten für Aufgaben, „die viel Lesen ohne viel Entscheidung erzeugen“ — „ich benutze sie immer weniger; die jüngsten Agenten delegieren ziemlich präzise von selbst.“ Schicht 3 — GitNexus indiziert das Repository als Graph und liefert impact(symbol) vor einer Änderung, detect_changes() vor einem Commit, eine Ausführungsfluss-Suche statt grep, sowie Umbenennungen über den Aufrufgraphen. Die Begründung des Autors: „Der eigentliche Punkt ist nicht Geschwindigkeit, sondern das Erkennen aller Nebenwirkungen einer Änderung.“ MCP wird als zu rechtfertigende Kontextausgabe behandelt: „Ich versuche, MCPs zu vermeiden, die mehr Kontext verbrauchen.“ Schicht 4 — Hooks sind „vom Harness des Agenten ausgelöste Skripte, nicht vom Agenten selbst“: das Verweigern des nativen Builds und die Umleitung auf den IDE-Build, das Ausführen des Formatters nach einem Schreibvorgang. Linting-Unterscheidung: ESLint für Syntax, ast-grep für Architekturentscheidungen (das Verbieten jedes fetch-Aufrufs, der den OpenAPI-Client umgeht), Typecheck für Typisierung. Schicht 5 — push to main → quality gate (lint → pattern lint → typecheck → tests) → build image → registry → deployment webhook, wobei der Deployment-Job ein needs: auf den Qualitäts-Job trägt. Fünf Stufen: Unit, Integration mit Wegwerf-Containern („echte Datenbank und echter Broker, keine Mocks“), Architektur, Frontend-Komponenten, End-to-End nur auf kritischen Pfaden. Schicht 6 — Specs, eingerahmt von zwei Skills, einer davon zum Abschließen, der die Spec mit dem tatsächlich Gebauten aktualisiert: „Die Spec-Dokumentation stirbt, wenn ihr Abschluss nicht Teil des Prozesses ist.“ Anti-Halluzinations-Regel: „Wenn eine Spec vage oder inkonsistent mit dem Bestehenden ist, muss der Agent fragen, nicht raten.“ Gestufte Auslieferung hinter Feature-Flags, motiviert durch die Verschlechterung bei langem Kontext — „das erlaubt mir mehrere kleine Implementierungssitzungen statt einer großen Sitzung, die qualitativ eher abbaut.“ Unterscheidung zwischen Feature Flipping (Unleash: Rollout, Kill-Switch) und Gating (Kundenvertrag, Plan). ### Der aufschlussreichste Kniff: eine bereits garantierte künftige Einschränkung Der Autor plant, einen Teil des Codes als Open Source zu veröffentlichen. Die Regel „für Open Source bestimmter Code darf niemals von proprietärem Code abhängen“ ist in die Regeln geschrieben und durch einen Architekturtest verifiziert. „Eine künftige Einschränkung in den Kontext zu schreiben, erspart später die Kosten eines Rewrites.“ ### Wo anfangen, in der angegebenen Reihenfolge 1. Zuerst das Qualitäts-Gate, falls es noch nicht existiert. 2. Ein schlankes CLAUDE.md, das das Wesentliche und das Warum beschreibt. 3. Regeln, die schrittweise für wichtige Architekturmuster hinzugefügt werden. 4. Skills, sobald eine Prozedur wiederkehrt. 5. CLI und MCP für die wichtigsten Werkzeuge. Warnung: „jeder Skill, jedes MCP oder jeder von außen eingebrachte Code muss geprüft werden. Das sind Abhängigkeiten, die Angriffsvektoren sein können.“ ### Die vier gelebten Einschränkungen 1. Die Veralterung einer Regel lässt sich nicht messen. „Mitte 2025 ergab ‚einen Test für jeden neuen Service schreiben‘ Sinn. Heute ist das Rauschen, und Claude macht es von selbst … Ich habe keine Möglichkeit zu messen oder zu wissen, ob eine alte Regel obsolet geworden ist.“ 2. Das Kaninchenloch. Eine boyscout.md-Regel erzeugt „endlose Sitzungen“ und kognitive Überlastung; eine erwogene Lösung besteht darin, diese Befunde in eine TODO-Liste umzuleiten und die Pflege in einen separaten Workflow zu verlagern. 3. Keine Paketierung. Skills und Regeln werden von einem Projekt zum anderen kopiert und eingefügt, manchmal maschinenabhängig. 4. Abhängigkeit von Claude, als „moderates Risiko“ eingestuft, sowie eine IDE, die unpassend geworden ist: „Ich benutze immer noch IntelliJ, finde es aber nicht mehr passend für unsere Zeit.“ ### Das zugrunde liegende Eingeständnis „Die neuesten Versionen von Opus werden zunehmend autonomer … Seien wir ehrlich, ich werde in den Implementierungsphasen immer weniger nützlich, will aber die Kontrolle über den produzierten Code nicht verlieren. Ich bin hin- und hergerissen zwischen der Zufriedenheit, eine immer effizientere Softwarefabrik zu haben, und dem Risiko, Wissen zu verlieren.“ Das Setup garantiert, dass der Code korrekt ist; es garantiert nicht, dass der Mensch ihn noch versteht. Offen gebliebene Frage: „Ich muss einen Weg finden, Designs im Nachhinein zu überprüfen, um mir das Ergebnis zu eigen zu machen.“ Dasselbe Problem wie das von [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]] aufgeworfene. ### Geltungsbereich Ein Solo-Setup, für persönliche Produkte, mit einem einzigen Entscheidungsträger: keine Koordination mehrerer Entwickler, kein Peer-Review, keine Compliance-Vorgaben. Was sich auf ein Unternehmensumfeld übertragen lässt: das Drei-Fragen-Raster, das Ausführbarkeits-Prinzip, der Spec-Abschluss und das Pattern-Linting; was sich nicht übertragen lässt: das Fehlen jeglichen menschlichen Gates außer sich selbst. Dieselbe These, zwei Tage später als Doktrin formuliert, in [[sfeir-code-review-anneau-contraintes-2026-07-30]].