Quando (Non) Usare l'AI

La malattia del martello d'oro

C'è un vecchio adagio nell'ingegneria: «quando hai un martello, tutto sembra un chiodo». Nel 2026 il martello si chiama LLM, e il mondo intero sembra un chiodo da colpire con l'intelligenza artificiale.

Ogni startup, ogni prodotto, ogni workflow vuole il suo «powered by AI». Ma la domanda che quasi nessuno si pone è: serve davvero un LLM per questo compito? E se sì, serve il modello più potente e costoso?

Questa pagina è una guida controcorrente. Non contro l'AI — la usiamo ogni giorno e la consideriamo una delle tecnologie più trasformative della storia — ma contro l'uso acritico dell'AI. Contro l'idea che più token spendi, più sei intelligente.

Principio zero: L'intelligenza artificiale è uno strumento. Come ogni strumento, ha un costo, un contesto d'uso e dei limiti. Usarla dove non serve non è innovazione, è spreco.

Il costo nascosto di ogni token

Partiamo dai numeri, perché i numeri non mentono.

Ogni chiamata a un LLM ha un costo che dipende da tre fattori: il modello, la lunghezza dell'input (prompt + contesto) e la lunghezza dell'output. A prima vista sembra economico — frazioni di centesimo per richiesta. Ma i costi si accumulano in modo non lineare:

La tabella è provocatoria di proposito. Non tutti questi casi sono identici — il LLM può gestire varianti e edge case che un regex non vede. Ma il punto è: nella maggioranza dei casi d'uso reali, il compito è più semplice di quanto pensiamo, e un approccio deterministico funziona meglio, più velocemente, e gratis.

Il costo non è solo denaro

Oltre al costo monetario, ogni chiamata LLM ha:

• Latenza — anche il modello più veloce impiega 200-500ms. Un regex impiega microsecondi.
• Non-determinismo — la stessa domanda può dare risposte diverse. Per operazioni che richiedono coerenza assoluta (parsing, validazione, trasformazione dati), questo è un difetto, non una feature.
• Dipendenza esterna — se l'API è giù, il tuo sistema è giù. Un script locale non ha questo problema.
• Complessità operativa — rate limits, retry, gestione errori, monitoraggio costi, aggiornamenti di modello che cambiano il comportamento.
• Costo ambientale — ogni inferenza consuma energia. Moltiplicato per milioni di richieste inutili, il conto con il pianeta è salato.

Bash: l'orchestratore che già hai (e che è gratis)

Ecco una verità scomoda: per molti workflow, il miglior orchestratore non è LangChain, non è CrewAI, non è un agent loop — è uno script Bash.

Sembra una provocazione, ma pensiamoci. Un tipico workflow «AI-powered» fa questo:

1. Recupera dati da un'API
2. Trasforma i dati in un formato diverso
3. Chiama un'altra API con i dati trasformati
4. Salva il risultato da qualche parte
5. Notifica qualcuno

Nessuno di questi passi richiede intelligenza artificiale. Sono operazioni deterministiche, sequenziali, ripetibili. Esattamente quello per cui Bash (o Python, o qualsiasi linguaggio di scripting) è stato inventato.

#!/bin/bash
# Recupera ordini del giorno da un'API
ORDERS=$(curl -s "https://api.example.com/orders?date=$(date +%F)" \
  -H "Authorization: Bearer $API_KEY")

# Estrai gli ordini con importo > 1000€ (jq, non un LLM)
BIG_ORDERS=$(echo "$ORDERS" | jq '[.[] | select(.amount > 1000)]')

# Conta e calcola totale
COUNT=$(echo "$BIG_ORDERS" | jq 'length')
TOTAL=$(echo "$BIG_ORDERS" | jq '[.[].amount] | add')

# Genera report (template, non un LLM)
cat <<EOF > /tmp/report.txt
Report Ordini Rilevanti — $(date +%F)
Ordini sopra 1000€: $COUNT
Totale: €$TOTAL

Dettaglio:
$(echo "$BIG_ORDERS" | jq -r '.[] | "- \(.customer): €\(.amount)"')
EOF

