Quando l'AI fallisce per motivi stupidi: lezioni da un esperimento con agenti di codifica locali

C'è un tipo particolare di frustrazione che provi quando vedi un sistema intelligente crollare per ragioni completamente stupide. L'ho vissuta di persona giocando con agenti di codifica AI che girano in locale—un trend che sta prendendo piede perché i modelli open-weight diventano più capaci e sempre più sviluppatori cercano soluzioni che rispettino la privacy.

L'esperimento era semplice: poteva un agente di codifica che gira solo su hardware locale costruire un gioco vero? Non una demo banale, ma qualcosa con gestione reale dello stato, logica di rendering, gestione degli input e un'interfaccia giocabile. La risposta, dopo parecchi mal di testa, è sì—ma arrivarci ha rivelato una categoria di problemi che l'ecosistema degli strumenti AI non sta gestendo nel modo giusto.

La configurazione che avrebbe dovuto funzionare

Lo stack era composto da tre elementi che rappresentano il meglio dello sviluppo AI locale: un CLI per agenti di codifica provider-agnostic, Ollama che espone un'API compatibile con OpenAI da localhost, e Qwen3.8 27B in esecuzione sulla macchina locale. Per contesto, non è una configurazione sottodimensionata—il modello 27B a 17GB entra comodamente in 32GB di memoria unificata e supporta il tool calling con capacità di ragionamento rispettabili.

I risultati iniziali erano promettenti. In quindici minuti l'agente aveva prodotto una struttura HTML completa e quasi 200 righe di CSS in stile NES, con bordi smussati da cabinato e una palette colori corretta. Più impressionante ancora, l'agente ha intercettato un proprio errore durante l'esecuzione: ha scritto un file, l'ha riletto, ha notato una discrepanza tra ciò che intendeva fare e ciò che era effettivamente finito su disco, e l'ha corretto senza che nessuno glielo chiedesse. Questo è comportamento genuinamente agentico, e suggeriva che il modello fosse all'altezza del compito.

Poi l'agente ha tentato di scrivere il file della logica di gioco, e tutto si è bloccato.

La spirale discendente

Quello che è seguito è una sequenza che chiunque abbia lottato con strumenti AI riconoscerà. Tredici tentativi consecutivi di scrivere il file del motore di gioco, ognuno terminato a metà generazione. Lo stream moriva e basta, senza errori, senza spiegazioni, senza output utilizzabile.

L'aspetto più fastidioso non era il fallimento in sé—era osservare il processo di ragionamento dell'agente. Poiché ogni tentativo ripartiva da zero, il modello ricalcolava le stesse decisioni di design da capo, approdando a tabelle di punteggio e approcci implementativi diversi ogni volta. Tre retry significavano tre risposte diverse alla stessa domanda architetturale. L'agente passava un'ora a pensare e non consegnava niente.

Il colpevole ovvio sembrava essere la pressione sulla memoria. Chiudere le schede del browser ha liberato parecchi gigabyte di RAM e le cose sono migliorate marginalmente, il che sembrava confermare la diagnosi. Ma questa era la lezione sbagliata da trarre.

Quello che i log rivelavano davvero

Riguardando i log del server è emersa una storia diversa. Non c'era un singolo errore di memoria in nessuno di essi. La memoria libera del sistema si manteneva comodamente tra 21 e 27 gigabyte per tutto il tempo, contro un footprint del modello di 17 gigabyte. La memoria non era mai stata il problema.

Il vero problema era una mancata corrispondenza nella configurazione che non produceva alcun errore visibile. La config dell'agente dichiarava un context window di 32.768 token. Ma il server Ollama era stato riavviato con un tetto di 8.192 token, e questa discrepanza passava inosservata. L'agente pianificava serenamente un file da 800 righe da scrivere in un colpo solo, perché per quanto ne sapeva, aveva 32k di margine. Quando la generazione reale colpiva il muro degli 8k a metà tool-call, la connessione veniva troncata senza alcun messaggio di errore che l'agente potesse elaborare.

C'era una complicazione secondaria nascosta nei log di avvio: Ollama era partito con il context-shifting abilitato, il che avrebbe permesso alla finestra di scorrere quando terminava lo spazio, sacrificando i token più vecchi per far posto a quelli nuovi. Ma l'architettura del modello non supportava questa funzione, quindi era stata disabilitata silenziosamente. Quello che avrebbe dovuto essere un limite morbido era diventato un muro duro.

La disciplina DevOps che lo sviluppo AI richiede

Questa esperienza cristallizza qualcosa di importante sullo sviluppo AI locale che l'entusiasmo attorno ai modelli open-weight tende a oscurare. Quando fai girare modelli sul tuo hardware, non stai solo scrivendo codice—stai gestendo infrastruttura. E l'infrastruttura richiede la stessa disciplina diagnostica, gestione della configurazione e attenzione ai parametri operazionali che i sistemi in produzione richiedono.

Le context window non sono proprietà astratte del modello da impostare e dimenticare. Sono parametri operazionali che interagiscono con la tua catena di strumenti in modi non ovvi. Quando la context configurata dall'agente non corrisponde al tetto effettivo del server, non ricevi un avviso—ricevi fallimenti silenziosi che sembrano incompetenza del modello quando in realtà sono disallineamenti operazionali.

Il takeaway pratico per gli sviluppatori che esplorano agenti di codifica AI locali è diretto: valida il tuo ambiente con la stessa cura con cui valideresti un deployment in produzione. Verifica che la configurazione dell'agente corrisponda ai tuoi parametri runtime. Leggi i log del server, non solo l'output dell'agente. Capisci quali funzionalità l'architettura del tuo modello supporta davvero rispetto a cosa la strumentazione tenta di abilitare.

I modelli stanno migliorando. Gli strumenti stanno maturando. Ma il divario tra "funziona nelle demo" e "funziona in modo affidabile nell'uso quotidiano" richiede ancora giudizio umano per essere colmato—e quel giudizio somiglia parecchio alla disciplina DevOps tradizionale applicata a una nuova classe di infrastruttura.

Alla fine il build di Tetris è riuscito. Ci sono volute quattro ore e mezza distribuite su due giorni, ha prodotto codice pulito in tre file, e funziona correttamente. Ma le lezioni non sono venute dal successo, bensì dal capire perché i fallimenti erano avvenuti—e dal riconoscere che a volte i problemi più costosi non hanno nulla a che fare con l'intelligenza.