Il tuo assistente AI sceglie un servizio cloud al posto tuo: come evitare la scelta di default

Un'analisi su quasi 17mila sessioni reali di Claude, Codex e Cursor ha misurato quale servizio terzo (storage, autenticazione, osservabilità...) questi assistenti consigliano quando devono implementare una funzionalità. Il risultato interessante non è chi vince, ma quanto la risposta cambi in base a come viene fatta la domanda — e quanto raramente ci fermiamo a farla nel modo giusto.

Il problema: un agente che non si ferma, sceglie per te

Lo studio ha messo alla prova gli assistenti su compiti concreti del tipo "ogni fattura che generiamo deve arrivare via email al cliente, trova la soluzione migliore e implementala". I ricercatori hanno osservato un pattern chiaro: se all'agente viene chiesto di implementare direttamente, senza margine per fare domande, tende a costruire tutto internamente o a scegliere il fornitore più "scontato" per quel tipo di stack — spesso lo stesso che ha già visto altrove nel codice esistente. Solo quando nel flusso di lavoro è previsto un momento in cui l'agente propone opzioni e aspetta una decisione, la scelta finale riflette davvero un confronto, e non la prima opzione plausibile.

Un esempio citato nello studio: in un esperimento sullo storage di oggetti, gli agenti finivano quasi sempre per proporre Amazon S3 — finché non veniva introdotto un passaggio esplicito di conferma prima di implementare, che dava spazio ad alternative come Cloudflare R2 di emergere e vincere in un numero rilevante di sessioni.

Cosa significa per chi usa un agente AI ogni giorno

Se lavori con un assistente AI per scrivere codice, la lezione pratica è semplice: le scelte di infrastruttura — quale servizio di email transazionale, quale database, quale provider di autenticazione — sono esattamente il tipo di decisione che un agente prenderà volentieri al posto tuo, in modo silenzioso, se gli lasci lo spazio per farlo. Il codice generato funzionerà, i test passeranno, e settimane dopo ti troverai con una dipendenza da un servizio che non hai mai consapevolmente scelto.

Vale la pena strutturare la richiesta in due tempi, invece che uno:

// Prima richiesta: solo analisi, nessuna implementazione
"Analizza il codice esistente e proponi 2-3 opzioni per inviare
l'email di conferma dopo la generazione della fattura. Per ognuna,
elenca costi stimati, complessità di integrazione e vincoli (es.
serve un dominio verificato?). Non implementare ancora."

// Seconda richiesta, dopo aver scelto tu:
"Implementa la soluzione con [nome servizio scelto], seguendo la
struttura del progetto esistente."

Questo pattern in due passaggi costa qualche minuto in più rispetto a "fai tutto tu", ma è esattamente il momento in cui il progetto smette di ereditare passivamente le preferenze di default di un modello e inizia a riflettere scelte tecniche fatte consapevolmente — cosa che conta doppio se il software che stai costruendo dovrà essere mantenuto, e pagato, per anni.