# Invia via email (o webhook, o Slack, o Telegram)
curl -s -X POST "https://hooks.slack.com/services/XXX" \
  -H "Content-Type: application/json" \
  -d "{\"text\": \"$(cat /tmp/report.txt)\"}"

Questo script fa in 0.5 secondi e a costo zero quello che un agente AI farebbe in 15 secondi consumando migliaia di token. E lo fa in modo deterministico: il risultato è sempre lo stesso dati gli stessi input.

Quando Bash batte l'AI

Il pattern è chiaro: tutto ciò che è deterministico, strutturato e ripetibile non ha bisogno di AI. L'AI brilla dove serve comprensione del linguaggio, ragionamento, creatività, gestione dell'ambiguità.

Regola pratica: Se puoi scrivere un if/else che copre tutti i casi, non ti serve un LLM. Se i casi sono troppi, troppo sfumati o impossibili da enumerare, allora sì.

La manovalanza digitale: il peccato originale

C'è un concetto che nel settore pochi osano nominare: la manovalanza digitale. È quando usi un modello da miliardi di parametri — addestrato su tutto lo scibile umano — per fare cose che un for loop farebbe meglio.

È come assumere un chirurgo per tagliare il pane. Può farlo? Certo. Lo farà bene? Probabilmente. Ha senso? Assolutamente no.

Esempi concreti di manovalanza AI

1. Formattare dati

Hai un JSON e vuoi un CSV. La tentazione: «Hey Claude, convertimi questo JSON in CSV». La realtà: jq -r '.[] | [.name, .email, .amount] | @csv'. Fatto. Zero token, zero latenza, zero possibilità di errore.

2. CRUD routing

Un utente dice «mostrami gli ordini di oggi». La tentazione: far analizzare la frase da un LLM per capire l'intent. La realtà: se hai 4 intent possibili (crea, leggi, aggiorna, elimina), un semplice pattern matching con keyword è sufficiente nel 95% dei casi. L'LLM serve per il 5% ambiguo.

3. Validazione input

«Usa l'AI per validare che l'email sia corretta». No. Un regex validate le email dal 1997. Funziona sempre, è istantaneo, e non ti dice mai che test@.com «sembra un'email valida» perché è di buon umore quel giorno.

4. Generare HTML statico

Hai un template con 5 variabili. La tentazione: far generare l'HTML a un LLM. La realtà: un template engine (Jinja2, Mustache, o anche un semplice sed) fa lo stesso lavoro in modo deterministico e non rischia di «migliorare» il tuo HTML aggiungendo classi CSS creative.

5. Spostare file, rinominare, organizzare

Compiti da filesystem. find, mv, rename esistono da 50 anni. Funzionano.

Il test della manovalanza: Se un compito può essere descritto come una sequenza finita di passi senza decisioni ambigue, è manovalanza. Non sprecare un cervello artificiale per la manovalanza.

Model routing: il modello giusto per il compito giusto

Ok, hai stabilito che il tuo compito richiede effettivamente un LLM. Bene. Ma quale? La tentazione naturale è usare sempre il modello più potente: «Se Opus esiste, perché dovrei usare Haiku?»

Perché Opus costa 30 volte più di Haiku. E per il 70% dei compiti che richiedono un LLM, Haiku è più che sufficiente.

La piramide dei modelli

Immagina una piramide. Alla base ci sono i compiti semplici — tanti, frequenti, a basso valore unitario. In cima i compiti complessi — pochi, rari, ad alto valore.

                    ╔═══════════╗
                    ║   OPUS    ║  ← Ragionamento complesso, analisi multi-step,
                    ║  ($15/M)  ║    decisioni critiche. 5% dei casi.
                  ╔═╩═══════════╩═╗
                  ║    SONNET     ║  ← Generazione testo, coding, riassunti
                  ║   ($3/M)      ║    articolati. 25% dei casi.
                ╔═╩═══════════════╩═╗
                ║      HAIKU        ║  ← Classificazione, estrazione dati,
                ║    ($0.25/M)      ║    risposte brevi, routing. 40% dei casi.
              ╔═╩═══════════════════╩═╗
              ║  NESSUN LLM (script)  ║  ← Tutto il resto. 30% dei casi.
              ╚═══════════════════════╝

