Qwen2.5-Coder è diventato il mio revisore fisso per le code review che faccio in homelab. Avevo bisogno di un modello che capisse il codice senza che ogni snippet finisse fuori dalla mia rete, perché tanti progetti che mi passano davanti contengono pezzi di configurazione, token di servizio e hostname interni che non voglio veder uscire. La variante 14B su una scheda con 16 GB di VRAM regge una sessione di mezza giornata senza farmi pensare alla latenza, ed è ormai la mia scelta principale per qualsiasi review che tocchi file di una certa lunghezza.

Il modello è rilasciato da Alibaba con licenza Apache 2.0, quindi posso usarlo liberamente anche per lavoro a pagamento. Lo tengo su un mini server Debian 12 headless, raggiungibile via SSH dal mio desktop. Ollama gira come servizio systemd, si lega di default su 127.0.0.1:11434, e su quella stessa macchina ho opencode installato. Quando devo fare review entro in SSH, apro tmux e lavoro lì dentro per tutto il tempo necessario.

I parametri che mi interessano sono pochi: 14B di parametri, finestra di contesto base 32k token (la spingo a 16k effettivi via Modelfile per non sprecare VRAM), quantizzazione Q4_K_M predefinita di Ollama. Il knowledge cutoff è metà 2024 e si sente quando arrivano librerie nuove, ma per code review su codice mio non è un problema.

Setup base con Ollama

Su Debian 12 lo script ufficiale di Ollama tira giù tutto in un colpo, compreso il service unit systemd.


curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
ollama pull qwen2.5-coder:14b
ollama run qwen2.5-coder:14b

Con 8 GB di VRAM la 14B fatica davvero, e in quel caso scendo alla 7B che resta comunque dignitosa per la review riga per riga. Quando devo dargli in pasto file lunghi, parto dal Modelfile esistente e ne creo una variante con un contesto più ampio.


ollama show qwen2.5-coder:14b --modelfile > /tmp/qwen-coder.Modelfile

Apro il file con il mio editor, aggiungo PARAMETER num_ctx 16384 e ricostruisco la variante con ollama create qwen-coder-long -f /tmp/qwen-coder.Modelfile. La uso solo quando serve davvero, perché la finestra grande mangia VRAM e mi costringe a tenere meno modelli caricati in parallelo.

Setup avanzato con opencode

opencode è una TUI agentica che si appoggia a un provider OpenAI-compatible, e per le code review fa esattamente quello che mi serve: monta la working directory, mi permette di passare file in contesto con un comando, e mantiene la cronologia della sessione su disco. Ollama da tempo espone un endpoint compatibile su /v1, quindi basta dichiararlo come provider locale dentro ~/.config/opencode/opencode.json.


{
  "provider": {
    "ollama-local": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "apiKey": "ollama",
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen2.5-coder:14b": { "name": "Qwen 2.5 Coder 14B" }
      }
    }
  }
}

Salvato il file, mi sposto nella cartella del progetto e lancio la sessione agentica.


cd ~/Documenti/progetti/router-config
opencode . --model ollama-local/qwen2.5-coder:14b

A quel punto sono nella TUI con la working directory già montata, senza wrapper intermedi e senza dovermi inventare integrazioni a parte.

Un esempio di sessione reale

Martedì pomeriggio, verso le 16, dovevo rivedere un retry decorator scritto in Python da una persona del team che gestisce una pipeline ETL. Il decorator avvolgeva chiamate HTTP verso un endpoint che ogni tanto restituiva 502 transitori, e la sensazione era che facesse troppi retry e troppo rapidi, saturando il rate limit a valle. Ho aperto la cartella del progetto in opencode, ho chiesto a Qwen2.5-Coder di leggere il file retry.py e di valutare se il backoff fosse implementato correttamente.

La risposta è arrivata in una trentina di secondi e ha colto due cose che mi erano sfuggite: il jitter era applicato solo al primo tentativo (per un errore di indentazione del randint dentro il loop), e il decorator non distingueva tra eccezioni di rete e errori HTTP 4xx, finendo per ritentare anche su 401 e 403. Ho chiesto una proposta di refactoring tenendo le firme pubbliche identiche e ho ottenuto una versione con backoff esponenziale corretto, jitter su ogni tentativo, e una whitelist esplicita di status code retriabili. Il merge request è uscito in serata.

Cosa fa bene

Sul codice scritto in linguaggi mainstream (Python, TypeScript, Go, bash, SQL) la qualità della review è solida. Coglie pattern di concorrenza fragile, vede dove manca la gestione delle eccezioni, suggerisce refactor di funzioni che fanno troppe cose. Sui Dockerfile e sui file Ansible è meno brillante ma sempre utile, soprattutto per stanare uso di latest come tag e privilegi superflui nei container.

Cosa fa meno bene

Su librerie uscite dopo la metà del 2024 inventa firme che sembrano plausibili ma non esistono, quindi le sue proposte vanno sempre verificate contro la documentazione vera. La 14B in Q4 ogni tanto perde il filo su file molto lunghi anche con num_ctx alzato, e la latenza per risposta lunga non è paragonabile a quella di un servizio cloud su acceleratori dedicati: con prompt da 6k token la prima parola arriva in 4-5 secondi.

Privacy: tutto resta sul mio host

Qwen2.5-Coder gira interamente dentro il mio server: nessun provider terzo coinvolto, nessun upload, nessuna telemetria di default. Ollama si lega su 127.0.0.1:11434 e non espone nulla all’esterno. Gli unici log sono in ~/.ollama/logs/, posso cancellarli quando voglio con un rm, e non c’è alcuna policy esterna da rileggere a ogni aggiornamento. Rispetto ai modelli cloud, dove ogni snippet passa per i server di chi offre il servizio (con retention variabile e, in qualche caso, riuso per training se non si fa opt-out), qui la differenza è radicale: il codice non esce mai dal mio host. La licenza Apache 2.0 di Qwen 2.5 Coder mi lascia libero di usarlo anche in contesti professionali senza ulteriori vincoli.

In pratica

Qwen2.5-Coder 14B è il modello che apro quando la review tocca codice mio o di progetti che gestisco direttamente. Per ragionamento esplicito su scelte architetturali passo a DeepSeek-R1 7B, per domande generiche e veloci sul laptop mi appoggio a qwen3:8b, e per risposte brevi e multimodali sul Mac Mini tengo Gemma3 4B. La scelta dipende da quanto contesto serve, da quanto tempo voglio aspettare, e da quale macchina è accesa in quel momento.

Immagine generata con Cloudflare Workers AI / FLUX.

Articolo originale su rpi.temporiti.net