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

## Veille

Pagina di riferimento pubblicata su **eventuallycoding.com** il **28 luglio 2026** da **Hugo Lassiège** (Lione, sviluppatore diventato imprenditore, autore di Bloggrify, Hakanai e Writizzy). L'autore la inquadra così: *"Sarà più una pagina di riferimento che un articolo,"* pensata per la propria pagina delle risorse. **Argomento**: la descrizione esaustiva e strumentata di una **fabbrica del software solista** in cui *"il codice prodotto è ormai generato quasi al 100%,"* distribuita su diversi monorepo poliglotti (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **deployment continuo in produzione**. **Distinzione posta fin dall'inizio**: non si tratta di **vibe coding** nel senso di Karpathy (sperimentazione, lasciar fare) ma di context engineering — *"fornire tutto il contesto necessario, al momento giusto, affinché il software corrisponda a un'intenzione e sia sistematicamente controllato,"* con la frase che fonda la responsabilità: *"Anche se non scrivo il codice, ne sono responsabile e devo mantenerne il controllo."* **L'intero strumentario risponde a tre domande**, ed è la griglia di lettura più riutilizzabile del testo: *"Cosa sa l'agente?"* (contesto, memoria, code graph) — *"Cosa può fare in modo deterministico, senza improvvisare?"* (skills, procedure) — *"Cosa lo ferma quando sbaglia?"* (hooks, test di architettura, quality gate). **Sei livelli dettagliati**: (1) **contesto** — `CLAUDE.md` alla radice + `.claude/rules/*.md` tematici caricati condizionalmente tramite `paths:` + `.agents/*.md` per il contenuto non tecnico (persona, posizionamento, tono); (2) **skills** — una trentina, criterio di esistenza *"se spiego la stessa cosa una terza volta"*; (3) **strumenti** — MCP dell'IDE JetBrains, **GitNexus** (code graph: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper RTK di filtraggio dell'output, Sentry, database in sola lettura; (4) **guard-rail eseguibili** — hook dell'harness, **test di architettura**, pattern linting (**ast-grep** per le decisioni di architettura, non solo ESLint); (5) **fabbrica** — quality gate bloccante con `needs:` sul job di qualità, cinque fasi di test; (6) **processo di prodotto** — spec numerate con una skill di redazione **e una skill di chiusura**, design in Claude Design, delivery a tappe dietro un feature flag, distinzione tra **feature flipping** (Unleash) e **gating** (contratto cliente). **La regola che riassume tutto**: *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre'… Un hook o un test viene seguito sempre."* ⚠️ **Raro per il genere**: una sezione "Da migliorare" che espone quattro limiti vissuti — l'**impossibilità di misurare l'obsolescenza di una regola** (*"non ho modo di sapere se una vecchia regola sia diventata obsoleta"*), il **rabbit hole** creato da una regola boyscout, l'**assenza di packaging** delle skill tra progetti, e soprattutto l'ammissione di una tensione: *"divento sempre meno utile nelle fasi di implementazione,"* *"diviso tra la soddisfazione di avere una fabbrica sempre più efficiente e il rischio di perdere la conoscenza."*

## 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

fabbrica del software, context engineering, vibe coding, Karpathy, codice generato al 100%, sviluppatore solista, monorepo, poliglotta, Nuxt, Kotlin, deployment continuo, CLAUDE.md, regole, caricamento condizionale, paths, agents.md, personas, contesto permanente, budget di contesto, economia dei token, skills, procedura rieseguibile, sub-agent, delega, MCP, JetBrains, GitNexus, code graph, impact, raggio d'impatto, detect_changes, flusso di esecuzione, Claude-mem, memoria persistente, RTK, filtraggio dell'output, Sentry, database in sola lettura, guard-rail eseguibili, hooks, harness, test di architettura, confine open source, pattern linting, ast-grep, ESLint, typecheck, quality gate bloccante, GitHub Actions, needs, fasi di test, container usa e getta, testcontainers, end-to-end, processo di prodotto, spec numerata, chiusura della spec, Claude Design, mockup, feature flag, Unleash, feature flipping, gating, trunk-based, Marty Cagan, quattro rischi, obsolescenza delle regole, rabbit hole, boyscout, packaging delle skill, perdita della conoscenza, 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