Il model routing è l'arte di instradare ogni richiesta al livello corretto della piramide. Non è un'ottimizzazione marginale — può ridurre i costi del 70-80% senza impatto percepibile sulla qualità.

Come funziona nella pratica

Il routing può essere implementato a diversi livelli di sofisticazione:

Livello 1 — Routing statico per funzionalità

Il più semplice: assegni un modello fisso per ogni funzionalità del tuo prodotto.

MODEL_ROUTING = {
    "classificazione_ticket": "claude-haiku",      # Veloce, economico
    "risposta_cliente": "claude-sonnet",            # Buon equilibrio
    "analisi_contratto": "claude-opus",             # Serve ragionamento profondo
    "estrazione_email": "claude-haiku",             # Task semplice
    "generazione_report": "claude-sonnet",          # Serve qualità di scrittura
    "suggerimento_strategico": "claude-opus",       # Serve visione d'insieme
}

def get_model(task_type: str) -> str:
    return MODEL_ROUTING.get(task_type, "claude-haiku")  # Default: il più economico

Livello 2 — Routing dinamico con classificatore

Usi un modello piccolo (o regole) per classificare la complessità della richiesta e scegliere il modello.

import re

def classify_complexity(user_message: str) -> str:
    """Classifica la complessità SENZA usare un LLM."""
    msg = user_message.lower()

    # Segnali di complessità alta → Opus
    complex_signals = [
        r"analizz[ai]", r"compar[ai]", r"strategi[ac]",
        r"pro e contro", r"valut[ai]", r"consiglia",
        r"perch[eé].*meglio", r"differenz[ae].*tra"
    ]
    if any(re.search(p, msg) for p in complex_signals):
        return "claude-opus"

    # Segnali di complessità media → Sonnet
    medium_signals = [
        r"scriv[i]", r"genera", r"riassun[ti]",
        r"spiega", r"come funziona", r"esempio"
    ]
    if any(re.search(p, msg) for p in medium_signals):
        return "claude-sonnet"

    # Tutto il resto → Haiku
    return "claude-haiku"

Nota: il classificatore stesso non è un LLM. È un set di regole. Usa un LLM per classificare il lavoro di un LLM solo se le regole non bastano — e nella maggior parte dei casi, bastano.

Livello 3 — Routing adattivo con fallback

Provi prima con il modello più economico. Se la risposta non supera un controllo di qualità, escali al modello successivo. Piattaforme come ChipsBot implementano una variante di questo pattern: l'orchestratore sceglie lo specialista (e quindi il modello e il contesto) in base all'intent dell'utente, evitando di sovraccaricare ogni richiesta con un contesto monolitico.

async def smart_completion(prompt: str, quality_threshold: float = 0.7):
    """Prova con Haiku, escala se necessario."""

    # Tentativo 1: modello economico
    response = await call_llm("claude-haiku", prompt)

    # Verifica qualità (può essere regole, non necessariamente un LLM)
    quality = evaluate_response(response, prompt)

    if quality >= quality_threshold:
        return response  # Haiku bastava!

    # Tentativo 2: modello medio
    response = await call_llm("claude-sonnet", prompt)
    quality = evaluate_response(response, prompt)

    if quality >= quality_threshold:
        return response  # Sonnet ce l'ha fatta

    # Tentativo 3: modello premium (ultima risorsa)
    return await call_llm("claude-opus", prompt)

La trappola del «sempre il modello migliore»

Esaminiamo questa mentalità così diffusa. Perché la gente vuole sempre usare il modello più potente? Ci sono ragioni psicologiche e ragioni tecniche, entrambe comprensibili ma spesso sbagliate.

La psicologia

