Cosa fare quando ChatGPT va giù: il playbook dello sviluppatore

ChatGPT è giù. Twitter è una galleria di schermate di errore. La vostra pull request aspetta ancora. L’outage non è la storia. La storia è se vi bloccate o continuate a consegnare.

OpenAI è andata giù nel 2023, 2024, 2025 e 2026. Anche Claude, Gemini e Copilot, nei giorni più silenziosi. La domanda utile non è «succederà di nuovo». È: nella prossima ora, cosa è davvero bloccato - e cosa lo sembra solo perché la scheda della chat restituisce un 500.

Non mescolate due incident. Avete perso un copilota. Oppure le chiamate OpenAI del prodotto stanno dando 500. Il primo è un problema di workflow. Il secondo è un incident. Sono due stanze diverse.

1. I primi cinque minuti: è davvero giù?

Ricaricare non è una diagnosi. Prima di aprire tre altre chat e un thread sulla «fine dell’IA», spendete cinque minuti a nominare il guasto.

• Controllate status.openai.com, poi status.anthropic.com e lo status Google AI se li usate già. Downdetector è un umore. La pagina di status del vendor è un segnale.
• ChatGPT il sito non è l’API, e nessuno dei due è Cursor. chatgpt.com può essere morto mentre gpt-4o nell’editor, o Claude nello stesso editor, risponde ancora. Nominate la superficie: app web, API, Copilot, selettore di modello in Cursor.
• Scartate il vostro lato: VPN, DNS, proxy aziendale, ad blocker, sessione stantia. I limiti del piano gratis sembrano un outage se da un’ora incollate lo stesso file.
• Se la pagina di status del vendor è rossa per la vostra regione, smettete di ricaricare quaranta volte. Non lo farete tornare a forza di volontà. Cambiate superficie o cambiate compito.

2. Sostituite la chat, non tutto il cervello

Alle 14 non vi serve una nuova filosofia del lavoro. Vi serve un altro modello che finisca il ticket. Entrate in un’alternativa e proseguite lo stesso compito. Non migrate lo «stack» in mezzo a un outage.

• Claude (Anthropic): spesso più solido su diff lunghi e refactor attenti. Se avete già la scheda, quella è la prima porta.
• Gemini / Google AI Studio: utile quando serve un secondo parere o un modello che ha ancora quota. Non è una religione. È una batteria di scorta.
• Cursor, Claude Code, Copilot, Windsurf: se l’IDE ha già un altro modello collegato, cambiate il selettore prima di aprire una chat nel browser. Il contesto del repo c’è già. È il senso di un editor agentico.
• La ricerca in doc, le issue GitHub e il changelog ufficiale battono un’API allucinata quando la domanda è «Next.js ha rinominato questo?». Un LLM è un junior veloce. Il changelog è la fonte.

3. Modelli locali: quando salvano il pomeriggio

Ollama, LM Studio, llama.cpp: a un modello sul portatile non importa che chatgpt.com dia 500. Non conosce nemmeno la release di Next.js della settimana scorsa. Usatelo per i lavori giusti.

• Bene: finire una funzione dal contesto che incollate, spiegare uno stack trace, riscrivere una regex, abbozzare un messaggio di commit, trasformare appunti in un nome di test.
• Male: architettura di un repo che il modello non ha mai visto; «qual è l’API attuale dell’App Router»; qualunque cosa che debba allinearsi alla doc di questo mese.
• Se non avete mai scaricato un modello locale, un outage è un brutto momento per iniziare. Fatelo un venerdì calmo: installate Ollama, scaricate un modello instruct 7B o 14B, lanciate un prompt vero del lavoro. Trenta minuti, una volta.

4. Il lavoro che non ha mai avuto bisogno di ChatGPT

Lo stack trace è ancora lì. Il test che fallisce è ancora rosso. Git ha ancora blame. Un outage ricorda in modo sgarbato che il modello non è mai stato la fonte di verità - era un modo veloce per parlarci.

• Leggete l’errore. Non il vibe dell’errore: il file, la riga, il messaggio. Poi aprite quel file.
• git blame, git log -p, le ultime tre PR su quel path. La maggior parte dei bug «misteriosi» è martedì scorso.
• Doc ufficiale, MDN, changelog della libreria, una riproduzione minima. Più lento di una chat. Meno finzione.
• Debugger, un test rosso, un console.log che cancellerete. Paperella: scrivete il problema in un commento. Spesso la risposta arriva prima della fine della frase.
• Se senza chat non fate un passo, il compito era sotto-specificato - o avete messo in outsourcing il pensiero. È un’informazione utile. Non è un difetto di carattere. Prima la spec, poi il codice.

5. Se il prodotto chiama l’API OpenAI

Non è «incollo in Claude per un’ora». È incident response. Gli utenti preferiscono «l’assistente è temporaneamente non disponibile» a uno spinner che non finisce mai.

• Nominate il guasto: la vostra chiave, la quota, il timeout o i loro 5xx. Dashboard e pagina di status sono in disaccordo più spesso di quanto vogliate. Loggate lo status code, non solo «l’IA è rotta».
• Se un secondo provider è già collegato, fate failover. Ho già scritto come un LLM sta dietro un passo a pagamento e cos’è davvero un provider. Un outage è un brutto momento per progettarlo. È un buon momento per girare un flag preparato.
• Degradate: mettete la scrittura in coda, rispondete dalle FAQ, mostrate una frase umana. Niente tempesta di retry. Backoff. Un chatbot che martella un’API morente allunga l’incident per tutti, voi compresi.

6. Un kit da montare prima del prossimo outage

Trenta minuti di setup in un giorno calmo battono tre ore a ricaricare Twitter. Lo sapete già. L’outage è solo la fattura.

• Una seconda chat già loggata: Claude o Gemini, con un billing che regge un pomeriggio pieno. Una scheda gratis non aperta da marzo non è un piano.
• L’IDE con almeno due modelli nel selettore. Se Cursor ha solo OpenAI, avete comprato un single point of failure e l’avete chiamato workflow.
• Un modello instruct locale già scaricato. Non «un giorno proverò Ollama». Già scaricato.
• Un file di note per i one-liner che chiedete sempre alla chat: git, docker, kubectl, quel jq che non ricordate mai. Quando la chat è morta, le note funzionano ancora offline.
• Per il prodotto: un flag di fallback, un backoff e una frase per l’UI già scritta. Gli incident vanno più veloci quando non inventate il testo su Slack.

7. La lezione che non piace a nessuno

ChatGPT è un junior veloce che ha letto Internet e nessuno dei vostri incident in produzione. Quando quel junior è in ferie, il senior deve comunque consegnare. Uso gli agenti ogni giorno. Devo comunque leggere il diff, lanciare i test e sapere dove sta la doc.

Gli outage continueranno. I modelli continueranno a cambiare nome. La competenza che sopravvive è ancora: specificare il risultato, debuggare il guasto, assumersi il merge. Ho già scritto come il vibe coding moltiplichi la disciplina che avete - e come un prompt vago spedisca il disastro più in fretta. Un pomeriggio senza ChatGPT è lo stesso esame, non pagato.

Conclusione: continuate a consegnare, tenete una scorta

Controllate la pagina di status. Nominate la superficie. Cambiate modello o cambiate compito. Se l’API è il prodotto, degradatela: non fingete che lo spinner sia una feature. Poi, in un giorno calmo, collegate la scorta: una seconda chat, un secondo modello nell’editor, un pull locale, un flag di fallback.

E una volta al mese chiudete la chat e finite comunque il ticket. Non per nostalgia. Così il prossimo outage è un disagio, non un blocco. :)