Mon usine logicielle à l'heure de l'IA

Punti chiave

1. 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.
2. 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]].