• Paura di sbagliare — «E se Haiku dà una risposta sbagliata e il cliente se ne accorge?». Ma anche Opus può sbagliare. La differenza è che l'errore di Opus costa 30 volte di più.
• Mancanza di misura — Se non misuri la qualità delle risposte per modello, non sai che Haiku funziona nel 90% dei casi. Quindi usi Opus «per sicurezza».
• Effetto demo — Il modello top fa demo impressionanti. Ma la demo è un contesto controllato. La produzione è un'altra cosa.
• Status symbol — «Noi usiamo GPT-4o/Opus» suona meglio di «noi usiamo Haiku con fallback». Ma il secondo è più intelligente.

La realtà tecnica

I benchmark mostrano che per compiti specifici e ben definiti (classificazione, estrazione, risposte fattuali), la differenza tra Haiku e Opus è spesso sotto il 5%. La differenza diventa significativa solo per:

• Ragionamento multi-step complesso
• Compiti che richiedono di tenere a mente molte variabili contemporaneamente
• Generazione di testo lungo e coerente
• Compiti che richiedono «buon senso» e giudizio sfumato
• Coding complesso con logica intricata

Per tutto il resto — e «il resto» è la maggior parte del lavoro reale — il modello piccolo va benissimo.

Scenario: SaaS con 50.000 richieste AI/mese

Senza routing (tutto Opus):
  50.000 × $0.06 media = $3.000/mese

Con routing intelligente:
  15.000 × $0.00 (script, nessun LLM)  = $0
  20.000 × $0.005 (Haiku)              = $100
  12.000 × $0.02 (Sonnet)              = $240
   3.000 × $0.06 (Opus)                = $180
                                 Totale = $520/mese

Risparmio: 83% ($2.480/mese = $29.760/anno)

Filosofia dello strumento giusto

C'è una lezione più profonda dietro al model routing e alla scelta di non usare l'AI. È una lezione di ingegneria matura.

L'ingegnere junior vuole usare la tecnologia più avanzata. L'ingegnere senior vuole usare la tecnologia più appropriata. Sono due mentalità radicalmente diverse.

La tecnologia più avanzata è affascinante, ma porta con sé:

• Complessità accidentale — ogni layer aggiunto è un punto di rottura potenziale
• Debito cognitivo — il team deve capire e mantenere tecnologia che forse non serve
• Lock-in — più dipendi da un provider AI, più sei vulnerabile ai suoi cambiamenti (pricing, rate limits, deprecation)
• Fragilità — un sistema con meno parti mobili è un sistema più robusto

Il principio della meno magia possibile

Nel framework Django c'è un concetto chiamato «less magic»: preferire l'esplicito all'implicito, il semplice al sofisticato. Lo stesso principio si applica all'AI:

Principio della meno magia: Usa l'approccio più semplice che risolve il problema. Se un if/else basta, usa quello. Se serve un classificatore ML, usa quello. Se serve un LLM, usa il più piccolo che funziona. Escala solo quando hai evidenza che serve.

Questo non è conservatorismo tecnologico. È rispetto per la complessità. Ogni pezzo di complessità che aggiungi deve giustificare la sua esistenza con un beneficio misurabile.

La scala delle soluzioni: dal semplice al complesso

Quando hai un problema, percorri questa scala dal basso verso l'alto. Fermati al primo gradino che funziona.

Livello 8: Sistema multi-agente con orchestratore    $$$$$
Livello 7: RAG + LLM con knowledge base              $$$$
Livello 6: LLM grande (Opus/GPT-4o) con prompt        $$$
Livello 5: LLM piccolo (Haiku/GPT-4o-mini)             $$
Livello 4: Classificatore ML fine-tuned                  $
Livello 3: Regex + regole + lookup table                 ¢
Livello 2: Script (Python/Bash/jq)                       ¢
Livello 1: Configurazione statica / hardcoded             0
Livello 0: Non fare niente (il feature più sottovalutato) 0

↑ Sali solo se il livello sotto non basta.
↓ Il default è il più basso possibile.

