Programmare non è più come prima

Ben lo dice chiaro: non gli importa più dei linguaggi di programmazione come un tempo. E non è una frase fatta. Parla per esperienza diretta, dopo anni passati a combattere online per il framework migliore.

Fino a poco tempo fa, scegliere se usare React o Svelte, TypeScript o Go, REST o GraphQL erano decisioni che potevano rovinarti la settimana. Oggi quelle scelte contano meno. Non zero, ma meno di prima.

SvelteKit 3 è uscito e Ben non se n'è accorto

Il caso più chiaro è Svelte. Ben ha fatto video per anni su quanto Svelte fosse meglio di React. La release candidate di SvelteKit 3 è uscita di recente, con un sacco di novità che prima lo avrebbero fatto saltare sulla sedia. Invece non ci ha pensato quasi per nulla.

Eppure usa Svelte più che mai. Il sito personale, gli strumenti interni, i progetti pubblici: tutto Svelte. Solo che non si preoccupa più dei dettagli che prima lo facevano impazzire. Il framework è diventato un mezzo, non un fine.

Cosa conta davvero adesso

Le domande che contano sono quelle ad alto livello: usi HTTP o WebSocket per mandare dati dal client al server? Quanto grandi sono i payload? Dove vive il database? Come funziona l'autenticazione? Come scala il sistema quando arrivano un milione di utenti?

Queste domande hanno sempre contato, ma prima erano il punto di partenza. Adesso sono il punto d'arrivo. Tutto il resto, i dettagli di implementazione, i pattern, le librerie, se li gestisce l'AI.

Il caso tRPC: quando l'eleganza non serve più

Prima dell'AI, library come tRPC erano fondamentali. Ti davano type safety full-stack senza scrivere codice boilerplate: definisci gli endpoint sul server, il client li consuma con zero sforzo. Tutto perfetto, tutto automatico.

Adesso puoi fare lo stesso con una REST API tradizionale, generare la documentazione, importare i tipi sul client. È più verboso, meno elegante, un po' sporco. Ma se non è il programmatore a doverci lavorare ogni giorno, perché dovrebbe importare?

I modelli sono diventati abbastanza bravi da rendere queste librerie opzionali. Non inutili: opzionali.

Le lingue diventano scambiabili

Ben ha un'app che si chiama Sudo, un tool di dettatura vocale locale. L'ha scritta interamente in Swift usando un modello AI. Non conosce Swift, non ha mai letto il codice, eppure l'app funziona.

Poi c'è il caso di Bun, che ha migrato da Zig a Rust in poche settimane usando quantità enormi di token AI. Risultato: funziona meglio, è più veloce. Il codice è "slop", come lo chiama Ben, ma è slop che funziona.

Le lingue non sono più incastrate. Puoi prendere un progetto in un linguaggio, usarlo come prompt complesso, e portarlo in un altro. Stessa cosa con i framework: trasformare un sito Svelte in React, o viceversa, è diventato un lavoro da minuti, non da giorni.

Meno dipendenze, più controllo

Prima, ogni progetto medio aveva 20 o 30 package nel package.json. Adesso Ben preferisce che l'AI generi una implementazione custom per qualsiasi cosa sotto le mille righe. Un color picker? Un componente UI semplice? L'AI lo fa in secondi, e non devi mantenere quel codice come dipendenza esterna.

Il motivo è pratico: prima usavamo librerie per risparmiare tempo sul boilerplate. Ora quel tempo lo risparmia l'AI, e in più non devi preoccuparti di aggiornamenti, vulnerabilità, compatibilità. Il tuo package.json diventa più piccolo, il progetto più leggero.

Il problema delle black box

Il rovescio della medaglia: Ben non capisce più del tutto come funziona il suo stesso codice. Il suo app Sudo? Non sa come è fatto dentro. Conosce abbastanza per capire il flusso generale, ma non abbastanza per riscriverlo da zero.

Questo è il vero problema dell'AI nell'informatica: quando generi codice a questo livello, perdi la comprensione granulare. E quando hai 15 PR che arrivano notte, ognuno con migliaia di modifiche, non puoi leggere ogni singola riga.

Ben ha sviluppato un approccio: non controlla più il codice riga per riga, ma controlla come viene usato. Se vede un pattern che non gli piace, tipo una vecchia funzione load di Svelte invece delle remote functions, lo segnala e chiede all'AI di correggere. Poi verifica il nuovo output.

Non è perfetto. È un compromesso. Ma è il modo in cui si lavora adesso.

La tabella delle priorità

La community reagisce

I commenti sotto il video sono divisi. C'è chi è triste per la fine di un'era, chi pensa che sia solo un cambiamento necessario, chi ribatte che per i programmatori junior contare ancora leggere e capire il codice.

Un commento colpisce: "L'AI è il grande rivela. Mostra che tipo di programmatore eri sempre stato." Chi amava il processo di costruzione, ora si sente perso. Chi voleva solo il risultato, si è trovato un alleato perfetto.

Un altro punto: se prima passavi ore a discutere di nomi di variabili e astrazioni, ora quelle discussioni non servono più. Il tempo si sposta verso l'architettura, la comunicazione, la capacità di guidare gli agenti.

Conclusione

Non è una tragedia, non è una rivoluzione. È un cambiamento di livello. Programmare prima significava conoscere i dettagli di ogni singola riga. Adesso significa capire come i pezzi si incastrano insieme, e lasciare che l'AI faccia il lavoro sporco.

C'è un po' di malinconia, per quei tempi in cui il framework che sceglievi definiva chi eri come sviluppatore. Ma c'è anche eccitazione: con un computer e degli agenti, il tetto di ciò che puoi costruire si è alzato tantissimo, soprattutto se lavori da solo o in un team piccolo.

Ben non ha una risposta su come usare bene questi strumenti. Nessuno ce l'ha. Sta tutti provando, sbagliando, adattandosi. L'unico consiglio che dà è: abbraccialo. Vedrai cosa puoi fare.