Claude Code ha abbassato così tanto la barriera di costruzione che oggi chiunque, in trenta minuti, può aggiungere una nuova skill, un plugin, un MCP server o un’automazione al proprio workspace. La velocità è eccitante, ma porta con sé un effetto collaterale di cui si parla poco: il rischio di accumulare pezzi che non si vogliono più togliere.
Il fenomeno ha un nome accademico preciso. Si chiama effetto Ikea, ed è un bias cognitivo descritto in uno studio del 2012 pubblicato sul Journal of Consumer Psychology. Applicato ai sistemi AI, e in particolare a Claude Code, spiega perché molti utenti si ritrovano dopo qualche mese con un workspace pieno di skill che non usano e con la sensazione vaga di non essere più in controllo.
In questo articolo vediamo cos’è l’effetto Ikea, perché Claude Code è un terreno particolarmente fertile, cosa significa “rumore” in un sistema AI e quale framework permette di tagliare ciò che pesa senza buttare via ciò che serve.
Cos’è l’effetto Ikea?
L’effetto Ikea è un bias cognitivo descritto in modo formale da Michael Norton, Daniel Mochon e Dan Ariely in uno studio pubblicato nel 2012 sul Journal of Consumer Psychology. Il principio è semplice: le persone attribuiscono un valore più alto agli oggetti che hanno costruito da sé rispetto a oggetti identici costruiti da altri, anche quando il risultato finale è oggettivamente peggiore.
Il nome richiama il colosso svedese del mobile auto-assemblato perché lo studio originale usava proprio mobili Ikea come stimolo sperimentale. Una libreria montata a mano vale, agli occhi di chi l’ha montata, di più di una libreria identica già assemblata.
Il bias non riguarda solo i mobili. Vale per qualsiasi sistema in cui si investe tempo e fatica: codice, processi, contenuti e, oggi, anche i workspace AI personalizzati.
Perché Claude Code amplifica l’effetto Ikea?
Claude Code è uno degli ambienti più potenti per chi vuole costruirsi un assistente AI cucito addosso. In pochi click si possono creare skill personalizzate, installare plugin, collegare server MCP esterni, impostare job ricorrenti con launchd, riorganizzare la struttura del workspace.
Ogni operazione è veloce, gratificante e sembra produttiva. Il problema arriva dopo. Ogni skill in più diventa un mobile che hai montato tu. E nessuno smonta un mobile che ha montato.
Dopo qualche mese il workspace tipo ha decine di skill, ognuna costruita con cura e dedicata a un caso d’uso specifico. Alcune vengono usate ogni giorno. Altre sono state aperte due volte e poi più. Eppure tutte sembrano necessarie, perché chi le ha costruite ricorda lo sforzo che è costato metterle in piedi.
Il ciclo che alimenta l’effetto Ikea
Quattro passi che si auto-rinforzano se non interrotti
Costruisci
Skill, plugin, MCP, hook. Pochi minuti, gratificazione immediata.
Ti affezioni
L’effort speso diventa proxy del valore percepito (effetto Ikea).
Accumuli rumore
Costo cognitivo, token sprecati, debito di manutenzione che cresce.
Smetti di usarla
La skill smette di servirti ma resta nel workspace, indelebile.
Cosa si intende per rumore in un workspace AI?
Esiste un termine tecnico che descrive il prezzo dell’effetto Ikea applicato a un workspace AI: il rumore. Nel contesto dei sistemi di intelligenza artificiale, rumore vuol dire tutto ciò che esiste nel contesto ma non serve a portare a termine il task corrente.
Tradotto in pratica, su Claude Code rumore significa:
- file di contesto vecchi che nessuno legge più
- cartelle organizzate con buone intenzioni che restano vuote
- skill duplicate o sovrapposte
- automazioni dormienti
- documentazione obsoleta dentro i CLAUDE.md di progetto
Tutto questo materiale sembra innocuo. Sta lì zitto. In realtà ha tre costi misurabili.
| Tipo di costo | Cosa succede | Effetto pratico |
|---|---|---|
| Cognitivo | L’utente non ricorda più cosa ha costruito e perché | Decisioni peggiori, esitazione, scelta della skill sbagliata |
| Computazionale | Claude scansiona file inutili a ogni sessione | Token consumati, attenzione dispersa, risposte peggiori |
| Manutenzione | Ogni skill in più è una skill da aggiornare e debuggare | Tempo perso su elementi che non producono valore reale |
Quali sono i segnali che il workspace sta accumulando rumore?
Tre indicatori pratici dicono se un workspace Claude Code è già passato dalla parte sbagliata.
Il primo segnale è la difficoltà a ricordare. Aprendo l’elenco delle skill installate, se una su cinque ha un nome di cui non si ricorda più l’uso, c’è un problema.
Il secondo segnale è la sovrapposizione. Quando ci sono due skill che fanno cose simili e l’utente non ricorda quando usare l’una o l’altra, esiste una duplicazione invisibile. Quasi sempre entrambe vengono usate poco.
Il terzo segnale è l’ansia da pulizia. Ogni volta che si pensa di rimuovere qualcosa, parte il dubbio “e se poi mi serve”. Senza un dato che dica quanto serve davvero, si finisce per non rimuovere mai nulla.
2 newsletter a settimana con riflessioni, dietro le quinte e anteprime su AI nel lavoro. Niente news flash, solo angoli che non trovi sul blog.
Iscriviti gratis su Substack →Come funziona il framework anti-Ikea: misurare prima di tagliare
L’unico modo onesto per uscire dall’effetto Ikea è sostituire la sensazione con il dato. In pratica significa strumentare il workspace per sapere, con precisione, quante volte ogni skill viene effettivamente utilizzata.
Workflow anti-Ikea in 3 step
Dato continuo, decisione regolare, rumore sotto controllo
Log automatico
Hook PostToolUse intercetta ogni attivazione skill.
Output: JSONL con timestamp, nome, contesto
Report periodico
Aggrega gli eventi del log, conta utilizzi per skill.
Cadenza settimanale o mensile in base al volume
Decisione
Per ogni skill poco usata: archivia, fondi o osserva.
Output: workspace pulito, decisioni basate sui dati
il ciclo si ripete a cadenza fissa
Il sistema base ha tre componenti.
Un log di utilizzo. Ogni volta che una skill viene attivata, si registra un evento (nome skill, data, contesto) in un file di log strutturato. Su Claude Code questo si può ottenere con un hook PostToolUse che intercetta l’attivazione delle skill.
Un report periodico. Una volta al mese (o ogni settimana, dipende dal volume) si genera un riassunto: quante volte ciascuna skill è stata richiamata negli ultimi trenta giorni. Le skill con zero utilizzi salgono in cima alla lista.
Una decisione ricorrente. Sulla base del report, alla fine di ogni periodo si prendono tre decisioni possibili per ogni skill poco usata: eliminarla, integrarla dentro una skill più ampia, oppure darle un’ultima settimana di osservazione.
Cosa fare con le skill che non si usano
Cosa fare con ogni skill
Matrice uso × valore. Decisione basata sul dato, non sull’attaccamento.
Valuta o stagionalizza
Uso basso + valore alto. Skill che servono solo in certi momenti dell’anno.
Es: skill fine anno fiscale
Tieni e amplifica
Uso alto + valore alto. Skill core del workspace, da documentare e tenere in evidenza.
Es: pubblica-su-wordpress
Archivia
Uso basso + valore basso. Sposta in _archivio/ invece di cancellare.
Es: prove fatte mesi fa
Fondi con altre
Uso alto ma valore basso singolarmente. Skill sovrapposte, accorpa in una più ampia.
Es: tre skill scrittura → una
Una volta che i dati sono sul tavolo, l’azione segue tre strade pulite.
Le skill con utilizzo zero negli ultimi tre mesi vanno archiviate. Non cancellate, ma spostate in una cartella separata (per esempio una sotto-cartella _archivio). Se serviranno di nuovo, sono lì. Nel frattempo non fanno rumore nel contesto attivo.
Le skill con utilizzo basso ma valore alto, come una skill di compliance che si attiva solo a fine anno, vanno taggate come stagionali. Si possono escludere dal contesto di default e includere solo nel periodo rilevante.
Le skill con utilizzo medio ma sovrapposte ad altre vanno fuse. Una sola skill più ampia, con parametri configurabili, gestisce più casi d’uso che prima erano separati. Il risultato è meno superficie da mantenere e una scelta più semplice nel momento dell’uso.
Perché funziona misurare invece di intuire
Misurare invece di intuire risolve due problemi insieme. Toglie l’attaccamento emotivo dalla decisione, perché non si sta più giudicando una skill che si è costruita ma si sta leggendo un numero. E introduce un’azione regolare che impedisce al rumore di accumularsi indisturbato.
L’effetto Ikea esiste perché il cervello tratta la fatica come un proxy del valore. Un report mensile è il modo più semplice per separare i due. La fatica resta, ma il valore lo certifica il dato.
Costruire è gratificante, smontare no
Per questo i workspace AI tendono a crescere senza pulizia, e per questo l’effetto Ikea applicato a Claude Code produce sistemi che sembrano potenti ma sono soprattutto pesanti.
L’antidoto non è costruire di meno. È costruire e poi misurare. Ogni skill, plugin o automazione deve giustificare la sua esistenza con un numero. Quelle che lo fanno restano e crescono. Quelle che non lo fanno vengono potate.
Un sistema AI ben curato non è quello con più pezzi. È quello in cui ogni pezzo, dopo trenta giorni di prova, è ancora vivo.
FAQ
Cos’è l’effetto Ikea?
Risposta: l’effetto Ikea è un bias cognitivo descritto da Norton, Mochon e Ariely nel 2012. Le persone attribuiscono un valore più alto agli oggetti che hanno costruito personalmente rispetto a oggetti identici prodotti da altri, anche quando il risultato finale è oggettivamente peggiore.
Perché si parla di effetto Ikea con Claude Code?
Risposta: perché Claude Code permette di costruire skill, plugin e automazioni in pochi minuti. La velocità di costruzione amplifica il bias: gli utenti accumulano molti pezzi e si rifiutano di rimuoverli, anche quando smettono di usarli.
Cos’è il rumore in un sistema AI?
Risposta: è tutto ciò che esiste nel workspace ma non serve al task corrente: file vecchi, skill dormienti, cartelle vuote, automazioni inattive. Consuma contesto, complica le decisioni e abbassa la qualità delle risposte del modello.
Come si misura l’uso delle skill su Claude Code?
Risposta: si configura un hook che logga ogni attivazione di skill in un file strutturato. Un report periodico (settimanale o mensile) sintetizza i dati: le skill con zero utilizzi vanno archiviate, quelle sovrapposte vanno fuse, quelle stagionali vanno taggate.
Devo cancellare le skill che non uso?
Risposta: no. Vanno archiviate in una cartella separata. Cancellare definitivamente rende difficile recuperarle in futuro. Archiviarle le toglie dal contesto attivo senza perderle, lasciando l’opzione di riattivarle quando serve.
Ogni quanto fare audit delle skill?
Risposta: dipende dal volume di costruzione. Per chi installa o crea skill quasi ogni settimana, un audit mensile è il minimo. Per workspace più stabili, ogni tre mesi è sufficiente. L’importante è che la cadenza sia fissa e non a sentimento.
Fonti
- Norton, M. I., Mochon, D., Ariely, D. (2012), “The IKEA Effect: When Labor Leads to Love”, Journal of Consumer Psychology, 22(3), 453-460. DOI: 10.1016/j.jcps.2011.08.002
- Discussione community r/ClaudeCode “Inherited a 3-month old repo from a Vibe Engineer” (aprile 2026, 3.940 upvotes, 455 commenti): caso reale di repo Claude Code bloated, riscritto da zero. Vedi su Reddit
- Documentazione ufficiale Claude Code hooks: docs.claude.com/claude-code/hooks
Continua altrove
Articolo scritto con il supporto dell’intelligenza artificiale, sotto la mia supervisione. La responsabilità di quello che leggi è mia.
Divulgo l’intelligenza artificiale con un approccio pragmatico. Su questo blog, su Substack, YouTube, WhatsApp e nel mio podcast Cronache di Intelligenza Artificiale racconto come uso davvero l’AI nel lavoro quotidiano: produttività per professionisti, ecosistema Google AI (Gemini, NotebookLM, AI Studio), Claude Cowork e Claude Code. Non racconto l’AI come magia: non ti dà il talento che non hai, ma può moltiplicare quello che sai già fare.