# 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 kündigt sie selbst so an: *„Das wird eher eine Referenzseite als ein Artikel sein“*, gedacht für seine eigene Ressourcenseite. **Thema**: eine erschöpfende, werkzeuggestü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) in **kontinuierlicher Auslieferung in Produktion**. **Vorab getroffene Unterscheidung**: Dies ist kein **vibe coding** im Sinne von Karpathy (Experimentieren, sich treiben lassen), sondern **context engineering** — *„den gesamten notwendigen Kontext zum richtigen Zeitpunkt 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 Werkzeug-Set beantwortet drei Fragen**, und das ist das am besten wiederverwendbare Lese-Raster des Textes: *„Was weiß der Agent?“* (Kontext, Gedächtnis, Code-Graph) — *„Was kann er deterministisch, ohne zu improvisieren?“* (Skills, Prozeduren) — *„Was stoppt ihn, wenn er einen Fehler macht?“* (Hooks, Architekturtests, Qualitäts-Gates). **Sechs im Detail beschriebene Schichten**: (1) **Kontext** — Wurzel-`CLAUDE.md` + themenbezogene `.claude/rules/*.md`, bedingt geladen über `paths:` + `.agents/*.md` für nicht-technische Belange (Personas, Positionierung, Tonalität); (2) **Skills** — rund dreißig, Existenzkriterium *„wenn ich dasselbe ein drittes Mal erkläre“*; (3) **Tools** — JetBrains-IDE-MCP, **GitNexus** (Code-Graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK-Filter-Wrapper, Sentry, schreibgeschützte Datenbank; (4) **ausführbare Leitplanken** — Harness-Hooks, **Architekturtests**, Pattern-Linting (**ast-grep** für Architekturentscheidungen, nicht nur ESLint); (5) **Fabrik** — blockierendes Qualitäts-Gate mit `needs:` auf dem Qualitäts-Job, fünf Teststufen; (6) **Produktprozess** — nummerierte Specs mit einem Skill zum Verfassen **und einem Skill zum Abschließen**, Design in Claude Design, gestufte Auslieferung hinter Feature-Flags, Unterscheidung zwischen **Feature Flipping** (Unleash) und **Gating** (Kundenvertrag). **Die Regel, die alles zusammenfasst**: *„Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt … Ein Hook oder ein Test wird immer befolgt.“* **Eine Seltenheit für dieses Genre**: ein Abschnitt „Zu verbessern“, der vier gelebte Einschränkungen offenlegt — die **Unmöglichkeit, die Veralterung einer Regel zu messen** (*„Ich habe keine Möglichkeit zu wissen, ob eine alte Regel obsolet geworden ist“*), das **Kaninchenloch**, das durch eine Boyscout-Regel entsteht, das **Fehlen einer Paketierung** von 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 immer effizientere Fabrik zu haben, und dem Risiko, 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, Subagenten, Delegation, MCP, JetBrains, GitNexus, Code-Graph, impact, Wirkungsradius, detect_changes, Ausführungsfluss, Claude-mem, persistentes Gedächtnis, RTK, Ausgabefilterung, Sentry, schreibgeschützte Datenbank, ausführbare Leitplanken, Hooks, Harness, Architekturtests, Open-Source-Grenze, Pattern-Linting, ast-grep, ESLint, typecheck, blockierendes Qualitäts-Gate, GitHub Actions, needs, Teststufen, Wegwerf-Container, 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-Veralterung, Kaninchenloch, boyscout, Skill-Paketierung, 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 ausgewiesen — *„Das wird eher eine Referenzseite als ein Artikel sein, und ich werde sie auf der Ressourcenseite der Site referenzieren.“* Das 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 eine Referenzkonfiguration suchen, um sie mit der eigenen zu vergleichen.

**Stil**: eine **Architektur in nummerierten Schichten** (1 bis 6), jede eröffnet durch ihre Funktion, dicht **tabellarisch** — die Seite enthält rund zehn zweispaltige Tabellen (Datei/Inhalt, Familie/was sie kodieren, Auslöser/Wirkung, Stufe/Abdeckung, Bedarf/Mechanismus). Es ist ein **technisches Datenblatt**, keine Demonstration: Die Tabellen tragen die Information, die Prosa trägt die Begründung. Echte, unverfälschte Konfigurationsauszüge (eine vollständige `rule` mit ihrer `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. **Zurückhaltung hinsichtlich der Reichweite der Regeln.** *„Eine Einschränkung ist spezifisch für ein Projekt und eine Person. Es geht nicht um Software-Qualität im engeren Sinne.“* Der Autor weigert sich ausdrücklich, seine Konventionen als universelle Best Practices darzustellen — selten in einem Genre, das schnell ins Präskriptive kippt.
2. **Ehrliche Selbsteinschätzung der Werkzeuge.** Zu Claude-mem: *„ehrlich gesagt habe ich einige Mühe, die negative oder positive Wirkung zu messen. Ich habe noch nicht genug Abstand.“* Zum RTK-Wrapper: *„der Gewinn wird manchmal zunichtegemacht, weil Claude den Befehl zweimal ausführt.“* Zu Subagenten: *„ich benutze sie immer weniger.“* **Was man liest, ist das, was nicht funktioniert 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 immer effizientere Softwarefabrik zu haben, und dem Risiko, Wissen zu verlieren.“* Der Text endet mit einem offenen Problem, nicht mit einem Schluss.

**Charakteristische Wendungen**: *„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 bedeutet nichts. Man muss seine eigenen Einschränkungen explizit machen“*, *„Was zählt, muss ausführbar sein“*, *„Kontext ist ein Budget“*, *„1 Bug behoben, 10 produziert“*, *„Die Spec-Dokumentation stirbt, wenn ihr Abschluss nicht Teil des Prozesses ist“*, *„wenn ich dasselbe ein drittes Mal erkläre, wird es zum Skill“*, *„er lässt sich nicht umgehen, im Gegensatz zu einer Regel“*.

## Pense-betes

- **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.
- **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]].

## 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.“*

**Der Rahmen.** Dies ist kein **vibe coding** — was bei Karpathy Experimentieren bedeutete —, sondern **context engineering**: *„den gesamten notwendigen Kontext zum richtigen Zeitpunkt geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird.“* Verantwortung lässt sich nicht delegieren: *„Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich.“* Und Software-Qualität geht über Code hinaus — sie schließt Absicht und **Marty Cagans vier Risiken** ein.

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

**Sechs Schichten.** **Kontext** ist nach Ladezeitpunkt geschichtet: ein kurzes, permanentes `CLAUDE.md`, bedingte `rules`, die pfadabhängig aktiviert werden, `.agents/*.md` für Personas und Positionierung — eine Regel, die als **Routing-Tabelle** zu Skills dient, die nur bei Bedarf geöffnet werden. **Skills** (rund 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 Wirkungsradius einer Änderung zu messen — *„der eigentliche Punkt ist nicht 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 Qualitäts-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 veralten Specs innerhalb von sechs Monaten“* — und wird gestuft hinter Feature-Flags ausgeliefert.

**Das Prinzip.** *„Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt … Ein Hook oder ein Test wird immer befolgt.“*

**Die offengelegten Einschränkungen.** Die Veralterung einer Regel lässt sich nicht messen; eine Boyscout-Regel erzeugt endlose Sitzungen; Skills werden mangels Paketierung kopiert und eingefügt. 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, 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/