Il Livello 0 merita una menzione speciale. A volte la soluzione migliore è non costruire la feature. Se nessuno l'ha chiesta, se il valore è speculativo, se il costo di manutenzione supera il beneficio — non farla. Nessun LLM, nessuno script, niente. Zero costo, zero bug, zero manutenzione.

Anti-pattern: quando l'AI fa danni

Non si tratta solo di spreco economico. In certi casi, usare l'AI dove non serve crea problemi reali.

Anti-pattern 1: AI dove serve determinismo

Un sistema di fatturazione che usa un LLM per calcolare gli importi. Sembra assurdo? Succede. L'LLM «arrotonda» a modo suo, interpreta «IVA inclusa» in modo diverso a seconda del contesto, e un giorno decide che lo sconto è del 15% invece che del 10% perché 15 «sembra più ragionevole».

Regola: Mai LLM per calcoli finanziari, validazione dati critici, o qualsiasi cosa dove il risultato deve essere identico ogni volta.

Anti-pattern 2: AI nel path critico di latenza

Un middleware che chiama un LLM per decidere se una richiesta HTTP è autorizzata. Ogni richiesta aggiunge 500ms. Moltiplica per migliaia di richieste al secondo. Congratulazioni: hai appena reso la tua app inutilizzabile.

Regola: Mai LLM nel hot path. Le decisioni in tempo reale ad alta frequenza devono essere deterministiche e locali.

Anti-pattern 3: AI per problemi già risolti

«Usiamo l'AI per rilevare se un'email è spam». SpamAssassin esiste dal 2001 e ha un tasso di accuratezza del 99.9%. «Usiamo l'AI per comprimere le immagini». WebP, AVIF e mozjpeg esistono e funzionano meglio. Non reinventare la ruota con un razzo.

Anti-pattern 4: AI come pappagallo costoso

Un chatbot che risponde a 50 FAQ. Il 95% delle risposte è identico ogni volta. Un semplice lookup per keyword con fuzzy matching costa zero e risponde in millisecondi. L'LLM aggiunge valore solo per il 5% di domande fuori copione — e per quel 5%, usa un modello piccolo con RAG.

Quando l'AI è indispensabile

Dopo tutta questa critica, è giusto riconoscere dove l'AI è non solo utile, ma insostituibile. Ci sono compiti che semplicemente non puoi fare senza un modello linguistico:

Comprensione del linguaggio naturale

Quando l'input è linguaggio umano non strutturato — email, chat, documenti, feedback — e devi capirlo, non solo cercarlo. La differenza tra «cercare la parola 'rimborso' in un ticket» (grep) e «capire se il cliente vuole un rimborso anche se non usa mai quella parola» (LLM).

Generazione di contenuto originale

Scrivere testo che non esisteva prima: riassunti, report narrativi, email personalizzate, documentazione. Qui non c'è alternativa. Un template può riempire variabili, ma non può scrivere.

Ragionamento in presenza di ambiguità

Quando le regole non bastano perché il mondo è sfumato. «Questo contratto è favorevole per noi?» — non puoi codificarlo in un if/else. Serve giudizio, contesto, capacità di pesare fattori multipli.

Interfaccia conversazionale

Quando vuoi che un utente interagisca con un sistema in linguaggio naturale. Qui l'AI è l'unica opzione. Non puoi fare un chatbot senza un modello linguistico (puoi fare un bot a menu, ma non è la stessa cosa). Piattaforme come ChipsBot rendono accessibile la creazione di chatbot AI, ma il punto resta: il chatbot conversazionale è un caso d'uso dove l'LLM è genuinamente necessario.

Analisi semantica su larga scala

Analizzare migliaia di recensioni per capire i temi ricorrenti. Categorizzare documenti legali per argomento. Identificare pattern in dati testuali non strutturati. Qui il valore dell'AI è enorme e non ha alternative comparabili.

L'architettura ibrida: il meglio di entrambi i mondi

La soluzione matura non è «tutto AI» né «niente AI». È un'architettura ibrida dove ogni componente usa lo strumento appropriato.