**Profilo**: una **pagina di riferimento tecnica**, presentata come tale — *"Sarà più una pagina di riferimento che un articolo, e la linkerò dalla pagina delle risorse del sito."* Registro di un **praticante solista** che documenta la propria postazione di lavoro: né thought leadership, né case study aziendale, né tutorial. Pubblico: sviluppatori che già strumentano agenti e cercano un setup di riferimento da confrontare con il proprio.

**Stile**: **architettura a strati numerati** (da 1 a 6), ciascuno aperto dalla propria funzione, densamente **tabellare** — la pagina contiene una decina di tabelle a due colonne (file/contenuto, famiglia/cosa codificano, trigger/effetto, fase/copertura, esigenza/meccanismo). È una **scheda tecnica**, non una dimostrazione: le tabelle portano l'informazione, la prosa porta il ragionamento. Estratti di configurazione reali e non rifiniti (una `rule` completa con il suo frontmatter `paths:` e la sua tabella di instradamento verso nove skill, lo schema ASCII della pipeline CI, il contenuto di `boyscout.md`).

**Tre tratti che distinguono il testo dalla letteratura circostante**:

1. **Modestia sulla portata delle regole.** *"Un vincolo è specifico a un progetto e a una persona. Non è una questione di qualità del software in senso stretto."* L'autore rifiuta esplicitamente di presentare le proprie convenzioni come best practice universali — raro in un genere che scivola rapidamente verso il prescrittivo.
2. **Autovalutazione onesta degli strumenti.** Su Claude-mem: *"onestamente faccio fatica a misurare l'impatto negativo o positivo. Non ho ancora abbastanza prospettiva."* Sul wrapper RTK: *"il guadagno viene talvolta annullato perché Claude esegue il comando due volte."* Sui sub-agent: *"li uso sempre meno."* **Il lettore scopre cosa non funziona, o non funziona più.**
3. **L'ammissione finale, irrisolta.** *"Divento sempre meno utile nelle fasi di implementazione,"* *"è al limite dell'inquietante e più rigoroso del 99% degli esseri umani,"* *"diviso tra la soddisfazione di avere una fabbrica del software sempre più efficiente e il rischio di perdere la conoscenza."* Il testo si chiude su un problema aperto, non su una conclusione.

**Frasi distintive**: *"Anche se non scrivo il codice, ne sono responsabile,"* *"Non serve a nulla dire a un'IA di scrivere codice di qualità, non ha senso. Bisogna esplicitare i propri vincoli,"* *"Ciò che conta deve essere eseguibile,"* *"Il contesto è un budget,"* *"1 bug corretto, 10 introdotti,"* *"La documentazione delle spec muore se la sua chiusura non fa parte del processo,"* *"se spiego la stessa cosa una terza volta, diventa una skill,"* *"non può essere aggirato, a differenza di una regola."*

## Pense-betes

