Avete presente quando cercate di fare debugging su un database e scoprite che una colonna che doveva contenere solo numeri è diventata un cimitero di stringhe, booleani e pattern casuali? Ecco, SQLite per anni è stato un po’ come quel tuo amico che dice ‘va tutto bene’ mentre la sua vita sta andando in pezzi.

Il punto è che la filosofia classica di SQLite è la ‘flexible typing’. In pratica, il motore ti permette di infilare quasi tutto ovunque. Vuoi mettere ‘ciao’ in una colonna `INTEGER`? Succede. Vuoi creare una colonna con un tipo che non esiste nemmeno, tipo `BLOBB` (con due B)? SQLite ti sorride e procede senza fiatare. È una libertà che, a prima vista, sembra fantastica, ma che in produzione si trasforma nel classico incubo da ‘perché il modulo calcolo crasha alle tre di notte?’.

La buona notizia (per chi ha il sangue freddo e odia i bug silenti) è che esiste una funzione chiamata ‘Strict Tables’. Basta aggiungere la parola chiave `STRICT` alla fine della definizione della tabella e — boom! — il party finisce. Se provi a inserire del testo in una colonna numerica, SQLite smette di fare il compiacente e ti lancia un errore. Fine della storia. Niente più tipi di dato inventati sulla fly o tipi ‘fantasma’ che non corrispondono alla realtà.

Certo, non è tutto rose e fiori. Se hai già un database pieno di spazzatura, passare al mode ‘strict’ non è un semplice click. Devi creare una nuova tabella, migrare i dati, pulire il disastro e sperare che il processo di `INSERT INTO … SELECT` non esploda perché hai trovato un altro valore illegale nascosto in un angolo remoto. È un lavoro sporco, lo so, ma è il prezzo da pagare per la sanità mentale.

E poi c’è la polemica interna. I developer di SQLite hanno una loro pagina dedicata che difende il ‘flexible typing’, sostenendo che la flessibilità sia un punto di forza per casi d’uso particolari, come i magazzini di chiavi-valore o l’importazione di CSV sporchi. Io dico che è un po’ come dire che il caos è una forma di ordine avanzato. Può andare bene per un esperimento di laboratorio, ma quando devi costruire qualcosa di serio, vuoi che il tuo database ti fermi quando stai facendo una cavolata.

In conclusione: se usate SQLite 3.37.0 o versioni successive, smettete di giocare a Risiko con i tipi di dato. Usate le `STRICT tables`. Sono semplici, sono chiare e, soprattutto, vi evitano di dover passare il weekend a rintracciare quel maledetto valore ‘garbage’ che ha rotto tutto. Se volete ancora la libertà totale, usate il tipo `ANY`, ma non lamentatevi se poi il vostro schema sembra un set di LEGO mescolato con pezzi di un motore diesel.

Source: Prefer strict tables in SQLite

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

Quanto spesso vi è capitato di guardare un pezzo di codice HTML, magari un maledetto legacy scrap di un progetto iniziato tre anni fa, e sentirvi come davanti a un ammasso di spaghetti senza fine?

Siamo onesti: la maggior parte di noi, quando deve tirare su una pagina veloce per mostrare il nuovo prototipo di una CNC o un log di un esperimento con l’IA, usa i `