Come lavoro con l'AI nello sviluppo: il mio metodo

Lavoro con l'AI seguendo un filo conduttore. Nella mia esperienza, chiedere a Claude o a ChatGPT una cosa alla volta produce pezzi che funzionano da soli e non si tengono insieme. Il mio metodo decide invece cosa chiedere, a quale modello, con quale contesto, e come verificare il risultato.

L'AI ha cambiato il mio modo di lavorare da sviluppatore Drupal freelance, e il metodo resta mio. Ogni lavoro passa da quattro passaggi che decido io: analizzo il problema, lo scompongo, delego, verifico. Le deleghe arrivano a un server che fa da nucleo remoto: smista i task fra i modelli, accende gli ambienti su richiesta e ricorda le decisioni prese. Qui racconto come è fatto, e cosa dicono le misure.

Qual è il filo conduttore quando lavoro con l'AI?

Il filo conduttore sono quattro passaggi, che seguo sempre nello stesso ordine:

1. Analizzo il problema. Raccolgo in un brief tutte le informazioni: cosa va fatto, perché,

con quali vincoli.

1. Definisco il flusso scomponendo il problema in task atomici. Scrivo la lista completa dei

passi e uso l'AI per controllarla: coprire tutti i passi, trovare le lacune funzionali che la lista lascia scoperte, tenere il filo fra una sessione e l'altra. Il lavoro nasce da una issue su GitLab, il codice passa da un change di OpenSpec che fissa la specifica, e le scelte di architettura finiscono in un ADR.

1. Delego al sistema. Ogni task va al modello adatto, con una specifica precisa.
2. Verifico e decido. Rileggo tutto quello che torna, prima del push. Il giudizio finale resta

mio.

L'AI lavora dentro questi passaggi e mi toglie il volume di lavoro: scrivere, rileggere log, controllare testi. La direzione resta mia.

Che ruolo ha il server nel flusso?

Il server è il centro di tutto il flusso: nel tempo è diventato un sistema di microservizi che accompagnano lo sviluppo e centralizzano le attività comuni: oggi conta 55 container, divisi in 21 progetti Docker Compose. Sulla stessa macchina girano GitLab con la CI, Ollama con i modelli locali, ctx-memory con la memoria delle decisioni, il registro delle skill e gli ambienti di sviluppo dei progetti.

Centralizzare tiene tutto allineato. Le skill stanno in un registro sul server, e il sistema propaga gli aggiornamenti in automatico a ogni macchina da cui lavoro. Alcune girano direttamente sul server, accanto a Ollama, e restituiscono a Claude solo l'esito: è così che funzionano i controlli sui testi e una parte della pipeline SEO. Nel sistema ci sono anche una gestione a parte per i dati sensibili e la condensazione del testo con Caveman, che accorcia i messaggi prima che arrivino a Claude.

L'hardware è un AMD Ryzen 9 9950X con 32 thread e 60 GB di RAM, senza scheda grafica: per ora basta CPU e tanta RAM.

Come smista il lavoro il server?

Con una tabella di regole scritta nelle istruzioni globali di Claude Code, che vale in ogni sessione senza doverla ripetere. Un server MCP riceve le deleghe e le manda a destinazione:

Opus, il modello che guida la sessione, progetta e rivede, e il volume di codice lo scrivono gli altri. Il corpo dei file delegati resta fuori dal suo contesto: Opus manda la specifica e riceve il percorso del file o il diff, e il contenuto lo legge solo quando lo rivede.

Una regola riguarda Ollama spento. Svegliarlo costa del tempo, una volta per sessione, e il sistema lo considera un costo da pagare, perché vale per tutto il lavoro che segue. Si rinuncia alla delega solo quando Ollama è irraggiungibile.

Come si accendono gli ambienti solo quando servono?

Gli ambienti si accendono da soli grazie a Traefik e Sablier. Traefik riceve le richieste per tutti i servizi del server, e Sablier tiene spenti i container finché qualcuno li chiama, li avvia alla prima richiesta e li ferma dopo un periodo di inattività, di norma un quarto d'ora. Dei 55 container, 34 funzionano così, in 13 gruppi: gli ambienti dei siti, ctx-memory, gli strumenti AI, perfino il browser che uso per generare le immagini. Mentre scrivo questo articolo, di quei 34 ne girano 4.

Il risultato è che ogni ambiente è pronto quando lo apro, e la macchina lascia la memoria a Ollama quando gli ambienti dormono.

Come evito di rispiegare il contesto a ogni sessione?

Con ctx-memory, il mio sistema RAG di attività e decisioni, costruito su Drupal 11 e Typesense. Le issue dicono cosa è stato fatto, mentre ctx-memory tiene il perché, con la prova accanto, e lo condivide fra le sessioni di Claude. Così una sessione nuova parte dal contesto già definito, invece di ridefinire attività e decisioni da capo.

Lo uso sempre da Claude. Un server MCP espone tre strumenti, cerca, leggi e cattura, e una skill dedicata insegna all'agente come usarli: quando apro una sessione su un progetto, l'agente recupera le decisioni che lo riguardano e lavora con quel contesto davanti. Quando decido qualcosa, la stessa skill la scrive nel grafo. Due hook catturano da soli: ogni proposal.md di un change OpenSpec entra come evidenza con la decisione che dichiara, e ogni ADR committato entra con il permalink al commit.

