# lassiege-usine-logicielle-heure-ia-2026-07-28

## Veille

Referenzseite, veröffentlicht auf **eventuallycoding.com** am **28. Juli 2026** von **Hugo Lassiège** (Lyon, vom Entwickler zum Unternehmer, Autor von Bloggrify, Hakanai und Writizzy). Der Autor rahmt sie so ein: *"Dies wird eher eine Referenzseite als ein Artikel sein"*, gedacht für seine eigene Ressourcenseite. **Thema**: die erschöpfende, toolgestützte Beschreibung einer **Solo-Softwarefabrik**, in der *"der produzierte Code inzwischen fast zu 100 % generiert ist"*, über mehrere polyglotte Monorepos hinweg (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) im **kontinuierlichen Deployment in Produktion**. **Von Anfang an gezogene Unterscheidung**: Dies ist kein **vibe coding** im Sinne Karpathys (Experimentieren, Loslassen), sondern context engineering — *"den gesamten notwendigen Kontext zur richtigen Zeit zu geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird"*, mit dem Satz, der die Verantwortung begründet: *"Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten."* **Das gesamte Tooling beantwortet drei Fragen**, und dies ist das am besten wiederverwendbare Lese-Raster des Textes: *"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). **Sechs im Detail beschriebene Schichten**: (1) **Kontext** — Root-`CLAUDE.md` + thematische `.claude/rules/*.md`, bedingt geladen über `paths:` + `.agents/*.md` für nicht-technische Inhalte (Personas, Positionierung, Ton); (2) **Skills** — etwa dreißig, Existenzkriterium *"wenn ich dasselbe ein drittes Mal erklären muss"*; (3) **Tools** — JetBrains-IDE-MCP, **GitNexus** (Code-Graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK-Output-Filtering-Wrapper, Sentry, Read-only-Datenbank; (4) **ausführbare Leitplanken** — Harness-Hooks, **Architekturtests**, Pattern-Linting (**ast-grep** für Architekturentscheidungen, nicht nur ESLint); (5) **Fabrik** — blockierendes Quality Gate mit `needs:` beim Quality-Job, fünf Teststufen; (6) **Produktprozess** — nummerierte Specs mit einem Skill zum Verfassen **und einem Skill zum Abschließen**, Design in Claude Design, gestaffelte Auslieferung hinter einem Feature Flag, Unterscheidung zwischen **Feature Flipping** (Unleash) und **Gating** (Kundenvertrag). **Die Regel, die alles zusammenfasst**: *"Was wichtig ist, muss ausführbar sein. Eine Anweisung wird 'meistens' befolgt … Ein Hook oder ein Test wird immer befolgt."* ⚠️ **Selten für dieses Genre**: ein Abschnitt "Zu verbessern", der vier gelebte Einschränkungen offenlegt — die **Unmöglichkeit, die Obsoleszenz einer Regel zu messen** (*"Ich habe keine Möglichkeit zu wissen, ob eine alte Regel obsolet geworden ist"*), das **Kaninchenloch**, das eine Boyscout-Regel erzeugt, das **Fehlen einer Packaging-Lösung** für Skills über Projekte hinweg, und vor allem das Eingeständnis der Spannung: *"Ich werde in den Implementierungsphasen immer weniger nützlich"*, *"hin- und hergerissen zwischen der Zufriedenheit, eine zunehmend effiziente Fabrik zu haben, und dem Risiko, das Wissen zu verlieren."*

## Titre Article

Mon usine logicielle à l'heure de l'IA

## Date

2026-07-28

## URL

https://eventuallycoding.com/p/mon-usine-logicielle-a-l-heure-de-l-ia

## Keywords