- **⭐ La griglia delle tre domande — l'insegnamento più riutilizzabile**: tutto lo strumentario risponde a *"Cosa **sa** l'agente?"* (contesto, memoria, code graph), *"Cosa può fare in modo **deterministico**, senza improvvisare?"* (skills, procedure), *"Cosa lo **ferma** quando sbaglia?"* (hook, test di architettura, quality gate). **Griglia di audit istantanea**: applicata a qualsiasi setup agentico, rivela in tre minuti quale delle tre è vuota. Quasi sempre è la terza.
- **⭐⭐ Il principio guida, da memorizzare alla lettera**: *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre', ma può essere dimenticata. Un hook o un test viene seguito sempre."* Formulato in modo ancora più netto altrove a proposito dei test di architettura: *"non può essere aggirato, **a differenza di una regola**."* → **Una regola è un'intenzione, un test è una garanzia.** È la stessa tesi dell'anello di vincoli in [[sfeir-code-review-anneau-contraintes-2026-07-30]] (pubblicato due giorni dopo) e dell'harness in [[osmani-agent-harness-engineering-2026-04-19]], ma **dimostrata su un setup reale e solista**, non enunciata come dottrina.
- **Esplicitamente contro il vibe coding**: *"Il vibe coding come definito da Karpathy era sperimentazione e lasciar fare. Qui parlerò di context engineering."* E la conseguente clausola di responsabilità: *"Anche se non scrivo il codice, ne sono responsabile e devo mantenerne il controllo."* Cfr. [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]].
- **La qualità del software non è la qualità del codice**: include l'**intenzione** (perché, per chi) e i **quattro rischi di Marty Cagan** — *Value, Usability, Feasibility, Viability* — oltre a prestazioni e affidabilità. È ciò che giustifica il livello 6 (processo di prodotto) e spiega perché una fabbrica del software puramente tecnica manca il punto.
- **Livello 1 — il contesto, e la mossa da copiare**: tre livelli separati per **momento di caricamento**. `CLAUDE.md` alla radice (architettura, convenzioni trasversali, indice delle spec) → permanente e **breve**; `.claude/rules/*.md` → **condizionale**, attivato da un frontmatter `paths:` (la regola Kotlin si carica solo quando si tocca `api/**/*`); `.agents/*.md` → contesto **non tecnico** (posizionamento di prodotto, persona, tono). ⭐ **La regola, vista per intero, è una tabella di instradamento**: non contiene le procedure, elenca nove skill con il compito che attiva ciascuna, da aprire solo quando serve. *"Se l'IA non sta facendo una modifica dello schema, non ha senso aprire la skill db-migration."* → **Il contesto permanente porta l'indice, non il contenuto.**
- **⭐ Un vincolo a lungo termine codificato come contesto *e* come test** — il miglior esempio del testo: l'autore prevede di rendere open source parte del codice. La regola *"il codice destinato all'open source non deve mai dipendere da codice proprietario"* è **scritta nelle regole** *e* **verificata da un test di architettura** (nessun file sul lato "open" fa riferimento al lato "proprietario"; ogni file di produzione appartiene all'uno o all'altro). *"Scrivere un vincolo futuro nel contesto evita di pagarne il prezzo con una riscrittura più tardi."* → **Una decisione che non esiste ancora può già essere garantita meccanicamente.**
- **La frase che uccide il prompt magico**: *"Non serve a nulla dire a un'IA di 'scrivere codice di qualità', non ha senso. Bisogna esplicitare i propri vincoli."* Accompagnata da una rara onestà: *"Un vincolo è specifico a un progetto e a una persona… Usare i feature flag non è meglio né peggio, è solo una mia preferenza."*
- **Livello 2 — le skill**: *"una procedura scritta una volta, rieseguita identicamente."* **Criterio di esistenza: la terza ripetizione.** Una trentina, suddivise in sei famiglie (backend, frontend, dati, ciclo di prodotto, operazioni/runbook, scrittura). Due lezioni: le skill di **"procedura multi-file"** sono le più redditizie (*"aggiungere un blocco all'editor di contenuti tocca tre superfici di rendering; senza una skill, l'agente ne dimentica sistematicamente una"*), e le skill di **"documentazione aggiornata"** sono critiche su codice in rapida evoluzione. ⚠️ Sfumatura operativa: *"Questo caricamento automatico a volte può fallire. In quel caso, bisogna chiedere esplicitamente di usare la skill."* Cfr. [[shihipar-claude-code-lessons-building-skills-2026-06-03]], [[agent-skills-anthropic-2025-10-16]], [[vincent-superpowers-agentic-skills-framework-github-2026-04-02]].
- **I sub-agent, in declino**: riservati a compiti *"che generano molta lettura senza molta decisione"* (audit, esplorazione ampia, redazione di documentazione) — *"consumano il proprio contesto e restituiscono una conclusione, non un dump di file."* Ma: *"li uso sempre meno, i modelli recenti fanno da soli una delega abbastanza mirata."* **Segnale di evoluzione**: una pratica di strumentazione resa in parte obsoleta dal modello.
- **⭐ Livello 3 — GitNexus, lo strumento più interessante del setup**: il repository viene indicizzato come un **grafo** (simboli, relazioni, flussi di esecuzione), il che permette `impact(symbol)` **prima** di modificare (raggio d'impatto, chiamanti, livello di rischio), `detect_changes()` **prima** di committare (*"ho toccato solo quello che intendevo toccare?"*), cercare un **flusso di esecuzione** invece di fare grep sul nome di una funzione, e rinominare **tramite il call graph** invece del find-and-replace. E la giustificazione, che conta più dello strumento in sé: *"Il vero problema non è la velocità, è **rilevare tutti gli effetti collaterali** di una modifica."* → ripresa nella regola n°4: *"Misurare gli impatti prima e dopo la modifica. Vogliamo evitare l'effetto '1 bug corretto, 10 introdotti'."* **Da confrontare con il contesto strutturato a code-graph rispetto al RAG vettoriale** — la stessa famiglia di argomentazione del risultato di Compare the Market citato in [[sfeir-code-review-anneau-contraintes-2026-07-30]].
- **MCP, con una riserva sul costo**: *"cerco di evitare gli MCP che consumano più contesto, ma ne ho comunque alcuni"* — IDE JetBrains (build, inspection, refactoring, ricerca indicizzata), GitNexus, servizi di business (pagamento, monitoraggio), database, browser. **L'MCP è trattato come una spesa di contesto da giustificare**, non come un dato di fatto.
- **Livello 4 — gli hook: la definizione che conta**: *"script attivati dall'**harness** dell'agente, non dall'agente stesso."* Due usi in produzione: prima di una chiamata shell, **rifiutare la build nativa** e reindirizzare verso la build dell'IDE (più veloce, errori strutturati) spiegando il fallback; dopo la scrittura di un file, **eseguire il formatter/linter**. Altri usi citati: bloccare le modifiche ai file generati, richiedere un test per ogni nuovo modulo, vietare un pattern pericoloso.
- **⭐ Pattern linting — la distinzione da tenere a mente**: **ESLint** per la sintassi, **`ast-grep` per le *decisioni di architettura*** (esempio: *vietare qualsiasi chiamata `fetch` che aggiri il client OpenAPI*), **typecheck** per la tipizzazione. → **Una decisione di architettura può diventare una regola di lint.** È l'anello mancante tra "abbiamo deciso" e "viene applicato", e costa poche righe.
- **Livello 5 — il gate**: `push su main → quality gate (lint → pattern lint → typecheck → test) → build immagine docker → push sul registry → webhook di deployment`. **Il punto strutturale**: il job di deployment ha un **`needs:` sul job di qualità**. *"Niente va in produzione senza passare il gate. È essenziale come regola generale, ancora di più per il codice prodotto automaticamente."* Cinque fasi di test: unitari (in modo massiccio), integrazione **con container usa e getta** (*"database e broker reali, niente mock"*), architettura, componenti front-end, **end-to-end solo sui percorsi critici**. Cfr. [[williams-adlc-3-tests-are-the-spec-2026-06-12]] e [[williams-adlc-2-two-human-gates-2026-06-12]].
- **Livello 6 — il processo di prodotto, e il passaggio che tutti dimenticano**: spec numerate (una per dominio funzionale, indicizzate nel contesto permanente) incorniciate da **due** skill — una per **redigere** la spec e il suo piano, **una per chiuderla** aggiornandola con ciò che è stato effettivamente realizzato. *"Senza di essa, le spec diventano obsolete entro sei mesi,"* e come regola finale: *"La documentazione delle spec muore se la sua chiusura non fa parte del processo."* ⭐ **La chiusura è la parte del ciclo di documentazione che quasi mai esiste altrove.**
- **Regola anti-allucinazione per le spec**: *"Se una spec non è chiara o è incoerente con il sistema esistente, l'agente deve chiedere, non indovinare."* Una singola riga di contesto che affronta la modalità di fallimento più costosa dello sviluppo agentico.
- **La consegna a tappe, e la sua motivazione**: la spec è pensata per essere consegnata a tappe protette da un feature flag, *"mi permette di fare diverse piccole sessioni di implementazione invece di una grande sessione, che tende a degradare in qualità una volta che si riempie troppo."* → **Qui, la scomposizione del prodotto è dettata dal degrado del contesto lungo**, non dalla gestione di progetto. Distinzione utile: **feature flipping** (Unleash — attivare/disattivare senza ridistribuire: rollout, kill switch, manutenzione) contro **gating** (tabella di configurazione + servizio — restrizione per contratto cliente o piano). Due meccanismi, due esigenze, e una skill affinché gli agenti non li confondano.
- **Da dove iniziare (ordine indicato, ed è un buon ordine)**: (1) **prima di tutto il quality gate**, se non esiste già; (2) un `CLAUDE.md` leggero che descrive l'essenziale e **il perché**; (3) regole aggiunte in modo incrementale per i pattern di architettura importanti; (4) skill non appena una procedura si ripete; (5) CLI e MCP per gli strumenti principali. ⚠️ **Avvertenza di sicurezza**: *"qualsiasi skill, MCP o codice importato dall'esterno deve essere esaminato con attenzione. Sono dipendenze che possono costituire vettori di attacco."* Da confrontare con la superficie d'attacco agentica descritta in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]].
- **⚠️ Limiti vissuti — la sezione che rende credibile la pagina**: 1. **L'obsolescenza di una regola non è misurabile.** *"A metà 2025, 'scrivi un test per ogni nuovo servizio' aveva senso. Oggi è rumore e Claude lo fa naturalmente… non ho modo di misurare o sapere se una vecchia regola sia diventata obsoleta."* → **Il contesto accumulato decade al ritmo dei modelli, e nulla traccia questo decadimento.** È la vera lacuna metodologica del settore, e qui viene nominata senza soluzione. 2. **Il rabbit hole.** Una regola `boyscout.md` (*"lasciare sempre il codice un po' migliore… segnalarmi i miglioramenti"*) produce *"sessioni infinite"* e sovraccarico cognitivo. Correzione prevista: instradare questi rilevamenti in una **lista TODO** e spostare la manutenzione in un workflow separato e parzialmente automatizzato. → **Una buona istruzione di miglioramento continuo diventa un generatore di deriva quando l'agente non si ferma da solo.** 3. **Nessun packaging.** Skill e regole vengono **copiate e incollate da un progetto all'altro**, a volte dipendenti dalla macchina. Manca: un modo per pacchettizzarle per il deployment e **centralizzare la manutenzione**. 4. **Dipendenza da Claude**, giudicata un *"rischio moderato"* (*"tutto l'ecosistema sta salendo di livello"*), con l'interesse a testare modelli open-weight — bloccato dall'hardware. E **l'IDE è diventato poco adatto**: *"uso ancora IntelliJ ma non lo trovo più adatto alla nostra epoca. Non ho ancora visto un'alternativa interessante."*
- **⭐⭐ L'ammissione di fondo, da citare alla lettera**: *"Le ultime versioni di Opus sono sempre più autonome… È al limite dell'inquietante, e più rigoroso del 99% degli esseri umani. Diciamocelo, divento sempre meno utile nelle fasi di implementazione, ma non voglio perdere il controllo del codice prodotto. Sono diviso tra la soddisfazione di avere una fabbrica del software sempre più efficiente e **il rischio di perdere la conoscenza**."* → È esattamente il **comprehension debt** di [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]], espresso dall'interno da qualcuno che ha costruito l'harness più completo possibile **e osserva che l'harness non risolve questo problema specifico**. Il setup garantisce che il codice sia corretto; non garantisce che l'essere umano lo capisca ancora. **La domanda aperta del testo**: *"devo trovare un modo per verificare a posteriori le scelte progettuali, per fare mio il risultato."*
- **⚠️ Portata da non sopravvalutare**: un setup **solista**, su **prodotti personali**, con un unico decisore. Nessun coordinamento multi-sviluppatore, nessuna peer review, nessun vincolo di compliance o audit — il livello "chi convalida" è occupato da una sola persona, che è anche l'autrice delle regole. Ciò che si trasferisce a un contesto aziendale: **la griglia delle tre domande, il principio dell'eseguibilità, la chiusura delle spec, il pattern linting**. Ciò che non si trasferisce tale e quale: l'assenza totale di qualsiasi gate umano diverso da se stessi.
- **Meta / correlati**: una dimostrazione pratica di [[osmani-agent-harness-engineering-2026-04-19]] e un cugino diretto di [[sfeir-code-review-anneau-contraintes-2026-07-30]] (pubblicato 2 giorni dopo, stessa tesi: la qualità vive nell'anello di vincoli, non nel codice); lo stesso vocabolario di "fabbrica del software" di [[wescale-usine-logicielle-augmentee-juge-strategique-2026-05-03]], ma su scala individuale; si contrappone al vibe coding di [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]]; converge con [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]] sull'esplicitazione dei vincoli; da leggere insieme a [[shihipar-claude-code-lessons-building-skills-2026-06-03]] sulle skill e [[williams-adlc-3-tests-are-the-spec-2026-06-12]] sui test.

## RésuméDe400mots

Pagina di riferimento pubblicata il **28 luglio 2026** da **Hugo Lassiège** su eventuallycoding.com, che documenta la sua **fabbrica del software solista** per prodotti in produzione (Hakanai, Writizzy, Bloggrify) il cui *"codice prodotto è ormai generato quasi al 100%."*

**L'inquadramento.** Non si tratta di **vibe coding** — che, per Karpathy, era sperimentazione — ma di context engineering: *"fornire tutto il contesto necessario, al momento giusto, affinché il software corrisponda a un'intenzione e sia sistematicamente controllato."* La responsabilità non viene delegata: *"Anche se non scrivo il codice, ne sono responsabile."* E la qualità del software va oltre il codice — include l'intenzione e i **quattro rischi di Marty Cagan**.

**La griglia.** Tutto lo strumentario risponde a tre domande: cosa **sa** l'agente (contesto, memoria, code graph), cosa può fare in modo **deterministico** (skills), e **cosa lo ferma** quando sbaglia (hook, test, gate).

**Sei livelli.** Il **contesto** è organizzato a strati secondo il momento di caricamento: un `CLAUDE.md` permanente e breve alla radice, `rules` condizionali attivate per percorso, `.agents/*.md` per persona e posizionamento — una regola che funge da **tabella di instradamento** verso le skill, da aprire solo quando serve. Le **skill** (una trentina) nascono alla terza ripetizione; le più redditizie sono quelle che coprono una **procedura multi-file**. Gli **strumenti** delegano il deterministico: MCP dell'IDE, **GitNexus**, che indicizza il repository come un grafo per misurare il raggio d'impatto di una modifica — *"il vero problema non è la velocità, è rilevare tutti gli effetti collaterali."* I **guard-rail** sono eseguibili: hook attivati dall'harness, **test di architettura** che bloccano la CI, e **`ast-grep`** per trasformare una decisione di architettura in una regola di lint. La **fabbrica** impone un quality gate da cui dipende il job di deployment (`needs:`), con cinque fasi di test. Il **processo di prodotto** parte da una spec numerata, incorniciata da una skill di redazione **e una skill di chiusura** — *"senza di essa, le spec diventano obsolete entro sei mesi"* — consegnata a tappe dietro un feature flag.

**Il principio.** *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre'… Un hook o un test viene seguito sempre."*

**I limiti, esposti.** L'obsolescenza di una regola non è misurabile; una regola boyscout produce sessioni infinite; le skill vengono copiate e incollate per mancanza di packaging. E l'ammissione finale: *"divento sempre meno utile nelle fasi di implementazione,"* diviso tra l'efficienza della fabbrica e *"il rischio di perdere la conoscenza."*

## 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/it/fiches/lassiege-usine-logicielle-heure-ia-2026-07-28/