Lunedì 2 novembre 2026
L’edizione di oggi
Millebit
AI · Software · QA
Il segnale, non il rumore.

Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo

← La Rassegna

lunedì 2 novembre 2026

La selezione insiste sulla necessità di valutazioni rigorose e primitive sicure per misurare tradeoff, affidabilità e prestazioni dei sistemi.

01 Sviluppo software

Verificare con ablation i tradeoff reali tra Rust e C

Many of those recent reimplementions and rewrites were done in Rust. However, to understand the implicit tradeoffs of this choice, an ablation study should be performed to see if/how faster and better the agent would do the same using the C language.

Salvatore Sanfilippo chiede un’ablation study per vedere «se/quanto» un agente vada meglio o peggio in C rispetto a Rust. Lo dice chi ha costruito Redis in C e conosce prestazioni e semplicità. Si porta il costo del modello di proprietà, l’attrito di toolchain e FFI, e l’ipotesi che la prevedibilità di C permetta un agente più rapido o più controllabile.

La conseguenza pratica: prima di pianificare una riscrittura, isolare l’hot path e misurarlo in C a parità di logica e vincoli. Se il guadagno su latenza e prevedibilità regge e la complessità resta gestibile, tenere C dove serve e limitare Rust al perimetro per la sicurezza. Concordiamo: serve misura, non fede. Chi parte con Rust rischia costi senza benefici misurati.

02 QA e affidabilità

Scollegare gli agenti dall’email finché mancano primitive sicure

Yes this is why I ended up disconnecting all my emails from Grok Bot and any an all agents that can receive password reset emails It's now handicapped - but better safe than sorry. We need much much better agentic primitives, and this will not happen without the platforms where the data is (eg Gmail) doing it. Or some other platform, and then I might move my email over there https://x.com/krishnadey30/status/2116774197527769440?a=JIr8ha7gg60XSpgtFcU&s=20

Gergely Orosz scollega l’email da Grok e da altri agenti per il rischio di reset password abusivi. Parla da autore di The Pragmatic Engineer, con credibilità sulle prassi enterprise, e indica il collo di bottiglia: chi custodisce i dati non offre primitive agentiche adeguate. Senza sandbox e permessi granulari forniti da chi gestisce l’inbox, il recinto resta finto. La minaccia di migrare dove queste primitive esistono è coerente con un rischio operativo, non con un gusto di design. «Meglio sicuro che dispiaciuto» è una scelta difendibile.

La conseguenza operativa è concreta e scomoda. L’indirizzo di recupero credenziali va spostato fuori da ogni perimetro toccato da agenti, e quegli agenti non devono leggere o inoltrare quei messaggi. L’email va trattata come un segreto di produzione. Valutazione della redazione: ha ragione Orosz. Chi offre confinamento robusto per gli agenti oggi si guadagna utenti come lui.

03 Intelligenza artificiale

Servono baseline umane e punteggi granulari nei benchmark

Nice to see a successor to GDPval to evaluate AI work but really needs human baselines like GDPval. Funnily enough, GPT-6 Pro spotted some errors in the grading. I also think the 0% scores hide economically meaningful differences in success rates. But still a valuable benchmark!

Ethan Mollick parla da chi misura l’AI sul lavoro pagato e mette il dito dove brucia: «servono baseline umane» e i «0% nascondono differenze economiche». Il successore di GDPval vale, ma senza riferimenti umani e con grading fragile si perde informazione. Che GPT-6 Pro abbia trovato errori nei voti è utile come lint, non come arbitro. GDPval resta raro perché confronta produttività su compiti realistici con persone vere.

Qui la mossa pratica è costruire riferimenti umani per ruolo e livello, con tempo medio, varianza e soglie di accettazione, e poi calibrare i punteggi del benchmark su quelle curve. Per un team QA questo cambia i gate di rilascio e il carico di revisione, quindi budget e SLA. Giudizio della redazione: d’accordo su riferimenti umani e punteggi granulari.