Softwarefabrik, context engineering, vibe coding, Karpathy, zu 100 % generierter Code, Solo-Entwickler, Monorepo, polyglott, Nuxt, Kotlin, Continuous Deployment, CLAUDE.md, Regeln, bedingtes Laden, paths, agents.md, Personas, permanenter Kontext, Kontextbudget, Token-Ökonomie, Skills, wiederholbare Prozedur, Sub-Agents, Delegation, MCP, JetBrains, GitNexus, Code-Graph, Impact, Blast Radius, detect_changes, Ausführungsfluss, Claude-mem, persistenter Speicher, RTK, Output-Filterung, Sentry, Read-only-Datenbank, ausführbare Leitplanken, Hooks, Harness, Architekturtests, Open-Source-Grenze, Pattern-Linting, ast-grep, ESLint, Typecheck, blockierendes Quality Gate, GitHub Actions, needs, Teststufen, Disposable Containers, testcontainers, End-to-End, Produktprozess, nummerierte Spec, Spec-Abschluss, Claude Design, Mockup, Feature Flag, Unleash, Feature Flipping, Gating, Trunk-based, Marty Cagan, vier Risiken, Regel-Obsoleszenz, Kaninchenloch, Boyscout, Skill-Packaging, Wissensverlust, Hugo Lassiège

## Authors

**Hugo Lassiège** — développeur devenu entrepreneur, basé à **Lyon**, écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets, sa chaîne YouTube et ses blogs.

**Les trois produits cités sont les siens**, et c'est ce qui donne son poids au texte : **Bloggrify** (générateur de blog statique, open source), **Hakanai** (application de newsletter pour blogs statiques) et **Writizzy** (plateforme de blogging — qui propulse la page elle-même, *« Propulsé par Writizzy »* en pied de page). Il ne décrit donc pas une méthode conseillée à des clients mais **le dispositif avec lequel il fait tourner ses propres produits en production**, seul.

## Ton

**Profil**: eine **technische Referenzseite**, als solche präsentiert — *"Dies wird eher eine Referenzseite als ein Artikel sein, und ich werde sie von der Ressourcenseite der Site aus verlinken."* Register eines **Solo-Praktikers**, der seinen eigenen Arbeitsplatz dokumentiert: weder Thought Leadership noch Unternehmens-Case-Study noch Tutorial. Zielgruppe: Entwickler, die bereits Agenten toolen und ein Referenz-Setup suchen, um es mit ihrem eigenen zu vergleichen.

**Stil**: **nummerierte Schichtenarchitektur** (1 bis 6), jede eröffnet durch ihre Funktion, dicht **tabellarisch** — die Seite enthält etwa ein Dutzend zweispaltige Tabellen (Datei/Inhalt, Familie/was sie kodieren, Trigger/Effekt, Stufe/Abdeckung, Bedarf/Mechanismus). Es ist ein **technisches Datenblatt**, keine Demonstration: Die Tabellen tragen die Information, die Prosa trägt die Argumentation. Echte, ungeschliffene Konfigurationsauszüge (eine vollständige `rule` mit ihrem `paths:`-Frontmatter und ihrer Routing-Tabelle zu neun Skills, das ASCII-Diagramm der CI-Pipeline, der Inhalt von `boyscout.md`).

**Drei Merkmale, die den Text von der umgebenden Literatur abheben**:

1. **Bescheidenheit hinsichtlich der Reichweite der Regeln.** *"Eine Einschränkung ist spezifisch für ein Projekt und eine Person. Es ist keine Frage der Softwarequalität im engeren Sinne."* Der Autor weigert sich explizit, seine Konventionen als universelle Best Practices darzustellen — selten in einem Genre, das schnell präskriptiv wird.
2. **Ehrliche Selbsteinschätzung der Tools.** Zu Claude-mem: *"Ich habe ehrlich gesagt Schwierigkeiten, den negativen oder positiven Einfluss zu messen. Ich habe noch nicht genug Abstand."* Zum RTK-Wrapper: *"der Gewinn wird manchmal zunichtegemacht, weil Claude den Befehl zweimal ausführt."* Zu Sub-Agents: *"Ich nutze sie immer weniger."* **Der Leser erfährt, was nicht oder nicht mehr funktioniert.**
3. **Das abschließende, ungelöste Eingeständnis.** *"Ich werde in den Implementierungsphasen immer weniger nützlich"*, *"es ist grenzwertig beunruhigend und rigoroser als 99 % der Menschen"*, *"hin- und hergerissen zwischen der Zufriedenheit, eine zunehmend effiziente Softwarefabrik zu haben, und dem Risiko, das Wissen zu verlieren."* Der Text endet mit einem offenen Problem, nicht mit einer Schlussfolgerung.