┌─────────────────────────────────────────────────────┐
│                   Richiesta utente                   │
└──────────────────────┬──────────────────────────────┘
                       │
                ┌──────▼──────┐
                │  ROUTER     │  ← Regole + keyword matching
                │  (no LLM)   │    Costo: $0
                └──┬───┬───┬──┘
                   │   │   │
          ┌────────┘   │   └────────┐
          │            │            │
    ┌─────▼─────┐ ┌───▼────┐ ┌────▼─────┐
    │   FAQ     │ │ ORDINI │ │ SUPPORTO │
    │  Lookup   │ │  API   │ │   AI     │
    │ (no LLM)  │ │(no LLM)│ │ (Haiku)  │
    └─────┬─────┘ └───┬────┘ └────┬─────┘
          │            │           │
          │            │     ┌─────▼──────┐
          │            │     │ Abbastanza │
          │            │     │  buono?    │
          │            │     └──┬─────┬───┘
          │            │        │ Sì  │ No
          │            │        │     │
          │            │        │  ┌──▼──────┐
          │            │        │  │ ESCALATE │
          │            │        │  │ (Sonnet) │
          │            │        │  └────┬─────┘
          │            │        │       │
          └────────────┴────────┴───────┘
                       │
              ┌────────▼────────┐
              │    Risposta     │
              │   all'utente   │
              └─────────────────┘

In questa architettura:

• Il 60-70% delle richieste non tocca mai un LLM (FAQ lookup + API ordini)
• Il 25% delle richieste usa Haiku (supporto semplice)
• Solo il 5-10% escala a Sonnet (casi complessi)
• Opus non serve quasi mai in un contesto di customer support

Questo è esattamente il tipo di architettura che piattaforme come ChipsBot implementano con il pattern orchestratore-specialisti (approfondito nella sezione dedicata): ogni specialista sa quando ha bisogno dell'AI e quando può rispondere con logica deterministica.

Checklist decisionale: devo usare l'AI?

Prima di aggiungere un LLM a qualsiasi flusso, poniti queste domande nell'ordine:

Il futuro: quando i modelli costeranno zero?

Obiezione legittima: «I costi scendono ogni anno. Tra 2-3 anni Opus costerà quanto Haiku oggi. Perché preoccuparsi?»

Vero, i costi scenderanno. Ma:

• La complessità resta. Anche se l'LLM è gratis, la latenza, il non-determinismo, la dipendenza esterna, e la complessità operativa non spariscono.
• I volumi crescono più velocemente dei costi che scendono. Se oggi fai 10.000 richieste e domani ne fai 1.000.000, il costo unitario dimezzato non ti salva.
• Il principio ingegneristico resta valido. Usare lo strumento più semplice non è una questione di costo — è una questione di correttezza architetturale. Un sistema semplice è più facile da capire, testare, debuggare, e mantenere. Questo non cambierà mai, indipendentemente dal prezzo dei token.

Il costo dei token scenderà. Il costo della complessità no. Scegli i tuoi strumenti per la loro appropriatezza, non per il loro prezzo. Quando il prezzo sarà zero, la differenza tra un'architettura pulita e una gonfiata di AI inutile sarà ancora più evidente.

Conclusione: l'intelligenza è sapere quando non essere intelligenti

L'ironia dell'intelligenza artificiale è questa: la cosa più intelligente che puoi fare con l'AI è sapere quando non usarla.

Non è un messaggio anti-tecnologia. Usiamo l'AI ogni giorno, la consideriamo rivoluzionaria, e costruiamo prodotti basati su di essa (come ChipsBuilder per la creazione di siti e ChipsBot per i chatbot). Ma proprio perché la usiamo intensamente, abbiamo imparato dove brilla e dove è uno spreco.

La prossima volta che pensi «potrei usare l'AI per questo», fermati un secondo e chiediti: «potrei farne a meno?». Se la risposta è sì, congratulazioni — hai appena risparmiato soldi, complessità e token. E il tuo sistema è un po' più robusto.

Se la risposta è no — se serve davvero comprensione, ragionamento, generazione — allora usa l'AI. Ma usa il modello giusto, non il più grande. E misura. Sempre.