Hai un'AI per le cose serie e una per divertirti? Rendilo un metodo

Il racconto (pubblicato su dev.to) descrive una routine ormai comune per chi programma con l'assistenza AI: un modello per la pianificazione e i bug senza causa ovvia, un altro per le modifiche di routine, un terzo per domande veloci fuori dall'editor. La cosa interessante non è l'elenco in sé, ma come è emerso: l'autrice aveva chiesto a un agente AI dentro il proprio IDE di controllare velocemente un bozza di articolo — grassetti, tag, un controllo che richiede letteralmente due secondi d'occhio. L'agente ha invece aperto un browser, fatto screenshot, mosso il cursore, provato a cliccare, ripetendo il ciclo più volte per un compito che non richiedeva nessuna azione, solo una lettura.

Il problema non era la qualità del modello: era il disallineamento tra la forma del compito (guardare, non agire) e la forma dello strumento (un agente capace di navigare e cliccare). Più capacità non ha aiutato. Ha solo reso l'errore più lento e più costoso.

• Il compito richiede azione o solo lettura? Se ti serve solo un parere, un controllo, una risposta secca, un modello "chat" veloce basta e costa meno tempo di attesa. Se invece serve modificare file, eseguire comandi, orchestrare più passaggi, allora ha senso un agente capace di operare nel tuo ambiente — ma solo per quel tipo di compito, non di default.
• Conta di più la correttezza o la velocità? Per un bug difficile da riprodurre o una decisione di architettura, vale la pena aspettare qualche secondo in più e usare il modello più capace che hai a disposizione. Per un refactor meccanico o una domanda su una sintassi, un modello più leggero risponde prima e va benissimo lo stesso.
• Il compito si ripete? Se ti ritrovi a fare la stessa richiesta ogni settimana, probabilmente non ti serve più "scegliere l'AI giusta ogni volta": ti serve uno script, un prompt salvato, o un'automazione che non dipende più da quale strumento hai aperto in quel momento.

Questo criterio sta diventando più conveniente anche sul piano economico, non solo pratico. Nella stessa settimana in cui circolava questo racconto, OpenAI ha rilasciato due nuovi modelli pensati esplicitamente per compiti diversi: Sol, a 2 dollari ogni milione di token in input e 10 in output, e Luna, molto più economico a 0,10 e 0,50 dollari per milione di token. La logica è la stessa: non tutti i compiti meritano il modello più costoso, e i fornitori stessi stanno costruendo una gamma pensata per farti pagare in proporzione a quanto serve davvero, non a quanto è disponibile.

La conclusione pratica è semplice da scrivere e facile da dimenticare nella foga del lavoro quotidiano: prima di aprire lo strumento AI più potente che hai a portata di mano, chiediti se il compito che hai davanti ne ha davvero bisogno. Spesso la risposta più veloce, ed economica, è anche quella giusta.