Sotto, Drupal fa da database del grafo: contesti, decisioni, evidenze e relazioni sono entità Drupal su PostgreSQL, con revisioni e permessi. Typesense, collegato con Search API, le indicizza per la ricerca, e l'indice sta in RAM e si ricostruisce da zero dal database. Oggi il grafo conta circa 180 decisioni e 440 evidenze. Quattro regole lo tengono affidabile:

1. una decisione catturata nasce sempre «proposta», e la conferma solo io;
2. una decisione si conferma solo con almeno un'evidenza che punta a una fonte stabile;
3. il grafo è append-only: una decisione cambia solo con una nuova che sostituisce la vecchia;
4. ogni riga dichiara chi l'ha scritta, una persona o un modello.

Quanto lavoro passa dal modello locale?

Il sistema registra ogni delega dall'8 luglio, con i token che il modello locale legge e quelli che scrive. Contando solo il lavoro con Claude, cioè skill e tool MCP, e lasciando fuori le altre applicazioni che usano Ollama sul server:

I token letti sono i log, i file e i testi da controllare che altrimenti avrebbe letto Claude, insieme alle istruzioni che servono al modello locale. Quelli scritti sono il risultato che avrebbe dovuto produrre Claude. Negli stessi 30 giorni ho lanciato anche 201 esecutori Claude, di cui 170 Sonnet.

Il risparmio reale è più ampio, perché ogni file che Claude legge resta nel suo contesto per i turni successivi. La sessione in cui ho scritto questo articolo, con dentro anche altri contenuti e quattro merge request, ha prodotto circa 578.000 token di output nel thread principale e ne ha letti circa 316 milioni, in gran parte dalla cache. Il dato che conta per me è pratico: con la delega arrivo a fine settimana, prima arrivavo a metà.

Quanto rende un modello locale su CPU?

Qwen3 su CPU chiude un lavoro in meno di un minuto: una skill eseguita sul server impiega in media 49 secondi, la scrittura di un file 63.

Le guide che si trovano in rete sconsigliano Qwen3-Coder su CPU, con risposte che arrivano dopo minuti. La differenza sta nel modello: i due Qwen3 che uso sono 30B-A3B, mixture-of-experts da 30 miliardi di parametri, di cui circa 3 miliardi lavorano per ogni token, quantizzati a 4 bit in 18 GB. Per questo rispondono alla velocità di un modello molto più piccolo. Questi tempi valgono per questa macchina e per lavori brevi, come un file o il riassunto di un log.

Anche l'affidabilità regge: su oltre 800 deleghe registrate dall'8 luglio i tentativi a vuoto sono stati 7, meno dell'1%. Il sistema li conta a parte, fuori dalle statistiche dei risparmi.

Come verifico quello che torna dalle deleghe?

Rileggo ogni consegna prima del push, perché delegare la stesura lascia a me la responsabilità del risultato. In una giornata di lavoro ho annotato i difetti di ogni consegna delegata, e ognuna ne aveva almeno uno: un'opzione --quiet che lasciava passare l'output, un comm lanciato su file non ordinati, commenti di esempio copiati da un modulo del core, un verdetto dichiarato senza una prova a sostegno. Sono difetti piccoli, e passano proprio per questo. Skill e script della pipeline fanno controlli automatici prima del merge: identificatori in inglese, traduzioni, configurazione esportata.

I testi seguono la stessa regola. Ogni testo del sito passa da llm-detect, una skill che misura quanto un testo porta le impronte di un modello linguistico: calchi dall'inglese, antitesi a effetto, formule ricorrenti. Un esito rosso blocca la pubblicazione, e il verde vale come soglia minima: in agosto un revisore umano bilingue ha riconosciuto in pochi minuti un testo che la pipeline aveva promosso, e da lì sono nati nuovi marker e quattro controlli da fare a mano. Anche questo articolo è passato da lì.

Fonti

Tutte le misure sono state lette il 1 ottobre 2026 sul server dove gira il sistema.

• Claude Code (si apre in una nuova scheda), Anthropic. Fonte primaria.
• Model Context Protocol (si apre in una nuova scheda). Fonte primaria.
• Ollama (si apre in una nuova scheda) e Qwen3-Coder (si apre in una nuova scheda), modelli 30B-A3B. Fonte primaria.
• Local LLM setup con Ollama e Qwen (si apre in una nuova scheda), Conduction: tempi di Qwen3-Coder senza GPU dedicata.
• Sablier (si apre in una nuova scheda) e Traefik (si apre in una nuova scheda). Fonte primaria.
• Typesense (si apre in una nuova scheda) e Search API Typesense (si apre in una nuova scheda). Fonte primaria.
• OpenSpec (si apre in una nuova scheda). Fonte primaria.
• Architecture Decision Records (si apre in una nuova scheda). Fonte primaria.
• Registro delle deleghe di Ollama dall'8 luglio, statistiche della sessione, inventario dei

container e della configurazione di Sablier, istruzioni globali di Claude Code, registro delle skill, contesti e decisioni di ctx-memory. Rilevamento dell'autore.