# 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 presenta così: *"Sarà più una pagina di riferimento che un articolo,"* pensata per la propria pagina di risorse. **Argomento**: una descrizione esaustiva e strumentata di una **software factory solitaria** in cui *"il codice prodotto è ormai quasi al 100% generato,"* su più monorepo poliglotti (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **deployment continuo in produzione**. **Distinzione posta in apertura**: non si tratta di **vibe coding** nel senso di Karpathy (sperimentazione, lasciarsi trasportare) 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, grafo del codice) — *"Cosa sa fare in modo deterministico, senza improvvisare?"* (skill, procedure) — *"Cosa lo ferma quando sbaglia?"* (hook, test di architettura, quality gate). **Sei livelli dettagliati**: (1) **contesto** — `CLAUDE.md` radice + `.claude/rules/*.md` tematici caricati condizionatamente via `paths:` + `.agents/*.md` per le questioni non tecniche (persona, posizionamento, tono); (2) **skill** — una trentina, criterio di esistenza *"se spiego la stessa cosa una terza volta"*; (3) **strumenti** — MCP dell'IDE JetBrains, **GitNexus** (grafo del codice: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper di filtraggio RTK, Sentry, database in sola lettura; (4) **guardrail eseguibili** — hook dell'harness, **test di architettura**, linting di pattern (**ast-grep** per le decisioni architetturali, non solo ESLint); (5) **factory** — quality gate bloccante con `needs:` sul job di qualità, cinque stadi di test; (6) **processo di prodotto** — spec numerate con una skill di redazione **e una skill di chiusura**, design in Claude Design, consegna a stadi dietro 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."* **Una rarità 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, la **mancanza di packaging** per le skill tra progetti, e soprattutto l'ammissione di tensione: *"Divento sempre meno utile nelle fasi di implementazione,"* *"combattuto tra la soddisfazione di avere una factory sempre più efficiente e il rischio di perdere 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

software factory, context engineering, vibe coding, Karpathy, codice generato al 100%, sviluppatore solitario, monorepo, poliglotta, Nuxt, Kotlin, deployment continuo, CLAUDE.md, regole, caricamento condizionale, paths, agents.md, personas, contesto permanente, budget di contesto, economia dei token, skill, procedura ripetibile, sub-agenti, delega, MCP, JetBrains, GitNexus, grafo del codice, impatto, raggio d'impatto, detect_changes, flusso di esecuzione, Claude-mem, memoria persistente, RTK, filtraggio dell'output, Sentry, database in sola lettura, guardrail eseguibili, hook, harness, test di architettura, confine open source, linting di pattern, ast-grep, ESLint, typecheck, quality gate bloccante, GitHub Actions, needs, stadi 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 di 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**, riconosciuta come tale — *"Sarà più una pagina di riferimento che un articolo, e la citerò nella pagina delle risorse del sito."* Il registro di un **praticante solitario** che documenta la propria postazione di lavoro: né thought leadership, né caso di studio aziendale, né tutorial. Pubblico: sviluppatori che già strumentano agenti e cercano una configurazione di riferimento con cui confrontare la propria.

