Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo
Pratiche operative e implicazioni pratiche nella produzione software: leggibilità, distribuzione locale di modelli e fiducia aziendale
I've recently started hiding the bulk of my AI-generated GitHub PR descriptions behind a collapsed <details><summary> HTML tag (thankfully supported by GitHub Markdown) and I think it's a useful pattern for making PR slop a little bit less exhausting https://simonwillison.net/2026/Nov/9/details-summary/
The kimi-k3 branch of DwarfStar can now do K3.1 PRO inference directly from safetensors weights with SSD streaming. Slow, but good enough for QA tasks.
DwarfStar, branch kimi-k3, esegue K3.1 PRO da safetensors con streaming da SSD. Lo annuncia Salvatore Sanfilippo, autore di Redis. L’inferenza è out-of-core: il modello non sta in RAM e i pesi restano su disco in safetensors, formato diffuso e sicuro da caricare. Il vincolo di memoria che spingeva verso cloud o modelli ridotti si sposta su I/O e latenza degli accessi, e apre scenari locali.
La conseguenza per test e QA: si validano prompt e regressioni in locale, accettando tempi più lunghi per la privacy. Cambia il ritmo, con batch notturni che assorbono la latenza. La redazione è d’accordo: per QA ha senso subito. Per servizio interattivo resta un limite, perché gli accessi da SSD frenano throughput e batching.
Closer to three weeks later, no sign of a postmortem, and zero comms to customers (like me!) on what happened L on Revolut, and so much for assuming there's a decent eng culture there Sorry to say but Revolut is less reliable than trad banks, and more risky to rely on
Gergely Orosz, che da anni misura la maturità dei team tecnici dalla gestione degli incidenti, contesta il silenzio di Revolut e parla di «nessun postmortem e zero comunicazioni». Il problema non è l’interruzione in sé, che capita, ma l’assenza di un resoconto tempestivo e firmato che dimostri controllo del processo. La redazione concorda: una cultura ingegneristica credibile si vede nella responsabilità pubblica dopo il guasto.
Per chi guida piattaforme, questo si traduce in pratica in un obbligo chiaro: postmortem entro 72 ore, con firma di un responsabile tecnico identificabile e pubblicazione su canali predefiniti come status page e blog, già inclusi nei runbook. Il confronto con le banche richiede dati comparabili su frequenza e durata degli incidenti e sulla puntualità dei postmortem. Un precedente utile viene dal mondo cloud, dove i resoconti pubblici a pochi giorni dall’evento sono prassi.
Giudizio della redazione: scelta giusta, purché il summary contenga le parti critiche. Simon Willison propone di collassare nelle PR GitHub il testo generato dall’AI con i tag HTML supportati, e di tenerne visibile solo un’introduzione curata da un umano. Willison, co‑autore di Django e autore di Datasette, lavora spesso con descrizioni di PR piene di testo prodotto da modelli e scrive che «nascondere il grosso del testo generato dall’AI dietro <details><summary>» riduce la fatica.
Per chi fa review la conseguenza pratica è un carico cognitivo più basso: si legge il riassunto umano, si capisce scopo e perimetro, poi si decide se aprire il resto mentre si guarda il diff. Si può inserire nel template senza cambiare processo: primo paragrafo curato sopra, materiale dell’agente piegato sotto.