Se pensavate che il mondo del software fosse un meccanismo senza fine di patch, aggiornamenti e alert di sicurezza che vi saltano in faccia alle tre di notte, preparatevi a ricalibrare i vostri parser.

Daniel Stenberg, l’uomo che ha reso curl lo standard de facto per ogni singola richiesta HTTP che passa per i nostri terminali, ha appena annunciato una notizia che farebbe venire un infarto a qualsiasi CISO di una multinazionale: durante tutto il mese di luglio 202LE, il progetto curl non accetterà, né gestirà, alcuna segnalazione di vulnerabilità. Lo hanno ribattezzato, con un pizzico di sano sarcasmo, «curl summer of bliss».

Sì, avete letto bene. Il form di sottomissione su Hackerone rimarrà spento, come un vecchio Commodore 64 quando stacchi la spina. Per trenta giorni, i bug critici che potrebbero far saltare in aria metà della rete globale dovranno restare nel limbo, in attesa che gli sviluppatori tornino dalle vacanze a godersi il sole (o a smanettare con qualche progetto di retrocomputing senza l’ansia di un exploit imminente).

Per noi che viviamo di script, automazioni e tool che girano su server che non vediamo dal 2015, la cosa è decisamente bizzarra. Da un lato, c’è un fascino quasi romantico in questa idea: il diritto al disconnessione portato all’estremo, quasi un atto di ribellione contro la cultura della reperibilità perenne che distrugge il cervello. È un po’ come quando stacchi il modulo Wi-Fi dalla tua stampante 3D per evitare che parta un aggiornamento firmware non richiesto che ti rompe tutto il workflow: un momento di pace pura.

Dall’altro lato, però, bisogna essere onesti. Se siete un ricercatore di sicurezza che ha appena trovato un buffer overflow che permette l’esecuzione di codice remoto su ogni server Linux del pianeta, trovarsi davanti a un modulo chiuso è frustrante quanto trovare un errore di sintassi in un codice Python complesso proprio un minuto prima della deadline.

Cosa significa per noi maker e smanettoni? Se state usando curl nei vostri progetti IoT o nei vostri script di automazione, sappiate che per luglio 2026 sarete ufficialmente in una zona di ‘sicurezza apparente’. Non è che il codice diventi magicamente incrollabile, è solo che nessuno ti dirà se sta bruciando.

In un mondo dominato da cloud provider che ti vendono servizi di sicurezza ‘all-in-one’ (e carissimi) e da una cultura enterprise che vive di panic-button, vedere un progetto così fondamentale che dice «No, ragazzi, questo mese non si lavora» è una boccata d’aria fresca. È un promemoria che, sotto l’hype dell’IA e delle megacorporazioni, esistono ancora esseri umani che gestiscono l’infrastruttura del mondo e che, ogni tanto, hanno bisogno di spegnere tutto e dimenticarsi dei pacchetti corrotti.

Source: Curl will not accept vulnerability reports during July 2026

Siete pronti a ricevere una verità scomoda che farà piangere i manager ossessionati dalle metriche di velocità?

C’è questa strana idea circolante secondo cui l’intelligenza artificiale serva solo a una cosa: produrre una quantità industriale di codice mediocre, scritte male e senza un briciolo di controllo, per poi fare merge selvaggi sperando che tutto regga. È il regno del «vibe coding» estremo: scrivi una riga, ne sputa cento l’AI, schiaccia ‘merge’ e prega che il server non prenda fuoco durante la notte. Un vero delirio da ‘slop cannon’.

Però, ascoltate bene, perché qui c’è la vera chicca per chi, come noi, ama quando le cose funzionano al primo colpo (o almeno al secondo).

Nolan Lawson ha appena pubblicato un pezzo che ribalta completamente la narrazione. Invece di usare le LLM per scrivere più velocemente, lui le usa per scrivere meglio, accettando il fatto che il processo diventerà più lento. L’idea è geniale: usare agenti AI non come assistenti alla scrittura, ma come revisori spietati. Immaginate di lanciare un team di sub-agenti (Claude, Cursor, Codex) su una vostra Pull Request con un unico compito: trovare ogni singolo bug, dalla falla di sicurezza critica al commento inutile che non c’entra nulla con il codice.

Il workflow è quasi poetico nella sua meticolosità. Si lancia l’attacco, si classificano i bug per gravità, si eliminano i critici e si decide quali sprecarci tempo e quali ignorare perché la ‘fatica non vale il risultato’. Non è una corsa ai 10x di produttività che promettono le slide di marketing; è un processo di raffinamento.

Da smanettone che passa le notti a debuggare circuiti o a cercare di far girare un vecchio emulatore su hardware moderno, questa cosa mi gasa da matti. Noi siamo gente che ama capire i ‘failure modes’, ovvero dove le cose si rompono. L’AI, se usata come un microscopio elettronico invece che come un martello pneumatico, ci permette di esplorare gli angoli più oscuri della nostra codebase senza dover leggere migliaia di righe di codice a mano.

Certo, non aspettatevi di finire i progetti in metà tempo. Anzi, preparatevi a finire in una ‘side-quest’ infinita: l’AI vi troverà bug che esistevano già da mesi, costringendovi a riscrivere test unitari e a sistemare refusi che pensavate innocui. Ma il risultato è un software più sano, più solido, quasi artigianale.

Quindi, la prossima volta che sentite parlare di ‘AI-driven development’ come se fosse una fabbrica automatizzata di spazzatura, provate a fare l’opposto. Usate i token per scavare più a fondo. Rallentate. Usate l’AI per interrogarvi, per farvi mettere in crisi e per costruire qualcosa che, quando lo smonteremo tra dieci anni, non si sbriciolerà come un pezzo di plastica riciclata male.

Source: Using AI to write better code more slowly