**Signatursätze**: *"Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich"*, *"Es bringt nichts, einer KI zu sagen, sie solle qualitativ hochwertigen Code schreiben, das ist bedeutungslos. Man muss seine eigenen Einschränkungen explizit machen"*, *"Was wichtig ist, muss ausführbar sein"*, *"Kontext ist ein Budget"*, *"1 Bug behoben, 10 eingeführt"*, *"Spec-Dokumentation stirbt, wenn ihr Abschluss nicht Teil des Prozesses ist"*, *"wenn ich dasselbe ein drittes Mal erkläre, wird es zu einem Skill"*, *"er kann nicht umgangen werden, im Gegensatz zu einer Regel."*

## Pense-betes

- **⭐ 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.
- **⭐⭐ 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.
- **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]].
- **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.
- **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.**
- **⭐ 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.**
- **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."*
- **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]].
- **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.
- **⭐ 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]].
- **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.
- **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.
- **⭐ 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.
- **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]].
- **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.**
- **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.
- **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.
- **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]].
- **⚠️ 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."*
- **⭐⭐ 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."*
- **⚠️ 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.
- **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.

## RésuméDe400mots

Referenzseite, veröffentlicht am **28. Juli 2026** von **Hugo Lassiège** auf eventuallycoding.com, die seine **Solo-Softwarefabrik** für Produktionsprodukte (Hakanai, Writizzy, Bloggrify) dokumentiert, deren *"produzierter Code inzwischen fast zu 100 % generiert ist."*

**Die Rahmung.** Dies ist kein **vibe coding** — das für Karpathy Experimentieren war —, sondern context engineering: *"den gesamten notwendigen Kontext zur richtigen Zeit zu geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird."* Verantwortung wird nicht delegiert: *"Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich."* Und Softwarequalität geht über den Code hinaus — sie schließt die Absicht und **Marty Cagans vier Risiken** ein.

**Das Raster.** Das gesamte Tooling beantwortet drei Fragen: was der Agent **weiß** (Kontext, Memory, Code-Graph), was er **deterministisch** tun kann (Skills), und **was ihn stoppt**, wenn er einen Fehler macht (Hooks, Tests, Gates).

**Sechs Schichten.** **Kontext** ist nach Ladezeitpunkt geschichtet: eine kurze, permanente Root-`CLAUDE.md`, bedingte `rules`, die pfadabhängig aktiviert werden, `.agents/*.md` für Personas und Positionierung — eine Regel, die als **Routing-Tabelle** zu Skills fungiert, die nur bei Bedarf geöffnet werden. **Skills** (etwa dreißig) entstehen bei der dritten Wiederholung; am kosteneffizientesten sind jene, die eine **dateiübergreifende Prozedur** abdecken. **Tools** delegieren das Deterministische: IDE-MCP, **GitNexus**, das das Repository als Graph indiziert, um den Blast Radius einer Änderung zu messen — *"das eigentliche Problem ist nicht die Geschwindigkeit, sondern das Erkennen aller Nebenwirkungen."* **Leitplanken** sind ausführbar: vom Harness ausgelöste Hooks, **Architekturtests**, die die CI brechen, und **`ast-grep`**, um eine Architekturentscheidung in eine Lint-Regel zu verwandeln. Die **Fabrik** erzwingt ein Quality Gate, von dem der Deployment-Job abhängt (`needs:`), mit fünf Teststufen. Der **Produktprozess** beginnt bei einer nummerierten Spec, eingerahmt von einem Skill zum Verfassen **und einem Skill zum Abschließen** — *"ohne ihn werden Specs innerhalb von sechs Monaten obsolet"* — ausgeliefert in Stufen hinter einem Feature Flag.

**Das Prinzip.** *"Was wichtig ist, muss ausführbar sein. Eine Anweisung wird 'meistens' befolgt … Ein Hook oder ein Test wird immer befolgt."*

