Mon usine logicielle à l'heure de l'IA

Kernpunkte

1. ⭐ Das Drei-Fragen-Raster — die am besten wiederverwendbare Erkenntnis. Das gesamte Tooling beantwortet "Was weiß der Agent?" (Kontext, Memory, Code-Graph), "Was kann er deterministisch tun, ohne zu improvisieren?" (Skills, Prozeduren), "Was stoppt ihn, wenn er einen Fehler macht?" (Hooks, Architekturtests, Quality Gates). Sofort-Audit-Raster: an jedes agentische Setup angelegt, offenbart es innerhalb von drei Minuten, welche der drei Fragen leer bleibt. Fast immer ist es die dritte.
2. ⭐⭐ Das Leitprinzip, wortwörtlich zu merken. "Was wichtig ist, muss ausführbar sein. Eine Anweisung wird 'meistens' befolgt, kann aber vergessen werden. Ein Hook oder ein Test wird immer befolgt." An anderer Stelle bezüglich Architekturtests noch schärfer formuliert: "er kann nicht umgangen werden, im Gegensatz zu einer Regel." → Eine Regel ist eine Absicht, ein Test ist eine Garantie. Dies ist dieselbe These wie der Constraint Ring in [[sfeir-code-review-anneau-contraintes-2026-07-30]] (zwei Tage später veröffentlicht) und der Harness in [[osmani-agent-harness-engineering-2026-04-19]], jedoch an einem realen Solo-Setup demonstriert, nicht als Doktrin verkündet.
3. Explizit gegen vibe coding. "Vibe coding, wie von Karpathy definiert, war Experimentieren und Loslassen. Hier werde ich über context engineering sprechen." Und die daraus resultierende Verantwortungsklausel: "Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten." Vgl. [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]].
4. Softwarequalität ist nicht Codequalität. Sie schließt die Absicht (warum, für wen) und Marty Cagans vier Risiken ein — Value, Usability, Feasibility, Viability — sowie Performance und Zuverlässigkeit. Dies rechtfertigt Schicht 6 (Produktprozess) und erklärt, warum eine rein technische Softwarefabrik am eigentlichen Punkt vorbeigeht.
5. Schicht 1 — Kontext, und der nachahmenswerte Kniff. drei Ebenen, getrennt nach ihrem Ladezeitpunkt. Root-CLAUDE.md (Architektur, übergreifende Konventionen, Spec-Index) → permanent und kurz; .claude/rules/.md → bedingt, aktiviert über ein paths:-Frontmatter (die Kotlin-Regel lädt nur, wenn api// berührt wird); .agents/.md → nicht-technischer Kontext (Produktpositionierung, Personas, Ton). ⭐ Die Regel, vollständig betrachtet, ist eine Routing-Tabelle: Sie enthält nicht die Prozeduren, sondern listet neun Skills mit der Aufgabe auf, die jeden auslöst, um nur bei Bedarf geöffnet zu werden. "Wenn die KI keine Schema-Änderung vornimmt, gibt es keinen Grund, den db-migration-Skill zu öffnen." → Der permanente Kontext trägt den Index, nicht den Inhalt.*
6. ⭐ Eine langfristige Einschränkung, kodiert sowohl als Kontext als auch als Test. — das beste Beispiel des Textes: Der Autor plant, einen Teil des Codes als Open Source zu veröffentlichen. Die Regel "für Open Source vorgesehener Code darf niemals von proprietärem Code abhängen" ist in die Regeln geschrieben und durch einen Architekturtest verifiziert (keine Datei auf der "offenen" Seite verweist auf die "proprietäre" Seite; jede Produktionsdatei gehört zur einen oder anderen Seite). "Eine zukünftige Einschränkung in den Kontext zu schreiben, erspart später eine Neufassung." → Eine Entscheidung, die noch nicht existiert, kann bereits mechanisch garantiert werden.
7. Der Satz, der den Magic Prompt tötet. "Es bringt nichts, einer KI zu sagen, sie solle 'qualitativ hochwertigen Code schreiben', das ist bedeutungslos. Man muss seine eigenen Einschränkungen explizit machen." Gepaart mit seltener Ehrlichkeit: "Eine Einschränkung ist spezifisch für ein Projekt und eine Person … Feature Flags zu verwenden ist nicht besser oder schlechter, es ist einfach meine Präferenz."
8. Schicht 2 — Skills. "eine einmal geschriebene Prozedur, die identisch wiederholt wird." Existenzkriterium: die dritte Wiederholung. Etwa dreißig, verteilt auf sechs Familien (Backend, Frontend, Daten, Produktzyklus, Betrieb/Runbooks, Schreiben). Zwei Lehren: Skills für "dateiübergreifende Prozeduren" sind am kosteneffizientesten ("das Hinzufügen eines Blocks zum Content-Editor betrifft drei Rendering-Oberflächen; ohne einen Skill vergisst der Agent systematisch eine davon"), und Skills für "aktuelle Docs" sind bei sich schnell verändertem Code entscheidend. ⚠️ Operative Nuance: "Dieses automatische Laden kann manchmal fehlschlagen. In diesem Fall muss man explizit darum bitten, den Skill zu verwenden." Vgl. [[shihipar-claude-code-lessons-building-skills-2026-06-03]], [[agent-skills-anthropic-2025-10-16]], [[vincent-superpowers-agentic-skills-framework-github-2026-04-02]].
9. Sub-Agents, im Rückgang. reserviert für Aufgaben, "die viel Lesen ohne viel Entscheidung erzeugen" (Audits, breite Exploration, Doc-Entwürfe) — sie "verbrauchen ihren eigenen Kontext und liefern eine Schlussfolgerung zurück, keinen Dateidump." Aber: "Ich nutze sie immer weniger, aktuelle Agenten delegieren selbst recht gezielt." Signal des Wandels: eine Tooling-Praxis, die durch das Modell teilweise obsolet geworden ist.
10. ⭐ Schicht 3 — GitNexus, das interessanteste Tool des Setups. Das Repository wird als Graph indiziert (Symbole, Beziehungen, Ausführungsflüsse), was impact(symbol) vor einer Änderung liefert (Blast Radius, Aufrufer, Risikostufe), detect_changes() vor dem Commit ("habe ich nur das berührt, was ich beabsichtigt habe?"), das Suchen nach einem Ausführungsfluss statt dem Grep eines Funktionsnamens, und Umbenennen über den Aufrufgraphen statt Suchen-und-Ersetzen. Und die Begründung, die mehr zählt als das Tool selbst: "Das eigentliche Problem ist nicht die Geschwindigkeit, sondern das Erkennen aller Nebenwirkungen einer Änderung." → übertragen in Regel #4: "Auswirkungen vor und nach der Änderung messen. Wir wollen den Effekt '1 Bug behoben, 10 eingeführt' vermeiden." Vergleichenswert mit strukturiertem Code-Graph-Kontext gegenüber Vektor-RAG — dieselbe Argumentfamilie wie das Compare-the-Market-Ergebnis, zitiert in [[sfeir-code-review-anneau-contraintes-2026-07-30]].
11. MCP, mit einem Kostenvorbehalt. "Ich versuche, MCPs zu vermeiden, die mehr Kontext verbrauchen, aber ich habe trotzdem noch einige" — JetBrains-IDE (Build, Inspektionen, Refactorings, indizierte Suche), GitNexus, Business-Services (Zahlung, Monitoring), Datenbank, Browser. MCP wird als zu rechtfertigende Kontextausgabe behandelt, nicht als Selbstverständlichkeit.
12. Schicht 4 — Hooks: die entscheidende Definition. "Skripte, ausgelöst vom Harness des Agenten, nicht vom Agenten selbst." Zwei produktive Anwendungen: vor einem Shell-Aufruf den nativen Build ablehnen und auf den IDE-Build umleiten (schneller, strukturierte Fehler), mit Erklärung des Fallbacks; nach einem Dateischreibvorgang den Formatter/Linter ausführen. Weitere genannte Anwendungen: Blockieren von Änderungen an generierten Dateien, Verlangen eines Tests bei jedem neuen Modul, Verbieten eines gefährlichen Musters.
13. ⭐ Pattern-Linting — die Unterscheidung, die man sich merken sollte. ESLint für Syntax, ast-grep für Architekturentscheidungen (Beispiel: jeden fetch-Aufruf verbieten, der den OpenAPI-Client umgeht), Typecheck für Typisierung. → Eine Architekturentscheidung kann zu einer Lint-Regel werden. Dies ist das fehlende Bindeglied zwischen "wir haben entschieden" und "es wird durchgesetzt", und es kostet nur wenige Zeilen.
14. Schicht 5 — das Gate. Push auf main → Quality Gate (Lint → Pattern-Lint → Typecheck → Tests) → Docker-Image bauen → Push in die Registry → Deployment-Webhook. Der strukturelle Punkt: Der Deployment-Job hat ein needs: auf den Quality-Job. "Nichts geht in Produktion, ohne das Gate zu bestehen. Das ist als allgemeine Regel essenziell, umso mehr bei automatisch produziertem Code." Fünf Teststufen: Unit (intensiv), Integration mit Disposable Containers ("echte Datenbank und Broker, keine Mocks"), Architektur, Frontend-Komponenten, End-to-End nur auf kritischen Pfaden. Vgl. [[williams-adlc-3-tests-are-the-spec-2026-06-12]] und [[williams-adlc-2-two-human-gates-2026-06-12]].
15. Schicht 6 — der Produktprozess, und der Schritt, den alle vergessen. nummerierte Specs (eine pro Funktionsbereich, indiziert im permanenten Kontext), eingerahmt von zwei Skills — einem zum Verfassen der Spec und ihres Plans, einem zum Abschließen, indem sie mit dem tatsächlich Gebauten aktualisiert wird. "Ohne ihn werden Specs innerhalb von sechs Monaten obsolet", und als Abschlussregel: "Spec-Dokumentation stirbt, wenn ihr Abschluss nicht Teil des Prozesses ist." ⭐ Das Abschließen ist der Teil des Dokumentationszyklus, den es anderswo fast nie gibt.
16. Anti-Halluzinations-Regel für Specs. "Wenn eine Spec unklar ist oder nicht mit dem bestehenden System übereinstimmt, muss der Agent nachfragen, nicht raten." Eine einzige Kontextzeile, die den kostspieligsten Fehlermodus der agentischen Entwicklung adressiert.
17. Gestaffelte Auslieferung, und ihre Begründung. Die Spec ist so konzipiert, dass sie in Stufen ausgeliefert wird, geschützt durch ein Feature Flag, "das erlaubt mir mehrere kleine Implementierungssitzungen statt einer großen Sitzung, die an Qualität verliert, sobald sie zu voll wird." → Hier wird die Produktzerlegung durch die Degradation bei langem Kontext diktiert, nicht durch Projektmanagement. Nützliche Unterscheidung: Feature Flipping (Unleash — Ein-/Ausschalten ohne Redeploy: Rollout, Kill Switch, Wartung) vs. Gating (Konfigurationstabelle + Service — Einschränkung nach Kundenvertrag oder -plan). Zwei Mechanismen, zwei Bedürfnisse, und ein Skill, damit Agenten sie nicht verwechseln.
18. Wo man anfängt (die vorgegebene Reihenfolge, und sie ist gut). (1) zuerst das Quality Gate, falls es noch nicht existiert; (2) eine schlanke CLAUDE.md, die das Wesentliche und das Warum beschreibt; (3) Regeln, inkrementell hinzugefügt für wichtige Architekturmuster; (4) Skills, sobald sich eine Prozedur wiederholt; (5) CLI und MCP für die wichtigsten Tools. ⚠️ Sicherheitswarnung: "jeder Skill, jedes MCP oder jeder von außen eingebundene Code muss geprüft werden. Das sind Abhängigkeiten, die Angriffsvektoren sein können." Vergleichenswert mit der agentischen Angriffsfläche, beschrieben in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]].
19. ⚠️ Gelebte Einschränkungen — der Abschnitt, der die Seite glaubwürdig macht. 1. Die Obsoleszenz einer Regel ist nicht messbar. "Mitte 2025 ergab 'schreibe einen Test für jeden neuen Service' Sinn. Heute ist es Rauschen, und Claude macht es natürlich… Ich habe keine Möglichkeit zu messen oder zu wissen, ob eine alte Regel obsolet geworden ist." → Der angesammelte Kontext verfällt im Tempo der Modelle, und nichts verfolgt diesen Verfall. Das ist die eigentliche methodische Lücke des Feldes, und sie wird hier ohne Lösung benannt. 2. Das Kaninchenloch. Eine boyscout.md-Regel ("den Code immer ein wenig besser hinterlassen … Verbesserungen für mich markieren") erzeugt "endlose Sessions" und kognitive Überlastung. Angedachte Lösung: diese Befunde in eine TODO-Liste leiten und die Wartung in einen separaten, teilweise automatisierten Workflow verlagern. → Eine gute Anweisung zur kontinuierlichen Verbesserung wird zum Drift-Generator, wenn der Agent nicht von selbst aufhört. 3. Kein Packaging. Skills und Regeln werden von Projekt zu Projekt kopiert-eingefügt, manchmal maschinenabhängig. Es fehlt: eine Möglichkeit zum Packaging für die Auslieferung und zur Zentralisierung der Wartung. 4. Abhängigkeit von Claude, eingestuft als "moderates Risiko" ("das gesamte Ökosystem bewegt sich aufwärts"), mit Interesse daran, Open-Weight-Modelle zu testen — blockiert durch die Hardware. Und die IDE passt inzwischen schlecht: "Ich benutze noch IntelliJ, finde es aber nicht mehr zeitgemäß. Ich habe noch keine interessante Alternative gesehen."
20. ⭐⭐ Das zugrunde liegende Eingeständnis, wortwörtlich zitierenswert. "Die neuesten Opus-Versionen werden zunehmend autonomer … Es ist grenzwertig beunruhigend, und rigoroser als 99 % der Menschen. Seien wir ehrlich, ich werde in den Implementierungsphasen immer weniger nützlich, aber ich möchte die Kontrolle über den produzierten Code nicht verlieren. Ich bin hin- und hergerissen zwischen der Zufriedenheit, eine zunehmend effiziente Softwarefabrik zu haben, und dem Risiko, das Wissen zu verlieren." → Dies ist genau die Comprehension Debt aus [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]], von innen ausgesprochen von jemandem, der den vollständigsten möglichen Harness gebaut hat und feststellt, dass der Harness genau dieses Problem nicht löst. Das Setup garantiert, dass der Code korrekt ist; es garantiert nicht, dass der Mensch ihn weiterhin versteht. Die offene Frage des Textes: "Ich muss einen Weg finden, die Entwürfe im Nachhinein zu überprüfen, um mir das Ergebnis zu eigen zu machen."
21. ⚠️ Nicht zu überdehnender Geltungsbereich. ein Solo-Setup, für persönliche Produkte, mit einem einzigen Entscheider. Keine Koordination mit mehreren Entwicklern, kein Peer Review, keine Compliance- oder Audit-Vorgaben — die Ebene "wer validiert" wird von einer einzigen Person besetzt, die auch Autor der Regeln ist. Was auf ein Unternehmensumfeld übertragbar ist: das Drei-Fragen-Raster, das Ausführbarkeits-Prinzip, das Spec-Abschließen, das Pattern-Linting. Was nicht unverändert übertragbar ist: das vollständige Fehlen eines menschlichen Gates außer sich selbst.
22. Meta / Verwandtes. eine praktische Demonstration von [[osmani-agent-harness-engineering-2026-04-19]] und ein direktes Pendant zu [[sfeir-code-review-anneau-contraintes-2026-07-30]] (2 Tage später veröffentlicht, dieselbe These: Qualität lebt im Ring der Constraints, nicht im Code); dasselbe Vokabular der "Softwarefabrik" wie [[wescale-usine-logicielle-augmentee-juge-strategique-2026-05-03]], jedoch im Maßstab einer einzelnen Person; steht im Gegensatz zum vibe coding von [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]]; konvergiert mit [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]] beim Explizitmachen von Constraints; zu lesen zusammen mit [[shihipar-claude-code-lessons-building-skills-2026-06-03]] zu Skills und [[williams-adlc-3-tests-are-the-spec-2026-06-12]] zu Tests.