Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo
Ogni mattina leggiamo quello che hanno scritto le persone che contano su intelligenza artificiale, sviluppo software e QA. Ne scegliamo tre e diciamo perché contano.
Pratiche e scelte ingegneristiche mirate a migliorare affidabilità, verifica e stabilità di agenti, sistemi e interfacce terminali.
I'm telling you folks, ADRs and primitives are a huge leverage point for getting your agents to build the right thing. I don't have to worry about an agent going against an important architectural decision because they actually do read those and make the right choice.
Revisiting my tweets from 6m ago is funny, because I don’t run into any of these problems now at all. What was missing in my setup 6 months ago was the verification process I now use. 70% of my daily token spend goes into verifying patches, and only ~20-30% into creating them.
Cindy Sridharan dice che spende circa il 70% dei token per verificare le patch e 20-30% per crearle, e che con quel «metodo di verifica» i problemi di sei mesi fa sono spariti. Parla da chi costruisce sistemi distribuiti, test in produzione e affidabilità, e sposta l’attenzione dalla produttività di generazione alla validazione prima che la patch tocchi il sistema.
La conseguenza è trattare il ciclo LLM come un filtro, con budget e latenza sugli iter di controllo che fermano l’errore quando costa poco. Chi ha test e CI trasforma spesa in qualità prevedibile. Chi non ha copertura o oracoli di verifica rischia verifica apparente. Il costo in token e secondi va messo a bilancio. La redazione è d’accordo.
libghostty 1.0 is here! I started Ghostty ~5yrs ago to work towards this. Today, libghostty is in hundreds of projects used by tens of millions of people. 1.0 marks ABI stability, quality, and an invite for distros to begin packaging. https://mitchellh.com/writing/libghostty-1-0 Since starting the Ghostty project in 2022, the most common question I've been asked is "why?". Today, I'll answer this by showing the broad industry impact libghostty has already had. On top of JetBrains and Neovim already mentioned (that alone being over 10 million users): -KDE developers are experimenting with a Konsole replacement built on it. - Vercel's Turborepo uses it to render task output in its TUI.
La redazione è favorevole. L’ABI stabile promette di spostare la qualità a monte e di ridurre le divergenze fra emulatori integrati. Mitchell Hashimoto ha credenziali da produzione e ha trasformato Ghostty in una libreria C usabile, con l’obiettivo esplicito di un’«ABI stabile» e di un «invito alle distro a pacchettizzare». Per le grandi distribuzioni la stabilità dell’ABI è il prerequisito per l’ingresso nei repository, quindi il messaggio è mirato.
Il valore pratico sta nel riuso consistente dentro tool e IDE. Mitchell cita JetBrains e Neovim come integrazioni di peso, con sperimentazioni in KDE e in Turborepo e con fuzzing che ha scovato bug in btop. Lo stato della PR su Neovim e la sostituzione di JediTerm vanno verificati nei repository pubblici. Giudizio della redazione: rischio di accentramento accettabile se l’ABI dichiarata resta vincolante e i test pubblici continuano a crescere.
Kent C. Dodds dice che ADRs e primitive contano perché gli agenti «leggono davvero» e rispettano decisioni architetturali. Ha voce perché ha formato mezzo settore su test e React e parla a chi usa agenti in codebase reali. Il rovesciamento è trattare ADR e primitive come ambiente operativo, non come note di wiki.
La conseguenza pratica è spostare lo sforzo dalla micro-gestione alla qualità dei vincoli a monte. ADR sintetiche, con primitive nominate, diventano segnali che l’agente riconosce e riducono drift e rielaborazioni in review. La redazione concorda: decisioni chiare, vicine al codice e nel contesto dell’agente alzano la qualità e fanno risparmiare tempo. Il caveat è semplice: ADR stantie o vaghe non aiutano, e l’agente non le seguirà.