**Die offengelegten Einschränkungen.** Die Obsoleszenz einer Regel ist nicht messbar; eine Boyscout-Regel erzeugt endlose Sessions; Skills werden mangels Packaging von Projekt zu Projekt kopiert. Und das abschließende Eingeständnis: *"Ich werde in den Implementierungsphasen immer weniger nützlich"*, hin- und hergerissen zwischen der Effizienz der Fabrik und *"dem Risiko, das Wissen zu verlieren."*

## GrapheDeConnaissance

- Hugo Lassiège —publie→ Mon usine logicielle à l'heure de l'IA (DOCUMENT, 0.98)
- Hugo Lassiège —a_créé→ Bloggrify (TECHNOLOGIE, 0.93)
- Hugo Lassiège —a_créé→ Writizzy (TECHNOLOGIE, 0.93)
- Hugo Lassiège —affirme_que→ ce qui compte doit être exécutable : une consigne est suivie la plupart du temps, un hook ou un test est suivi tout le temps (CITATION, 0.97)
- test d'architecture —surpasse→ une rule de contexte, parce qu'il ne peut pas être contourné (AFFIRMATION, 0.95)
- context engineering —s_oppose_à→ vibe coding (METHODOLOGIE, 0.95)
- Hugo Lassiège —affirme_que→ même sans écrire le code, l'humain en reste responsable et doit en garder le contrôle (CITATION, 0.95)
- Hugo Lassiège —recommande→ expliciter ses propres contraintes plutôt que demander à une IA d'écrire du code de qualité (AFFIRMATION, 0.95)
- usine logicielle —est_basé_sur→ trois questions : ce que l'agent sait, ce qu'il fait de façon déterministe, ce qui l'arrête quand il se trompe (AFFIRMATION, 0.94)
- contexte permanent —permet→ d'indexer les skills sans les charger, le contenu n'étant ouvert qu'au besoin (AFFIRMATION, 0.92)
- skill —est_instance_de→ procédure écrite une fois et rejouée à l'identique, créée dès la troisième répétition (AFFIRMATION, 0.94)
- GitNexus —permet→ de mesurer le rayon d'explosion d'une modification et d'en détecter tous les effets de bord (AFFIRMATION, 0.94)
- graphe de code —surpasse→ le grep de nom de fonction pour retrouver un flux d'exécution (AFFIRMATION, 0.9)
- hooks —fait_partie_de→ harness de l'agent (CONCEPT, 0.94)
- ast-grep —permet→ de transformer une décision d'architecture en règle de lint (AFFIRMATION, 0.93)
- quality gate —permet→ d'empêcher tout déploiement non validé, via une dépendance du job de déploiement au job de qualité (AFFIRMATION, 0.95)
- clôture de spec —résout→ l'obsolescence des specs, qui deviennent périmées en six mois sans elle (AFFIRMATION, 0.93)
- feature flag —permet→ de livrer une spec par étapes et d'éviter les longues sessions dont la qualité se dégrade (AFFIRMATION, 0.9)
- Unleash —s_applique_à→ l'activation et la désactivation de fonctionnalités sans redéploiement (AFFIRMATION, 0.9)
- Hugo Lassiège —affirme_que→ rien ne permet de mesurer si une ancienne rule est devenue obsolète (AFFIRMATION, 0.93)
- règle d'amélioration continue —s_oppose_à→ la terminaison d'une session, en produisant des sessions sans fin (AFFIRMATION, 0.88)
- Hugo Lassiège —affirme_que→ l'efficacité croissante de l'usine logicielle s'accompagne d'un risque de perdre la connaissance du code (CITATION, 0.94)
- skills et MCP repris de l'extérieur —s_oppose_à→ la sécurité de la chaîne, en constituant des dépendances vectrices d'attaques (AFFIRMATION, 0.9)
- qualité logicielle —est_basé_sur→ les quatre risques de Marty Cagan — valeur, utilisabilité, faisabilité, viabilité — au-delà de la production de code (AFFIRMATION, 0.92)
- sous-agents —s_applique_à→ les tâches à forte lecture et faible décision, rendant une conclusion plutôt qu'un dump de fichiers (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/de/fiches/lassiege-usine-logicielle-heure-ia-2026-07-28/