**Stile**: un'**architettura in livelli numerati** (da 1 a 6), ciascuno aperto dalla propria funzione, densamente **tabulata** — la pagina contiene una decina di tabelle a due colonne (file/contenuto, famiglia/cosa codificano, trigger/effetto, stadio/copertura, bisogno/meccanismo). È una **scheda tecnica di riferimento**, non una dimostrazione: le tabelle portano l'informazione, la prosa porta il ragionamento. Estratti di configurazione reali e non edulcorati (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 nel prescrittivo.
2. **Autovalutazione onesta degli strumenti.** Su Claude-mem: *"onestamente, faccio fatica a misurare l'impatto negativo o positivo. Non ho ancora abbastanza recul."* Sul wrapper RTK: *"il guadagno viene talvolta annullato perché Claude esegue il comando due volte."* Sui sub-agenti: *"li uso sempre meno."* **Ciò che si legge è ciò che 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 umani,"* *"combattuto tra la soddisfazione di avere una software factory sempre più efficiente e il rischio di perdere 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 niente dire a un'IA di scrivere codice di qualità — non significa nulla. Bisogna rendere espliciti i propri vincoli"*, *"Ciò che conta deve essere eseguibile"*, *"Il contesto è un budget"*, *"1 bug corretto, 10 prodotti"*, *"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

- **Data / fonte**: **28 luglio 2026**, eventuallycoding.com, **Hugo Lassiège**. Una pagina di riferimento riconosciuta come tale, che descrive il setup con cui l'autore gestisce da solo i propri prodotti in produzione.
- **Inquadramento chiave**: non si tratta di vibe coding — *"Il vibe coding come definito da Karpathy era sperimentazione e lasciarsi trasportare. Qui parlerò di context engineering."* Con la clausola di responsabilità: *"Anche se non scrivo il codice, ne sono responsabile e devo mantenerne il controllo."* ### La griglia delle tre domande L'intero strumentario risponde a tre domande, ed è il contributo più riutilizzabile del testo: | Domanda | Cosa risponde | |---|---| | Cosa **sa** l'agente? | contesto, memoria, grafo del codice | | Cosa sa fare in modo **deterministico**? | skill, procedure | | Cosa lo **ferma** quando sbaglia? | hook, test di architettura, quality gate | Posta di fronte a un setup agentico, rivela quale delle tre è vuota. Principio guida associato: *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre,' ma può essere dimenticata. Un hook o un test viene seguito sempre."* E sui test di architettura: *"non può essere aggirato, a differenza di una regola."* ### I sei livelli | # | Livello | Contenuto | |---|--------|---------| | 1 | **Contesto** | `CLAUDE.md` radice, breve e permanente (architettura, convenzioni, indice delle spec); `.claude/rules/*.md` condizionali attivate via frontmatter `paths:`; `.agents/*.md` per le questioni non tecniche (posizionamento, persona, tono) | | 2 | **Skill** | una trentina, sei famiglie; criterio di esistenza: la terza ripetizione | | 3 | **Strumenti** | MCP dell'IDE JetBrains, **GitNexus** (grafo del codice), Claude-mem, Sentry, database in sola lettura | | 4 | **Guardrail** | hook dell'harness, test di architettura, linting di pattern (`ast-grep`) | | 5 | **Factory** | quality gate bloccante, cinque stadi di test | | 6 | **Processo di prodotto** | spec numerate, skill di redazione **e** skill di chiusura, feature flag | **Livello 1** — il contesto permanente porta l'indice, non il contenuto: la regola, vista per intero, è una tabella di instradamento che elenca nove skill accanto al compito che le attiva. *"Se l'IA non sta facendo una modifica di schema, non ha senso aprire la skill db-migration."* **Livello 2** — 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."* Sfumatura: *"Questo caricamento automatico a volte può fallire. In quel caso, bisogna chiedere esplicitamente di usare la skill."* I sub-agenti sono in declino, riservati a compiti *"che generano molta lettura senza molte decisioni"* — *"li uso sempre meno; gli agenti recenti delegano da soli in modo piuttosto preciso."* **Livello 3** — GitNexus indicizza il repository come un grafo e fornisce `impact(symbol)` prima di modificare, `detect_changes()` prima di committare, una ricerca per flusso di esecuzione anziché grep, e il rinominare tramite il grafo delle chiamate. La giustificazione dell'autore: *"Il punto vero non è la velocità, è rilevare tutti gli effetti collaterali di una modifica."* MCP è trattato come una spesa di contesto da giustificare: *"cerco di evitare gli MCP che consumano più contesto."* **Livello 4** — gli hook sono *"script attivati dall'harness dell'agente, non dall'agente stesso"*: rifiutare la build nativa e reindirizzare verso la build dell'IDE, eseguire il formatter dopo una scrittura. Distinzione nel linting: ESLint per la sintassi, **`ast-grep` per le decisioni architetturali** (vietare qualsiasi chiamata `fetch` che aggiri il client OpenAPI), typecheck per la tipizzazione. **Livello 5** — `push su main → quality gate (lint → pattern lint → typecheck → test) → build immagine → registry → webhook di deployment`, con il job di deployment che porta un **`needs:` sul job di qualità**. Cinque stadi: unit, integrazione con container usa e getta (*"database e broker reali, niente mock"*), architettura, componenti front-end, end-to-end solo sui percorsi critici. **Livello 6** — spec inquadrate da due skill, una delle quali **di chiusura**, che aggiorna la spec con quanto effettivamente costruito: *"La documentazione delle spec muore se la sua chiusura non fa parte del processo."* Regola anti-allucinazione: *"Se una spec è vaga o incoerente con ciò che esiste, l'agente deve chiedere, non indovinare."* Consegna a stadi dietro feature flag, motivata dal degrado del contesto lungo — *"mi permette di fare più piccole sessioni di implementazione invece di una grande sessione, che tende a degradare in qualità."* Distinzione tra **feature flipping** (Unleash: rollout, kill switch) e **gating** (contratto cliente, piano). ### La mossa più istruttiva: un vincolo futuro già garantito 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**. *"Scrivere un vincolo futuro nel contesto evita di pagare una riscrittura più tardi."* ### Da dove iniziare, nell'ordine indicato 1. Prima il **quality gate**, se non esiste ancora. 2. Un `CLAUDE.md` leggero che descrive l'essenziale **e il perché**. 3. Regole aggiunte progressivamente per i pattern architetturali importanti. 4. Skill non appena una procedura si ripete. 5. CLI e MCP per gli strumenti principali. Avvertenza: *"qualsiasi skill, MCP o codice portato dall'esterno deve essere esaminato attentamente. Sono dipendenze che possono essere vettori di attacco."* ### I quattro limiti vissuti 1. **L'obsolescenza di una regola non si può misurare.** *"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."* 2. **Il rabbit hole.** Una regola `boyscout.md` produce *"sessioni infinite"* e sovraccarico cognitivo; una correzione allo studio consiste nell'instradare questi riscontri verso una lista TODO e spostare la manutenzione in un workflow separato. 3. **Nessun packaging.** Skill e regole vengono copiate e incollate da un progetto all'altro, a volte dipendenti dalla macchina. 4. **Dipendenza da Claude**, giudicata *"rischio moderato,"* e un IDE diventato inadatto: *"uso ancora IntelliJ, ma non lo trovo più adatto alla nostra epoca."* ### L'ammissione di fondo *"Le ultime versioni di Opus sono sempre più autonome… Diciamocelo francamente, divento sempre meno utile nelle fasi di implementazione, ma non voglio perdere il controllo del codice prodotto. Sono combattuto tra la soddisfazione di avere una software factory sempre più efficiente e il rischio di perdere conoscenza."* Il setup garantisce che il codice sia corretto; non garantisce che l'umano lo comprenda ancora. Domanda lasciata aperta: *"devo trovare un modo per rivedere i design a posteriori, per fare mio il risultato."* Stesso problema sollevato da [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]]. ### Ambito Un setup **solitario**, su prodotti personali, con un unico decisore: nessun coordinamento multi-sviluppatore, nessuna peer review, nessun vincolo di compliance. Ciò che si trasferisce a un contesto aziendale: la griglia delle tre domande, il principio dell'eseguibile, la chiusura delle spec e il pattern linting; ciò che non si trasferisce: l'assenza di qualsiasi gate umano diverso da sé stessi. Stessa tesi, enunciata come dottrina due giorni dopo, in [[sfeir-code-review-anneau-contraintes-2026-07-30]].

## RésuméDe400mots

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

**L'inquadramento.** Non si tratta di **vibe coding** — che, per Karpathy, significava 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 è delegabile: *"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.** L'intero strumentario risponde a tre domande: cosa **sa** l'agente (contesto, memoria, grafo del codice), cosa sa fare in modo **deterministico** (skill), e **cosa lo ferma** quando sbaglia (hook, test, gate).

**Sei livelli.** Il **contesto** è stratificato per momento di caricamento: un `CLAUDE.md` breve e permanente, `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 all'occorrenza. 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 punto vero non è la velocità, è rilevare tutti gli effetti collaterali."* I **guardrail** sono eseguibili: hook attivati dall'harness, **test di architettura** che fanno fallire la CI, e **`ast-grep`** per trasformare una decisione architetturale in una regola di lint. La **factory** impone un quality gate da cui dipende il job di deployment (`needs:`), con cinque stadi di test. Il **processo di prodotto** parte da una spec numerata, inquadrata da una skill di redazione **e una skill di chiusura** — *"senza di essa, le spec invecchiano male in sei mesi"* — consegnata a stadi dietro 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 si può misurare; 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,"* combattuto tra l'efficienza della factory e *"il rischio di perdere 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/