Quando un modello linguistico si trasforma da compagno di snippet a co-pilota di un’applicazione reale, il divario tra generazione di codice e senso architetturale diventa improvvisamente doloroso. È il racconto di uno sviluppatore che, dopo aver integrato Qwen3.6-27b nello sviluppo di un software commerciale da oltre 100.000 linee, si è trovato a combattere con un assistente capace di sfornare classi elefantiache, interfacce ipertrofiche e un disprezzo totale per l’automazione dei test. Non un bug occasionale, ma un pattern sistematico: l’LLM scrive quel tanto che basta a soddisfare la richiesta immediata, ignorando completamente la manutenibilità, la separazione delle responsabilità e qualsiasi best practice indispensabile per far crescere il codice senza che la complessità esploda.

La frustrazione del post originale non è isolata, ma segnala una crepa strutturale. I modelli come Qwen3.6-27b vengono addestrati prevalentemente su repository pubblici, dove la qualità architetturale è eterogenea e il contesto di sistema è assente: dominano funzioni brevi, script isolati, pull request che raramente mostrano l’evoluzione di un’intera codebase. L’inference locale – scelta spesso dettata da sovranità dei dati, controllo dei costi o vincoli di compliance – amplifica il problema, perché si perde il feedback implicito di piattaforme cloud dove il modello può attingere a contesti estesi o a meccanismi di retrieval-augmented generation già calibrati. In locale, il prompt è tutto, e se l’utente non specifica in modo ossessivo i vincoli architetturali, il sistema torna al suo minimo comune denominatore: scrivere codice funzionante ma strutturalmente fragile.

Il risultato è un paradosso per chi ha investito in hardware dedicato e stack self-hosted. Da un lato si guadagna privacy e prevedibilità dei costi operativi; dall’altro si genera un debito tecnico nascosto, fatto di classi «superuomo» che mischiano accesso ai dati, logica di business e presentazione, e di interfacce che crescono a dismisura a ogni iterazione. Il costo non è immediato: emerge settimane dopo, quando un cambio di requisiti obbliga a rifattorizzare un groviglio che nessun membro del team riesce più a decifrare. In termini di Total Cost of Ownership, il risparmio sulle API cloud rischia di essere eroso dal tempo speso a correggere, riscrivere e «addestrare» il modello a ricordare principi come il single responsibility o il dependency inversion.

L’appello dello sviluppatore per un set di file SKILL.md – documenti che inietterebbero conoscenza architetturale direttamente nel modello – è rivelatore. Segnala la necessità di un nuovo strato di ingegneria: se l’LLM non ha interiorizzato il design del software, qualcuno dovrà fornirglielo ogni volta, sotto forma di linee guida persistenti, prompt template o addirittura fine-tuning mirato. Per i team che gestiscono deployment on-premise, questo cambia il calcolo del TCO: non basta più dimensionare la GPU per contenere i pesi del modello; bisogna investire anche in pipeline di contesto che facciano da ponte tra le intenzioni dello sviluppatore e la capacità grezza dell’LLM. E non è un costo una tantum, perché l’architettura evolve con il progetto.

In controluce si legge una verità scomoda per l’intero ecosistema dei modelli aperti: la generazione di codice sta diventando una commodity, ma la progettazione del software resta una competenza che i dati di training non trasmettono facilmente. La distribuzione locale, che promette indipendenza e controllo, finisce per amplificare il divario, trasformando ogni sviluppatore in un formatore part-time del proprio assistente. La ricerca di SKILL.md non è solo la richiesta di un file; è il sintomo di un bisogno più ampio di strumenti che trasformino un modello linguistico in un vero compagno di progettazione, capace di vedere la foresta oltre il singolo albero.