Coding Models: enterprise & open-source

1. Cosa rende un modello buono per il coding

Non esiste un singolo numero. Un modello "buono per il coding" è quello che, sul tuo stack, dentro il tuo flusso, produce output che passano i tuoi test. Detto questo, alcune capacità sono trasversalmente importanti.

Capacità rilevanti

• Long context. Leggere file grandi, più file insieme, contesto di repo. Da 100k token in su è territorio utile; i modelli top arrivano a 1M+ token.
• Tool use / function calling. Chiamare funzioni esterne in modo affidabile (leggi file, esegui comando, interroga DB). Requisito per qualsiasi agente.
• Reasoning multi-step. Capacità di scomporre un problema e iterare. Cruciale per bug complessi e refactoring non banali.
• Fill-in-the-middle (FIM). Completare codice in mezzo a un file, non solo in fondo. Fondamentale per l'autocompletion interattiva.
• Instruction following. Rispettare vincoli (es. "niente nuove dipendenze", "mantieni questa firma pubblica"). I modelli specializzati spesso sono più "bravi" ma meno "ubbidienti".
• Multilingua sui linguaggi rari. Ottima performance su Python e JS è comune; Rust, Kotlin, SQL dialect specifici, COBOL sono dove i modelli si differenziano.

2. Modelli frontier (enterprise closed)

I modelli che oggi rappresentano lo stato dell'arte per coding agent reali. Attenzione: la classifica cambia ogni pochi mesi. I nomi che seguono sono le famiglie, non modelli singoli.

Claude (Anthropic)

Attualmente tra i più forti su task di coding end-to-end, specialmente quando richiedono ragionamento e uso di strumenti (leggere file, lanciare test). La famiglia Opus è la top-tier, Sonnet è il workhorse quotidiano, Haiku è il modello "fast" per volumi. È il motore di Claude Code (modulo 7).

• Punti di forza: coding agent, tool use, long context, rispetto delle istruzioni.
• Canali enterprise: Anthropic diretto con DPA UE, AWS Bedrock, GCP Vertex.
• Trade-off: costo per token superiore ai mid-tier di OpenAI, ma spesso meno iterazioni necessarie.

GPT (OpenAI) — serie 4/5 e o-series

La famiglia più generalmente disponibile, con integrazione nativa in Azure OpenAI (fondamentale per Blulink). La o-series è la linea reasoning, ottima per problemi difficili anche non di coding.

• Punti di forza: ecosistema, Azure OpenAI, tool use maturo, multimodalità.
• Canali enterprise: Azure OpenAI (tenant dedicato, data residency EU, SLA, SSO, audit log).
• Trade-off: historically meno "docile" nel seguire istruzioni rigide rispetto a Claude su task di coding puri, ma il gap si riduce continuamente.

Gemini (Google)

Contesto gigantesco (1M+ token), multimodalità forte, buona integrazione con Google Cloud. Storicamente più debole su agent tool use coding puro, in rapida crescita.

• Punti di forza: long context, multimodalità, Vertex AI.
• Canali enterprise: Vertex AI con data residency EU.

Quando sceglierne uno rispetto all'altro?

3. Modelli open-weight

I modelli "open" (peso dei parametri scaricabile) non sono ancora alla pari con i frontier closed per gli scenari agent-complex, ma coprono molti casi d'uso utili, specialmente a volumi alti o con vincoli di data sovereignty.

Principali famiglie

• Codestral / Mistral Large (Mistral, FR) — famiglia europea, forte su completamento e FIM, licenza permissiva per uso commerciale con caveat. Buona opzione EU.
• DeepSeek Coder — ottime prestazioni per taglia, rapporto qualità/costo alto, considera la provenienza e le policy aziendali sull'origine.
• Qwen Coder (Alibaba) — molto forte nei benchmark recenti, stesse considerazioni di provenienza.
• Llama 3/4 (Meta) — generalisti con capacità di coding buone dopo fine-tuning; base per molti modelli derivati.
• StarCoder 2 / BigCode — progetto open con governance trasparente su dataset e licenze. Rilevante quando serve rigore su provenance dei dati di training.
• Granite Code (IBM) — pensato per scenari enterprise, licenza permissiva, taglie modeste ma decorose.

Quando scegliere un open-weight

• Quando serve deploy on-prem o in tenant completamente privato.
• Quando il volume giustifica l'ammortamento dell'hardware.
• Quando serve fine-tuning su dataset proprietario che non può uscire.
• Per task ristretti e ben definiti (autocompletion su un linguaggio, generazione test, classificazione).

4. Benchmark: cosa dicono, cosa non dicono

I principali benchmark da conoscere

• HumanEval / MBPP — classici di generazione funzioni Python. Ormai saturi, utili solo per sanity check.
• LiveCodeBench — problemi di programmazione sempre nuovi per evitare contamination. Più indicativo di HumanEval per capacità "fresche".
• SWE-Bench / SWE-Bench Verified — il benchmark più vicino al lavoro reale: risolvere issue GitHub su progetti open source. Misura capacità agentiche end-to-end.
• Aider leaderboard — benchmark derivato dall'uso reale del tool Aider, misura anche la capacità di editing consistente di file esistenti.
• BigCodeBench — più ampio di HumanEval, più linguaggi e librerie reali.

Cosa NON dicono i benchmark

• Performance sul tuo stack e sulle tue convenzioni.
• Qualità dell'integrazione con gli strumenti di lavoro (editor, CI, PR).
• Stabilità in produzione: un modello benchmark-ottimo può essere flaky in uso reale.
• Costo totale di ownership per il tuo workflow.

La pratica matura: oltre ai benchmark pubblici, mantenere un eval interno con 30–100 prompt rappresentativi delle attività quotidiane di Blulink, e rieseguirlo periodicamente sui modelli candidati. Alcuni spunti di eval interno:

• "Genera test unitari per questa classe esistente."
• "Refactor di questo metodo rispettando la firma pubblica."
• "Trova il bug descritto in questa issue dato il codice del repo."
• "Scrivi le release notes in italiano a partire da questo changelog."
• "Implementa questa user story nel modulo X."

5. Integrazione in pipeline enterprise reali

Pattern 1: modello frontier in cloud per agenti interattivi

Il dev usa Claude Code o Copilot con modelli frontier (Claude, GPT) via tenant enterprise. L'uso interattivo non ha bisogno di volumi estremi: la qualità è prioritaria sul costo per call. Il modulo 7 entra nel dettaglio per Claude Code su Azure DevOps.

Pattern 2: modello mid-tier per pipeline CI

Job automatici (generazione release notes, triage issue, aggiornamento docs) vengono eseguiti da modelli mid-tier (meno costosi), con prompt standardizzati in repo. Il vantaggio è che i costi sono lineari e prevedibili, e non c'è utente umano in attesa.

Pattern 3: modello small/open per volumi alti

Classificazioni, estrazioni, autocompletion su un linguaggio specifico: scenari dove il volume giustifica l'ottimizzazione. Un modello piccolo (eventualmente fine-tuned) self-hosted o su tenant dedicato può abbattere i costi di un ordine di grandezza.

Pattern 4: router

Come anticipato nel modulo 3: una chiamata iniziale a un classificatore decide quale modello gestisce la richiesta. Complica l'architettura ma offre il miglior rapporto qualità/costo su prodotti maturi.