01 Sviluppo software
Kernel su misura e sandbox tagliano il 96%
There are so many Linux zero-day vulnerabilities these days, but on Replit we’re able to avoid 96% of them with our custom Kernel build. Read about our new sandbox design.
venerdì 6 novembre 2026
L'insieme indaga come personalizzazione e pratiche ingegneristiche influenzano efficienza, sicurezza e sprechi nel software e nei modelli.
02 Intelligenza artificiale
Personalizzabilità come gate di lancio del modello
we spent a ton of time understanding what makes models customizable, and built Inkling 2 Small to have the right properties. For a fixed data and $ budget, this model will get you very good results (relatively) versus other options. Probably one of the only model programs in the industry with a launch blocking eval around customizability. Go @tinkerapi !
Soumith Chintala mette il peso della sua esperienza di addestramento su una scelta di processo: Inkling 2 Small nasce per essere adattato e il rilascio si ferma se la «valutazione che blocca il lancio» sulla personalizzabilità non supera la soglia. La mossa rifiuta le medie da vetrina e tratta l’adattabilità come requisito di progetto, con l’impegno esplicito a dare buoni risultati a dato e budget fissi.
Per chi costruisce prodotto questo sposta la pianificazione dal punteggio generico al costo reale di portare il modello al proprio dominio. Se la valutazione diventa pubblica e ripetibile, scende il rischio di tuning a vuoto e si può fissare un contratto di qualità interno che dipende dal dato del team. Giudizio della redazione: direzione giusta e buco reale colmato. Senza protocollo e baseline accessibili resta una promessa. Se aprono quel pezzo, altri vendor dovranno misurarsi su ciò che conta in produzione.
03 Sviluppo software
Un target di 30.000 righe al giorno incentiva spreco
Bryan is too nice: He is looking to reconnect with the engineer he talked with after The Pragmatic Engineer Unplugged, which dev has a mandate to generate 30K LOC per day (!!) Yes, that expectation is wild and weird. (If you’re that dev, or in similar shoes. , DM him!)
Gergely Orosz riporta il caso di un ingegnere a cui sarebbe stato chiesto «30.000 LOC al giorno». Colpisce perché ripropone la scorciatoia dei KLOC come misura di produttività. Nel passato questa metrica è entrata perfino in contratti e rendicontazioni, poi è stata abbandonata a favore dei punti funzione proprio perché la quantità di codice gonfia i numeri e peggiora i risultati. Qui rientra dalla finestra con un obiettivo giornaliero che trasforma la metrica in bersaglio.
La pressione a far crescere i commit premia soluzioni prolisse e scoraggia riuso e refactoring. Il conto arriva in manutenzione: più debito tecnico, più regressioni, cicli di integrazione più lenti. Il nostro giudizio è netto: fissare obiettivi sulle LOC è una scelta gestionale pigra che trasferisce rischio su chi mantiene e su chi usa il software e produce report ordinati e sistemi fragili.
Amjad Masad sostiene che con un kernel personalizzato e una nuova sandbox su Replit si riesce a «evitare il 96% delle zero‑day Linux». Replit esegue codice non fidato e conosce i rischi di un multi‑tenant. La scelta è infrastrutturale: ridurre la superficie prima delle patch, invece di inseguire CVE.
Per chi gestisce ambienti condivisi ridurre la superficie compra tempo e abbassa le emergenze. Togliere funzionalità al kernel e stringere l’isolamento rompe compatibilità, impone una catena di build e sposta competenze nel team piattaforma. La redazione giudica la direzione giusta per chi esegue codice non fidato in produzione. Sul numero serve cautela: senza metodologia pubblica e minacce dichiarate il 96% resta un ordine di grandezza, utile nel perimetro di Replit.