AI coding governabile con model routing

Per molti team il primo ciclo dell’AI coding è stato semplice: aprire Claude Code, Cursor o Copilot, chiedere più output e vedere cosa succede. In alcuni casi ha funzionato subito. Più prototipi, più fix, più branch, meno attesa tra idea e demo.

Il secondo ciclo è meno spettacolare, ma più importante. Se ogni task può usare un modello diverso, con costo, latenza, capacità e policy diverse, scegliere “l’AI” non basta più. Bisogna scegliere quale modello usare, quando, per quale lavoro e con quale livello di controllo.

Il 2 luglio 2026, The Pragmatic Engineer ha pubblicato un’analisi sullo smart model routing: router che scelgono il modello più adatto per task, costo, qualità o disponibilità. Il tema sembra tecnico, ma per chi costruisce prodotto è molto concreto. Quando l’AI entra nel delivery quotidiano, il routing diventa parte del sistema operativo del team.

Il costo non è solo token

La lettura più immediata del model routing è economica. Alcuni task non hanno bisogno di un modello frontier. Se il lavoro è semplice, ripetitivo o già ben specificato, un modello più economico può bastare. Se invece il task tocca architettura, dati, sicurezza o decisioni di prodotto, ha senso spendere di più.

Questa è una distinzione utile, ma incompleta. Il costo vero non è solo il prezzo dei token. È il tempo di review, il rischio di correggere output sbagliati, il rumore prodotto da una soluzione apparentemente corretta, la fatica di capire perché un modello ha preso una certa direzione.

Un router può ridurre il costo computazionale. Non decide da solo il costo organizzativo. Se un team manda task vaghi a un modello economico, poi passa ore a pulire il risultato, il risparmio è finto. Se usa sempre il modello più forte anche per modifiche banali, sta comprando sicurezza psicologica, non necessariamente qualità.

Per questo il routing vive accanto all’AI-assisted delivery e alla governance degli agenti per livello di autonomia. La scelta del modello è solo un controllo. Classe di task, profondità della review, permessi e fallback decidono se l’output può entrare nel prodotto.

Il routing richiede una tassonomia dei task

Per far funzionare il model routing serve una cosa poco glamour: classificare il lavoro. Non basta dire “bugfix”, “feature” o “refactor”. Bisogna capire che tipo di rischio porta quel cambiamento.

Un fix visuale isolato può stare in fast lane. Una modifica su permessi, billing, compensi, autenticazione o dati sensibili richiede un altro livello di review. Una spike può usare modelli diversi perché non entra subito in produzione. Una migrazione o un refactor condiviso ha bisogno di criteri più espliciti, perché il modello può produrre tanto codice plausibile e lasciare implicazioni distribuite nel sistema.

Qui il PM tecnico e l’engineering lead devono lavorare insieme. Il routing non è una decisione puramente infrastrutturale. È una decisione sul modo in cui il team protegge il prodotto mentre aumenta la velocità.

Il modello non sostituisce la review

Una tentazione naturale è usare il routing per automatizzare anche la fiducia: task semplice, modello economico, merge più veloce. Il rischio è confondere la scelta del modello con la qualità del risultato.

Un modello più forte non elimina la review. Un modello più economico non rende il task meno rischioso. La review resta il punto in cui il team decide se quell’output può diventare prodotto. Cambia però ciò che la review deve sapere: quale modello ha generato l’output, quale prompt o contesto aveva, quali vincoli erano espliciti, quali fallback sono stati usati.

Se questi elementi restano invisibili, il routing diventa una scatola nera. Il team vede solo una pull request e deve indovinare quanto fidarsi. È il contrario della governance: più automazione, meno spiegabilità.

Cosa decidere prima del router

Il model routing diventerà probabilmente normale negli strumenti di AI coding. Ha senso: i modelli sono troppi, i costi variano, le performance cambiano e nessun team vuole scegliere manualmente ogni volta.

Ma prima del router serve una domanda più semplice: quali task devono restare sotto controllo umano stretto, anche quando il modello sembra abbastanza bravo?

Questa domanda non rallenta il team. Lo protegge da una forma nuova di debito: output generato velocemente, accettato troppo presto, capito troppo tardi. La parte interessante dell’AI coding non è solo scrivere più codice. È costruire un sistema in cui il team sa ancora perché quel codice è stato scritto, quanto è rischioso e chi decide se può entrare nel prodotto.

Il routing può aiutare molto. Ma funziona solo se il team ha già definito cosa sta cercando di proteggere.